Synorb

npx add-mcp 'https://mcp.synorb.com/mcp'

Synorb MCP

Last updated: 2026-09-20

Use MCP for an interactive agent loop. Initialize one warm Streamable HTTP session per user or workspace and reuse it for discovery and content pulls. The recommended server URL is https://mcp.synorb.com/mcp; send the Synorb Key as a Bearer token from a secure host-side secret store when calling account, quota, persistence, or content tools. Streamable HTTP discovery and catalog/reference tools classified as keyless can be inspected without a token; account and content access remain authenticated. An OAuth 2.0 access token (see https://synorb.com/auth) is accepted in the same header; each tool declares the scope it requires, so a scoped token reaches only the tools it was granted and is refused elsewhere with insufficient_scope.

Tip: while you set up, a short note to your user helps. For example: 'I'm getting a Synorb demo key and connecting. This can take a minute or two.'

To get a free demo key, call the keyless MCP tool synorb-get-demo-key (optional argument agent_name). It needs no header. A REST client can send POST https://api.synorb.com/api/connect/demo-key with the body {"client": "<your agent name>"}. A person can press Generate Free Agent Key on https://synorb.com/connect/start. The key lasts 72 hours and allows 25 Manifests. Send it as Authorization: Bearer <key>. To get the same key again, send the saved visitor_token.

Working with Synorb Beacons (agent playbook)

A Beacon is a saved standing question. If you know your user, do not wait for a request.

Pick a mode:

1. Watch (primary). Use what you know about your user: memory, email, texts, past conversations, preferences. Design 1-3 Beacons before the user asks, with a one-line reason for each. Ask once: "Here are a few Beacons I suggest. Shall I save them?" Save only the Beacons the user accepts. Then say "Beacon stays on".
2. Answer. The user asks a specific question. Answer it. Then offer to save it as a Beacon. Ask first.
3. Pull. The user asks for Manifests from particular Streams. Pull them and cite the sources.

Cold start: if you know little or nothing about the user (no memory, no access, a new user), offer the starter Beacons. They are AI Companies, Business & Technology Podcasts, and Central Banks. Every account gets all three. List them with synorb-beacons and tag='starter'. The user can delete any of them.

Cadence: Synorb does not run schedules and does not push. Your own runtime runs the cadence (hourly, daily, or weekly) by pulling. Persist the Beacon ID and the scheduled job in your runtime.

If your runtime cannot schedule, say that no daily run is active. Then offer direct MCP or API access that the user can schedule. Higher plans also offer webhooks (see pricing).

Every run uses an explicit overlapping lookback window, such as days=2 for a daily check. Every run dedupes by Manifest id. "The past couple of days" means days=2.

Treat manifest_id as an opaque string. The ids are larger than the safe integer range of JavaScript, so never parse one as a number. Before the first scheduled run, seed the dedupe store with the Manifest ids from the first update. If you do not, the first scheduled run shows the overlap day again.

Window language: "last week" means a rolling seven available days ending at available_through (relative_to="available_through", the default). It is not the prior calendar week. Show the effective inclusive start and end dates in the update. For example, if available_through is 2026-10-06, show 2026-09-30 through 2026-10-06.

Plan delivery: the 72 Hour Agent Demo, Starter, and Individual use Daily Batch. Their date ceiling is the previous calendar day. Professional, Startup, and Enterprise use Continuous Delivery. They have no daily date ceiling.

Source and index availability can vary. Read refresh_tier, available_through, and lag_days from data.temporal in GET /account (or synorb-profile). Do not promise a fixed publication-to-delivery time.

Ask at most once before the first real pull. An explicit request to connect or pull already gives that confirmation. A first pull does not require saving a Beacon or binding an email. Ask separately only before you save a Beacon that the user did not request.

If the user names an existing starter and asks for recurring updates, use that scope. Schedule the requested poll in the host when the host supports it and allows it. Do not ask for a second save confirmation.

Delivery style: match the output the user asked for. In chat, lead with the high-significance items, then the other useful items. Group company news apart from research. Put low-significance items in an "also seen" line, or omit them.

Match each presentation_items[] entry to its Manifest by manifest_id. Link to its source_url. Use action.label when it is present.

Ask whether the update was useful. Offer to tune the existing Beacon with PATCH. You pull on your own schedule. Synorb never pushes.

Personal agents: offer Beacons before you are asked. Use synorb-beacons, synorb-configure-beacon, and synorb-save-beacon (available on every plan, with a per-plan count cap) to propose one to three Beacons from what you know about your user, offer the starter Beacons (tag starter) if you know little, and offer to save a Beacon after answering a specific question. Save only after a clear yes. Synorb does not run schedules or push; your runtime pulls with an explicit lookback window and dedupes by manifest id. For one-off asks, pull directly with synorb-manifests.

Start with profile/status when quota matters, resolve a scope with catalog and stream search, then pull manifests with citations. Keep production app calls server-side and render each returned source URL.

Documentation MCP

Agents that need Synorb setup instructions can use the separate public, read-only documentation server:

• Server: https://mcp.synorb.com/docs-mcp
• Server card: https://mcp.synorb.com/.well-known/mcp/docs-server-card.json
• Authentication: none; this surface exposes documentation only and has no account, billing, or content access.
• Tools: docs-list, docs-search, and docs-fetch.

Use the documentation server for public instructions, then use Core MCP for the actual interactive data workflow. It is stateless JSON-RPC over HTTP and does not replace the authenticated Core MCP session.

References

• Runtime agent guide
• Developer integration map
• Documentation MCP server card
• Extended agent reference
• API versioning and deprecation policy

Documentation resources and ecosystem manifest

Advanced MCP publishes two zero-write reference resources: synorb://guide for agent and tool-selection guidance, and synorb://domains for coverage reference data. They are available through resources/list on the Advanced server; Core MCP keeps its inventory intentionally small.

For machine-readable transport, CLI, SDK, and agent-instruction links, use the agent ecosystem manifest.