Ecosystem & Patterns

Topics We'll Cover

• The Host Landscape — Who Speaks MCP
• Reference Servers — What Anthropic Ships
• The MCP Registry
• Pattern A — Data Servers (Read-Only Context)
• Pattern B — Tool Servers (Side-Effecting Actions)
• Pattern C — Agent Servers (Sampling-Driven) Sampling deprecated in 2026-07-28
• Pattern D — Multi-Server Orchestration
• Distribution — uvx / npx / Docker
• What to Take Away

The Host Landscape — Who Speaks MCP

Within fourteen months of the spec going public, MCP went from one Anthropic host to a dozen mainstream ones. The list as of early 2026:

Reference Servers — What Anthropic Ships

The modelcontextprotocol/servers repo on GitHub is a working library of reference implementations. They're worth reading for two reasons: they exercise every primitive correctly, and they're the canon hosts test against.

The reference set, by category

How to read one

Pick servers/src/sqlite or servers/src/filesystem in the repo. Each is < 500 lines. The structure is the same across all of them:

1. Argument parsing — root path, db path, etc.
2. Server construction with declared capabilities.
3. Tool definitions with input schema.
4. Resource definitions (where applicable).
5. Single run() call binding stdio transport.

The MCP Registry

Through 2025 the discovery story was “read READMEs”. The official MCP Registry, generally available in early 2026, fixes that. It's an open, JSON-Schema-driven catalogue of servers with metadata, capabilities, and install instructions.

Registry record — what it captures

{
  "name": "io.acme/postgres",
  "version": "2.4.1",
  "description": "Read and write a PostgreSQL database.",
  "homepage": "https://github.com/acme/mcp-postgres",
  "license": "MIT",
  "publisher": { "id": "io.acme", "verified": true },
  "transports": ["stdio","http"],
  "protocol_versions": ["2025-03-26","2025-06-18"],
  "capabilities": {
    "tools": [
      { "name":"query",  "annotations":{ "readOnlyHint": true } },
      { "name":"mutate", "annotations":{ "destructiveHint": true } }
    ],
    "resources": ["pg://schema/{table}"]
  },
  "install": {
    "uvx":    "uvx mcp-server-postgres",
    "docker": "ghcr.io/acme/mcp-postgres:2.4.1"
  },
  "auth": {
    "type": "oauth2",
    "scopes_required": ["postgres.read","postgres.write"]
  },
  "signature": "sha256:…"
}

What the host does with this

• Show the user a vetted list, with verified-publisher badges.
• Cross-check the running server's tool list against the registry — mismatch is the rug-pull signal from deck 04.
• Pre-flight install: pick the right runtime (uvx if Python is available, fallback to Docker).
• Offer an “upgrade available” nudge when a new version is published.

Pattern A — Data Servers (Read-Only Context)

The simplest and most common pattern. The server exposes resources — addressable read-only chunks of context. No side effects, no authentication beyond the user's own credentials, low risk surface.

Worked example shape

resources/list   → { resourceTemplates:[
                       { uriTemplate:"wiki://{space}/{slug}", name:"Wiki page" },
                       { uriTemplate:"wiki://search?q={q}", name:"Search"}
                     ]}
resources/read   → { contents:[{ uri, mimeType:"text/markdown", text:… }]}
tools/list       → [{ name:"recent_changes",
                          annotations:{ readOnlyHint:true }}]
tools/call       → { content:[{type:"resource_link", uri:"wiki://…"}],
                       structuredContent:{ pages:[…]}}

Pattern B — Tool Servers (Side-Effecting Actions)

The riskier sibling. The server exposes tools that change something in the world — create issues, send messages, deploy services, mutate data. Annotations and confirmations carry the safety weight.

Annotation discipline carries the security model

The host decides UX based on annotations — auto-approve, prompt, confirm-with-typed-acknowledgement. You, the server author, are the only one who knows whether a tool is destructive. Be honest.

{
  "name": "force_push",
  "title": "Force Push Branch",
  "description": "git push --force-with-lease to remote.",
  "inputSchema": {
    "type":"object",
    "properties":{
      "remote":{"type":"string"},
      "branch":{"type":"string"},
      "expected_sha":{"type":"string","pattern":"^[a-f0-9]{40}$"}
    },
    "required":["remote","branch"]
  },
  "annotations":{
    "readOnlyHint":   false,
    "destructiveHint":true,
    "idempotentHint": false,
    "openWorldHint":  true
  }
}

