Skip to content

MCP server

Give other people's agents a working plug into a live system you run — your database, an API, an internal tool — so their agent can query it or act on it mid-task, in plain language, without you handing over your credentials or code. A small connector any agent snaps into.

Reach for it when the value is live — fresh data, a real action. Skip it when the recipient just needs a finished thing to look at, or a one-off procedure their agent can follow without touching your system.

Last verified: 2026-06-07 · Confidence: high on what it is, the two share shapes, and the access model; checked against modelcontextprotocol.io and the Claude Code MCP docs.

It allows you to

  • Plug a live system into someone's agent. They add one connector and it gains a new ability — "look up a grant", "file a ticket" — talking to your system in real time. [confirmed]
  • Hand out the reach, not the keys. Run it yourself and they call your URL; your database password and API key never leave your side. [confirmed]
  • Let their agent act on its own, mid-task, in plain language — it decides when to call the ability, with you out of the loop.
  • Update once; every connected agent sees it. It reads live data, so there's no copy to re-send.
  • Work with any agent. One shared standard — Claude Code, Claude Desktop, and other MCP-speaking agents all use it. [confirmed]

Ideal for

  • A shared research or forecasting database many teams query — each partner org's agent asks "what's the current estimate for X?" and gets today's number, not a stale export.
  • An org's internal wiki or knowledge base — staff agents answer from the live handbook ("what's our travel policy?"), not a PDF pasted in last quarter.
  • A private API you don't want to expose raw — wrap "submit an application" as one named tool; recipients get that action, not your endpoint or auth.
  • A live action, gated — "post to our Slack", "add a row to the tracker" — their agent does something to your system through one approved door.
  • A real one: congressMCP exposes the live Congress.gov API as MCP tools — any agent queries bills, votes, and members. The same shape over a private base is the policy/forecasting case. [confirmed]

Who can get in

How you share the connector sets who reaches it — two shapes, with the full mechanics (what a URL exposes, how its login works) in the fine print.

  • Ship the code — in a private repo only invitees run, or a public one anyone copies. Either way they bring their own key, so they reach their system, not yours. [confirmed]
  • Host it at a URL with a login — you run one copy online and hold the key; only agents that pass the login reach your live data. Cut someone off by rotating the token or dropping them from the allowlist. (true everywhere) [confirmed]

Which rungs it can hold. Code route inherits the repo's rungs (just you / named people / org-only / the whole internet); hosted route holds named people via the login. → Who can see it? [confirmed]

Handing data to the host. A hosted server holds your live data and keys; keep secrets host-side and add a login if it touches anything sensitive. → Can you trust the company? [confirmed]

What you do to set it up

  • Ask: tell Claude Code "build an MCP server that exposes \<the one thing — e.g. search our grants database>, keep the key out of the code, and give me the config snippet to share." It scaffolds the connector, wires in your tool, and tests it against your agent. ~2 min to brief it; the real cost is the ability it wraps, plus putting it online on the hosted route. [confirmed]
  • One-time, in order:
    1. Set up Claude Code — the thing that builds and tests it, ~10 min once.
    2. (Code route) a GitHub account + the CLI to share the files, ~13 min once.
    3. (Hosted route) a Fly account to run it online — ~3 min, plus a card on file.
  • Full walkthrough — Build and share an MCP server. Rather do it by hand? → by-hand section.

What the other person does

  • Connect it: one line — "connect this MCP server to my agent." Floor ~2–4 min if they have an agent. The code route asks more (their own key + runtime, run locally); the hosted route is just your URL plus any login. Route-by-route → the fine print. [estimate]
  • Use it: their agent then calls the ability as part of its own work ("search grants for climate") — you never demo it by hand. [confirmed]
  • Pay: nothing on the code route. On the hosted route you run the service; a sleep-to-zero host keeps that near $0 → Deploy to Fly. [confirmed]

Other ways to share

  • Callers will write request code, not have an agent plug it in? → a live API — the same live system over plain HTTP, for programs and scripts rather than agents.
  • A fixed procedure their agent follows — no live system to reach? → a Claude skill: a written recipe, no server to run.
  • A plain command people run, not a connection their agent calls? → a one-command tool: they type one word, it fetches and runs, no agent needed.
    • A step that should fire automatically in a pipeline, not on demand by an agent? → a GitHub Action runs the work in CI on a trigger.

Sources

Good to know

  • A connector only exposes the abilities you named, not your raw database or endpoint — recipients can do exactly what your tools allow and no more. [confirmed]
  • The code-vs-hosted choice shapes everything — who runs it, who holds the key, whose system it reaches. Full breakdown → the fine print. [confirmed]