# 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": ""}`. 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 `. 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 five starter Beacons new accounts get: AI Companies, Business & Technology Podcasts, Venture Capital, Private Companies, and Public Company Filings & Executive Transitions. 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. ## Synorb Skills Skills are jobs that a user sets up once, in the open Agent Skills format (`SKILL.md`). The agent then runs each job on a Beacon on a schedule and reports only what is new. Each skill is one Markdown file. The user's own model writes the result. - [Synorb Setup](https://synorb.com/skills/synorb-setup.md) (`synorb-setup`): Connect Synorb once, see a first cited briefing, and set up the Beacons your skills run on. - [Newsletter Writer](https://synorb.com/skills/newsletter-writer.md) (`newsletter-writer`): Set it up once. Every Monday your agent writes a new issue in your voice, every item cited. - [Research Associate](https://synorb.com/skills/research-associate.md) (`research-associate`): Set it up once. Every week your agent sends a cited memo for your question, with evidence and open questions. - [Podcast Producer](https://synorb.com/skills/podcast-producer.md) (`podcast-producer`): Set it up once. Every week your agent writes a two-host episode script, or a short spoken briefing every morning. - [Launch Radar](https://synorb.com/skills/launch-radar.md) (`launch-radar`): Set it up once. Every week your agent reports what AI companies shipped, from their own announcements. - [Thesis Tracker](https://synorb.com/skills/thesis-tracker.md) (`thesis-tracker`): Set it up once. Every month your agent reports what VC firms published, mapped to your thesis. - [Podcast Digest](https://synorb.com/skills/podcast-digest.md) (`podcast-digest`): Set it up once. Every week your agent sends the arguments from the top business and tech podcasts. - [Ambient Knowledge](https://synorb.com/skills/ambient-knowledge.md) (`ambient-knowledge`): Your agent reads Synorb every day in the background and uses what matters in everyday work, without you asking it to check. Start with `synorb-setup` when you have no Synorb connection. Catalog: https://synorb.com/skills.json. Gallery: https://synorb.com/skills. Install: - Coding agents: `npx skills add Synorb/skills` (all skills), or `--skill ` for one. - Any agent that can read a link: read `https://synorb.com/skills/.md` and follow it. - Upload: `https://synorb.com/skills/.zip` holds the skill folder. - When a skill gets a demo key, it sends `client` (REST) or `agent_name` (MCP) as `synorb-skill/`. ## References - [Runtime agent guide](https://synorb.com/agent-guide.md) - [Developer integration map](https://synorb.com/developers/llms.txt) - [Documentation MCP server card](https://mcp.synorb.com/.well-known/mcp/docs-server-card.json) - [Extended agent reference](https://synorb.com/llms-full.txt) - [API versioning and deprecation policy](https://synorb.com/docs/api-versioning) ## 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](https://synorb.com/agent-ecosystem.json).