Pattern C — Agent Servers (Sampling-Driven) Sampling deprecated in 2026-07-28

The server runs an inner agent loop that calls back into the host's LLM via sampling/createMessage. The host owns the model and the user gates each sample — the server brings the workflow.

Why this is different

A normal tool call is a one-shot RPC. An agent server is multi-turn: it samples, inspects the result, samples again, possibly calls its own tools internally, and only returns to the host when its inner loop terminates.

Source: MCP specification 2026-07-28 — Deprecated features; Multi round-trip requests (accessed 2026-10-08).

Pattern D — Multi-Server Orchestration

Hosts routinely run 5–15 servers concurrently. The host is the orchestrator: it sees the union of all tool catalogues, decides which server to call for each step, and stitches results together. Two friction points emerge.

Friction 1 — Tool name collisions

Two servers can both expose a search tool. The host needs to disambiguate. Two strategies:

Friction 2 — Roots and resource scoping before 2026-07-28

The user opens project ~/code/api in their IDE. Three running servers care: filesystem, git, postgres. The host's roots mechanism is how it tells them all in one shot:

// from each connected server’s perspective
{"jsonrpc":"2.0","method":"notifications/roots/list_changed"}

// servers respond with
{"jsonrpc":"2.0","id":99,"method":"roots/list"}

// host returns the current set
{"jsonrpc":"2.0","id":99,"result":{
  "roots":[
    {"uri":"file:///Users/me/code/api","name":"api"}
  ]
}}

Servers MUST honour roots: filesystem only serves files under the listed roots; git opens the repos inside them; postgres may key its connection on the project. Roots are the user's consent boundary materialised on the wire.

Source: MCP specification 2026-07-28 — Roots; Deprecated features (accessed 2026-10-08).

Friction 3 — Cross-server data flow

Servers don't talk to each other. The host is the only thing that sees output from server A go into the prompt that produces a tool call to server B. That's deliberate; it keeps the trust topology star-shaped instead of mesh-shaped.

Distribution — uvx / npx / Docker

How servers reach users. Almost every community server falls into one of three distribution shapes:

Versioning & protocol-version pinning

MCP date-stamped versions and your server's semver are independent. Best practice:

• Advertise all protocol versions you genuinely support in the registry record — not just the latest.
• On initialize, accept the highest mutually-supported value the client offers before 2026-07-28. From 2026-07-28 there is no initialize: implement server/discover, judge the version on every request and answer an unsupported one with -32022 listing supported; a dual-era server also keeps answering initialize for legacy clients.
• Bump your server's semver when its tool surface changes; bump the registry's protocol_versions when you tested against a new spec.
• For Streamable HTTP, support a two-spec window — the current and the previous — to give clients time to upgrade.

Source: MCP specification 2026-07-28 — Versioning and compatibility; Discovery (accessed 2026-10-08).

What to Take Away

• The host landscape converged. Build one server, reach Claude Desktop, Claude Code, Cursor, VS Code, Zed, Continue, Windsurf, OpenAI Agents, LangGraph — all on day one.
• The reference set is your textbook. Every server idiom you'll need is in modelcontextprotocol/servers; everything shows them all in one place.
• The Registry turns MCP into a marketplace. Verified publishers, capability advertisement, install metadata, signed records. Enterprise registries shadow the public one.
• Four canonical patterns. Data servers (resources, read-only). Tool servers (annotated side effects). Agent servers (sampling-driven inner loops). Multi-server orchestration (the host's problem, but shaped by your output schema).
• Distribution is solved. uvx and npx for local, Docker for sandboxed, Streamable HTTP for SaaS. Pin versions, advertise honestly, support a window.
• Server design is annotation discipline. The protocol can't tell which of your tools is dangerous — you have to.
• Two protocol eras coexist. 2026-07-28 2026-07-28 made MCP stateless; hosts and SDKs that are dual-era still talk to handshake-era servers. Gateways that combine many servers are covered in chapter 7 of Agent Protocols Explained.