Skip to content

SYSTEM Cited by 27 sources

Model Context Protocol (MCP)

Definition

Model Context Protocol (MCP) is an open standard — published at modelcontextprotocol.io — for servers to describe the tools they provide to LLM agents. Each tool advertises a description, parameter schema, and invocation semantics. Clients (Claude Code, Cursor, Goose, Claude Desktop, …) load servers into an agent session and expose their tools to the planner.

Why it exists

Before MCP, every agent framework had its own tool-description format. MCP standardizes the protocol so:

  • Tool servers are portable across MCP-compatible clients.
  • Agent vendors build one integration surface instead of N.
  • Enterprise teams can expose one MCP server that every agent in the company (Claude, Cursor, Goose, …) can use uniformly.

What MCP does well

  • Protocol-level portability — a server written once works in any compliant client.
  • Tool-description as first-class artifact — tools are self-describing; agents pick from them dynamically.
  • Ecosystem leverage — third-party MCP servers (Backstage, Datadog, Dropbox Dash, GitHub, …) proliferate; an agent can compose across them.
  • Local- and remote-server shapes — both stdin/stdout and HTTP/SSE transports supported.

Known limitations (surfaced by production deployments)

Multiple sources converge on the same design concerns:

Production design patterns that assume MCP

Patterns derived from treating MCP tools as a scarce-context surface:

  • patterns/tool-surface-minimization — keep exposed tool count low via flexible tools, opt-in toolsets, layering.
  • patterns/tool-surface-minimization — one retrieval tool backed by a unified index replaces many per-source tools (Dash / Dash MCP Server).
  • token-budget-pagination — return N tokens worth of records + cursor, not fixed record count.
  • query-language-as-agent-tool — expose SQL instead of many get_X endpoints.
  • actionable-error-messages — agents in retry loops re-enter bad context; specific errors break the loop.

MCP Resources (implementer altitude)

The MCP specification defines two first-class surfaces on an MCP server: tools (actions, mutations, side effects, calculations) and resources (read-only, addressable, client-cacheable, optionally-subscribable content). Most wiki coverage of MCP above concentrates on the tools surface — the context-budget cost of tool inventories, the accuracy degradation with more tools, the five-pattern Datadog retrospective, the Unity-AI-Gateway-at- Databricks governance layer. The resources surface is less covered in production retrospectives but is canonicalised at implementer altitude by Wix Engineering's 2026-01-08 tutorial (Source: sources/2026-01-08-wix-mcp-resources-all-you-need-to-know).

Canonical sub-primitives:

  • mcp-resource — the resource primitive itself. Three shapes: static (fixed content, one registration), template (parameterised URI via RFC 6570 placeholders), and updating (declares subscribe: true capability, emits notifications/resources/updated on content change).
  • mcp-tool-vs-resource — the decision rule for when to expose behaviour as a tool vs a resource. Rule: resources for read-only cacheable content that both users and agents might want to view directly; tools for actions, mutations, side effects, and calculations.
  • resource-link-vs-embedded-resource — token-budget trade-off when returning a resource from a tool. resource_link (URI only, client caches) for large or frequently-reused content; embedded resource (full content inline) only for small one-shot payloads.
  • resource-subscribe-capability — the push-update protocol edge. Server declares capabilities: { resources: { subscribe: true } }; emits sendResourceUpdated({ uri }) on change; clients re-read on notification.
  • resource-annotations — optional per-resource metadata (audience, priority, lastModified) used by clients for filtering and sorting in discovery UIs.
  • mime-type-as-first-class-metadata — always declare MIME types on resources (and by extension on any addressable content) so clients can render without sniffing.

Two integration patterns canonicalised from the resources axis:

  • expose-resource-as-tool-for-agent-discoverability — workaround for MCP-client fragmentation around resource discovery. Register a companion tool that returns a resource_link / resource content type; resources become reachable in every MCP-aware agent flow through tool listing. Creates tension with patterns/tool-surface-minimization — apply judiciously.
  • subscribe-notify-for-updatable-resource — the live-logs / live-metrics / live-feeds pattern. Structure the content as an MCP resource with subscribe: true; server pushes notifications; clients re-read. Same cache-invalidation economics as server-sent events, riding the MCP transport already established.

Three @modelcontextprotocol/sdk v^1.8.0 production caveats surfaced by Wix (SDK-specific, not protocol-specific):

  1. The JavaScript URL constructor breaks file:// resource URIs — trailing slash appended, turning file://example.txt into file://example.txt/. Fix: use a custom scheme (doc://, log://, git://, resource://).
  2. The SDK does not implement the subscribe method. Clients calling subscribe get "method not found". Server can still emit notifications via sendResourceUpdated.
  3. No subscriber targeting. Every notification fans out to every connected client regardless of what each client is interested in — O(N) wasted traffic at scale. Authors needing filtered fan-out implement subscribe themselves.

See systems/mcp-typescript-sdk for the full SDK page.

Known MCP servers in this wiki

  • systems/dash-mcp-server — Dropbox's MCP server, one retrieval tool over the Dash universal search index.
  • systems/datadog-mcp-server — Datadog's official MCP server; five-pattern redesign after V1 thin-API-wrapper failed.
  • systems/mcp-server-portal — Cloudflare's internal aggregator over internal tool MCP servers (Backstage-driven service-catalog exposure).
  • systems/sprites-mcp — Fly.io's vendor-hosted remote MCP server at sprites.dev/mcp for Sprite CRUD. Ships with a three-axis creation guardrail (org scope × Sprite cap × name prefix) and is explicitly framed by Ptacek as the fallback shape for shell-less agents.
  • systems/meta-capacity-efficiency-platform — Meta's unified platform for hyperscale performance engineering (2026-04-16). Exposes profiling / experiments / configuration history / code search / documentation as MCP tools to in-house agents; pluggable skills encode senior-engineer reasoning patterns over the shared tool layer. Canonical wiki instance of mcp-tools-plus-skills-unified-platform — hyperscaler- internal-infrastructure-tools deployment of MCP, distinct from the SaaS-facing deployments above. Program impact: "hundreds of megawatts of power" recovered; ~10-hour investigations compressed to ~30 minutes.
  • Pinterest's MCP ecosystem (2026-03-19) — three named seed servers (Presto, Spark, Knowledge) plus others (Airflow mentioned). All cataloged in a central MCP registry. Canonical wiki instance of hosted MCP ecosystem at the enterprise altitude — 66,000 invocations/month across 844 MAUs, ~7,000 engineer-hours-saved/month (January 2025). See sources/2026-03-19-pinterest-building-an-mcp-ecosystem-at-pinterest.

MCP registry as a protocol-scoped instance of the AI tool registry pattern (MongoDB, 2026-05-11)

MongoDB Engineering's 2026-05-11 Fighting Tool Sprawl position post (sources/2026-05-11-mongodb-fighting-tool-sprawl-the-case-for-ai-tool-registries) positions the enterprise AI tool registry as a broader category that subsumes the MCP registry shape: same four functions (discovery + versioning + certification metadata + access control), same dual-surface property (web UI for humans + API for agents), same organisation-internal scope — but extended beyond MCP-compliant servers to any tool an agent can call (REST APIs, internal RPC services, code-execution sandboxes, data accessors).

The post explicitly cites Kong's enterprise MCP Registry launch (February 2026) — "hardcoded and managed tool isolation across teams, fragmented integrations, and limited organization visibility" — as market validation of the registry pattern at the MCP layer. Canonical wiki naming of this generalisation: enterprise-ai-tool-registry (the broader pattern, of which mcp-registry is the protocol-scoped instance) plus patterns/on-behalf-of-agent-authorization (the "Internal Developer Portal one layer up" framing). The tool-sprawl failure mode is what motivates both at their respective scopes.

Seen in

  • sources/2026-09-29-dropbox-evolving-our-calendar-assistant-reclaim-to-be-ai-native-with-f60d451f — MCP used bidirectionally in one product (client + server). Reclaim, Dropbox's AI calendar assistant, runs an MCP client inside its own agent loop (to consume compatible tools from other services) and also exposes its own tools through an MCP server to external AI clients — Claude and ChatGPT — which use their own models and agent loops but "can call the same tools used within Reclaim." A clean small-scale illustration of MCP's two roles at once: the same tool surface is both something Reclaim's agent calls out to and something external assistants call in to, reusing the shared Schedule Action tools rather than duplicating integration logic (patterns/mcp-as-centralized-integration-proxy).
  • sources/2026-09-24-zalando-agentic-platform-open-sourcing-the-agentic-identity-broker RFC 9728 (Protected Resource Metadata), Cross-App Access (XAA), SPIFFE, IETF WIMSE, and the AIMS draft. Architecturally, MCP servers are the downstream tool endpoints on the far side of the agentgateway + Agentic Identity Broker gate: agents reach in-house or third-party MCP servers only via the gateway, which performs token exchange so the MCP server sees a provider token the agent never holds. A core design goal is to keep OAuth 2.0 ceremonies out of MCP servers entirely (they are fronted by the gateway) — the OBO / MCP-as-centralized-integration-proxy shape at the identity layer. "could give an agent the context around the data and not just the data itself, so it understood what a table meant instead of guessing" — grounding the agent's text-to-SQL generation before it runs on Trino.
  • sources/2026-08-14-cloudflare-how-cloudflare-detects-mcp-traffic-and-helps-secure-it — MCP as a network-governance target. Because MCP runs over ordinary HTTPS with no required hostname or /mcp path, MCP traffic "has no obvious shape" and a single line of config connects an agent to any server. Cloudflare detects it on the wire via the MCP-Protocol-Version header (Gateway experimental.is_mcp), separates shadow MCP from Portal bypass, enforces Portal-only egress, and gates tool calls server-side with WriteGuard. Establishes the client / network / server control-point framing and reuses the 2026-07-28 stateless Mcp-Method / Mcp-Name headers (protocol-metadata-in-http-headers) as per-operation classification signals.
  • sources/2026-08-06-cloudflare-ai-search-give-your-agents-a-search-engine — MCP as a no-code search surface. Cloudflare AI Search namespaces expose a /mcp endpoint (alongside /search) that any coding agent can drop into its MCP config with zero deployment. The Cloudflare Dev Stack MCP ships as a single tool inside Cloudflare's MCP server that fans one call across 10 Cloudflare-surface AI Search instances, returning cited docs — positioned as replacing the agent's "web search then fetch full pages" fallback with current, cited, low-token results.

  • sources/2026-01-08-wix-mcp-resources-all-you-need-to-know — Canonical implementer-altitude disclosure of the MCP resources surface. Wix Engineering's 2026-01-08 tutorial walks the @modelcontextprotocol/sdk v^1.8.0 SDK end-to-end for static / template / updating resource shapes; canonicalises the tools-vs-resources decision rule (mcp-tool-vs-resource), the resource-link-vs-embedded-resource token-budget trade-off (resource-link-vs-embedded-resource), the RFC 6570 URI template shape (uri-template-rfc6570), the subscribe: true capability and sendResourceUpdated emission API (resource-subscribe-capability), and the optional annotations metadata (resource-annotations). Three SDK-v1.8.0 gotchas surfaced: (1) JS URL constructor breaks file:// URIs — use custom schemes; (2) subscribe method not implemented — clients get "method not found"; (3) no subscriber targeting — notifications fan out to all clients. Two canonical integration patterns derived: expose-resource-as-tool-for-agent-discoverability (workaround for client-side resource-discovery fragmentation) and subscribe-notify-for-updatable-resource (live-logs, metrics, feeds as MCP resources). First on-scope Wix ingest on the wiki; complements the Dropbox / Datadog / Cloudflare bias toward MCP-tools disclosures with the first implementer-altitude source on MCP resources. Tier-3 on-scope on vocabulary- canonicalisation grounds.

  • sources/2026-03-12-stripe-10-things-we-learned-building-for-the-first-generation-of-agentic-commerce — MCP as native transport for the Agentic Commerce Protocol (ACP). Per Stripe's 2026-03-12 retrospective, ACP PR #139 adds native MCP transport, bridging agent-tool-discovery and agentic-commerce-checkout transport into one mechanism. "Since we co-developed ACP with OpenAI in September 2025, we've shipped four releases and added ... native MCP transport." Architecturally: MCP carriage gives agentic-commerce the same discoverability and tool-shape semantics as general MCP tool registration.

  • sources/2025-04-03-redpanda-autonomy-is-the-future-of-infrastructure — Alex Gallego's founder-voice reframing of MCP as infrastructure, not just a tool-description format. Positions MCP as an intent-based integration proxy centralising connectivity, auth, audit, tracing, cost accounting at a single choke-point, canonicalising patterns/mcp-as-centralized-integration-proxy on the wiki. Reframes future MCP evolution as dynamic per-call content filtering at HBase-cell-ACL granularity via Redpanda Connect declarative pipelines (Bloblang) + code extensions (Starlark Python subset) — canonicalised as dynamic-content-filtering-in-mcp-pipeline. Load- bearing framing verbatim: "MCP is about intent, 'create a Redpanda Cluster in us-east-1', while the MCP server worries about implementing the five API calls... An intent-based proxy pushes that complexity to a central location." Canonical Redpanda instantiation: rpk connect mcp-server exposes any of ~300 Redpanda Connect connectors as an MCP tool with YAML config managing connection pooling, retries, exponential backoffs, TLS, certificates, authentication. Distinct from existing Fly.io fly mcp launch ergonomics-tax focus and from Pinterest's hosted-MCP ecosystem — Gallego's frame is MCP-as-infrastructure-choke-point, not MCP-as-managed-platform.

  • sources/2025-11-17-dropbox-how-dash-uses-context-engineering-for-smarter-ai — names MCP as "a robust protocol" while laying out the tool-inventory / context-window limitations it intrinsically surfaces; frames Dash's design as MCP-compatible but context-lean.

  • sources/2026-03-04-datadog-mcp-server-agent-tools — the most detailed MCP-design retrospective in this wiki; five patterns each a specific response to MCP-related failure modes.
  • sources/2026-04-20-cloudflare-internal-ai-engineering-stack — MCP at enterprise scale (Server Portal, proxy pattern, discovery endpoint, progressive tool disclosure).
  • sources/2026-01-28-dropbox-knowledge-graphs-mcp-dspy-dash — Josh Clemm's talk puts concrete latency numbers on MCP-at-scale degradation: simple queries taking up to ~45s via MCP vs "within seconds" against the raw index; Dash caps its context at ~100,000 tokens. Enumerates four production fixes Dash applied in response: (1) collapse retrieval tools into one "super tool" (patterns/tool-surface-minimization); (2) knowledge-graph bundles as token-efficient result compression ("modeling data within knowledge graphs can significantly cut our token usage"); (3) store tool results locally rather than inline them into the context window (new lever); (4) classifier-routed sub-agents with narrow toolsets (patterns/specialized-agent-decomposition). Frames MCP as the default "make it work" starting point and indexed retrieval as the "make it better" destination at scale.
  • sources/2026-04-16-cloudflare-email-service-public-beta-ready-for-agents — introduces a new Email MCP server on the Cloudflare MCP surface — any MCP-aware agent (Claude / Cursor / Copilot) can discover and call the Email endpoints to send and configure email with a prompt. Paired with the same Code Mode machinery that fits ~3,000 Cloudflare operations into <1,000 tokens. The post also explicitly flags the context-window-bloat failure mode of MCP — "tool definitions can consume tens of thousands of tokens before your agent even starts processing a single message" — and ships Wrangler + Skills as the "near-zero context overhead" complement for agents with bash access. Agentic Inbox additionally ships its own built-in MCP server so external agents can "draft emails for your review before sending" — the email-tier analog of the dashboard elicitation gate.
  • sources/2025-04-10-flyio-30-minutes-with-mcp-and-flyctl — canonical CLI-wrapped-as-MCP-server instance: Fly.io's flymcp exposes 2 flyctl commands (fly logs, fly status) via MCP stdio transport in ~90 lines of Go, built in "30 minutes" on mark3labs/mcp-go. Anchors patterns/wrap-cli-as-mcp-server and surfaces local-mcp-server-risk — "I don't like that I'm giving a Claude instance in the cloud the ability to run a native program on my machine" — with patterns/disposable-vm-for-agentic-loop as the natural sandbox answer. Demonstrates an agentic-observability flow over unpkg (Fly-hosted npm CDN): 10-Machine topology recited, OOM correlation, per-second incident timeline reconstructed from two read-only tools.
  • sources/2025-05-07-flyio-provisioning-machines-using-mcps — mutation-transition sequel (~27 days after the 2025-04-10 read-only prototype): the same flyctl MCP server now exposes the full fly volumes subcommand family — create / list / extend / fork / snapshots / destroy — shipped in flyctl v0.3.117. First wiki instance of patterns/wrap-cli-as-mcp-server crossing the read-only → production-mutation boundary. Load-bearing architectural thesis paragraph for natural-language-infrastructure-provisioning: "Today's state of the art is K8S, Terraform, web based UIs, and CLIs. Those days are numbered." Introduces the "Make it so" target UX (LLM scans code → presents plan → human adjusts → approves → agent executes → on failure examines logs) and CLI-refusal-as-agent- guardrail ("I would have received an error had I tried to destroy a volume that is currently mounted. Knowing that gave me the confidence to try the command"). Also gestures at MCP servers running on Fly.io's private network — "on separate machines, or in 'sidecar' containers, or even integrated into your app" — pairing with the 2025-04-08 robot-routing / long-lived-SSE framing. Names GitHub Copilot as the authoring assistant, Claude Desktop as the canonical client, and MCP Inspector (local port 6274) as the agent-free validation surface for server authors.
  • sources/2025-11-06-flyio-you-should-write-an-agent — Fly.io (Thomas Ptacek, 2025-11-06) is the wiki's first "when MCP is not needed" framing. The post's minimal-agent-loop demonstration (tool-call-loop-minimal-agent) shows that a 30-LoC Python loop against the OpenAI Responses API with a native-JSON tools list is a complete agent — no MCP involved. Explicit thesis: "we didn't need MCP at all. That's because MCP isn't a fundamental enabling technology. […] MCP is just a plugin interface for Claude Code and Cursor, a way of getting your own tools into code you don't control. Write your own agent. Be a programmer. Deal in APIs, not plugins." The claim is structural, not dismissive: MCP earns its place as an interop protocol for tools consumed by agents other people built (Claude Code, Cursor, Goose) — which is exactly the case the wiki's existing MCP instances (flymcp, systems/datadog-mcp-server, systems/cloudflare-ai-gateway's MCP Server Portal, systems/unity-ai-gateway) are designed for. The corollary Fly flags for production MCP: "one context window bristling with tool descriptions doesn't leave enough token space left to get work done" — independent confirmation of concepts/context-window-as-token-budget and the patterns/tool-surface-minimization / sub-agent (patterns/context-segregated-sub-agents) responses. Also sharpens the wiki's existing MCP-security framing ("When you read a security horror story about MCP your first question should be why MCP showed up at all") — MCP's implicit single-context-window assumption can prevent the operator from splitting tool surfaces across sub-agents, which is the structural fix for prompt-injection blast-radius (local-mcp-server-risk + untrusted-input-via-file-not-prompt).

  • sources/2026-03-10-flyio-unfortunately-sprites-now-speak-mcp — Fly.io (Thomas Ptacek, 2026-03-10). Canonical wiki statement of the MCP-is-aesthetically-wrong-for-shell-capable- agents thesis. "In 2026, MCP is the wrong way to extend the capabilities of an agent. The emerging Right Way to do this is command line tools and discoverable APIs." Load- bearing because it's the first-party statement from Fly.io — the same vendor that ships systems/flymcp, systems/fly-mcp-launch, and, in this post, sprites.dev/mcp. Introduces two distinct-from-token-budget axes of cost: progressive capability disclosure (CLIs reveal capabilities incrementally; MCP front-loads all tools) and context-as- importance-signal ("Cramming your context full of MCP tool descriptions is a way of signaling to the model that those tools are important to you"). Playwright coin-flip observation is the canonical empirical datum: "Ask claude to install Playwright and Chrome and there's a coinflip chance it sets up the MCP server. But notice that when the coin comes up tails, Playwright still works." Positional recommendation: MCP as fallback for shell-less agents (patterns/mcp-as-centralized-integration-proxy); CLI + short-prose skill for shell-capable. sprites.dev/mcp is shipped with the three-axis agent-creation guardrail (org scope × Sprite-count cap × name prefix), extending concepts/ai-agent-guardrails to the VM-lifecycle altitude. Closes with the "Fuck Stateless Sandboxes" reprise of the 2026-01-09 "Fuck Ephemeral Sandboxes" manifesto.

  • sources/2025-12-01-slack-streamlining-security-investigations-with-agents — canonical first wiki instance of MCP in an internal security-investigation agent pipeline. Slack's Security Engineering team built their prototype of Spear with a "simple 'stdio' mode MCP server to safely expose a subset of our data sources through the tool call interface" — the MCP server being the safety wrapper around the security-data surface so the agent couldn't reach beyond what the server advertised. Paired with a coding-agent CLI repurposed as execution harness. When the prototype moved to production as the Hub/Worker/Dashboard service (hub-worker-dashboard-agent-service), the post stops explicitly mentioning MCP — whether the production workers still speak MCP or now speak direct data-source APIs is not disclosed. The disclosure is valuable as the first wiki instance of MCP used inside an internal-security-operations-posture pipeline (prior ingests cover dev tooling, public registries, Cloudflare's MCP ecosystem, and the Redpanda ADP vision). See systems/slack-spear + director-expert-critic-investigation-loop.

As the wrong default (Fly.io, 2026-03-10)

Ptacek's 2026-03-10 framing locates MCP's correct role explicitly: fallback protocol for shell-less agents, not universal-integration-abstraction.

"Skills and APIs are the best way to drive Sprites. But to make that work, you need an agent that can run shell commands for itself. So you'll want to reach for MCP sessions when you're stuck with an agent that can't run commands. Thankfully, most of us aren't using those kinds of agents anymore."

The recommendation is not "don't ship MCP" — Fly.io ships sprites.dev/mcp in the same post. It is "don't make MCP the default surface when the agent has shell access." For shell-capable agents (Claude Code, Gemini CLI, Codex CLI), Fly's preferred surface is the CLI + a one-sentence skill.

See patterns/mcp-as-centralized-integration-proxy for the pattern page; concepts/progressive-capability-disclosure for the discovery mechanism the CLI path relies on; context-as-importance-signal for the attention-weighting cost axis.

As a generated interface (Cloudflare, 2026-04-13)

Cloudflare's 2026-04-13 CLI announcement reveals that the Code Mode MCP server — which fits Cloudflare's entire ~3,000-operation API into <1,000 tokens — is generated from the same TypeScript schema that produces the cf CLI, Workers bindings, wrangler.jsonc config, Cloudflare SDKs, Terraform provider, Agent Skills, and OpenAPI spec. This positions MCP as one generated surface of a unified interface schema, not a hand-maintained server (Source: sources/2026-04-13-cloudflare-building-a-cli-for-all-of-cloudflare). See also concepts/agent-ergonomic-cli and schema-driven-interface-generation.

As an agent consumption layer with permission enforcement (Cloudflare Agent Lee, 2026-04-15)

Cloudflare's 2026-04-15 Agent Lee launch is the first wiki instance of MCP deployed to end-users at measurable scale: ~18,000 daily users and ~250,000 tool calls / day across DNS, Workers, SSL/TLS, R2, Registrar, Cache, Cloudflare Tunnel, API Shield, and more (Source: sources/2026-04-15-cloudflare-introducing-agent-lee). Two architectural refinements to the protocol's consumption pattern surface in this deployment:

  • Code Mode instead of direct tool prompting. Agent Lee's MCP surface is just two tools (search + execute); all ~3,000 Cloudflare API operations are reachable through execute via generated TypeScript code. "LLMs have seen a huge amount of real-world TypeScript but very few tool call examples, so they're more accurate when working in code. For multi-step tasks, the model can also chain calls together in a single script and return only the final result, ultimately skipping the round-trips."
  • Elicitation gate at a credentialed-proxy boundary. Agent Lee routes every MCP call through a Durable Object that classifies the generated code as read or write, proxies reads directly, and blocks writes until the user approves via the dashboard elicitation UI. API keys are held inside the DO and injected server-side at forward time — they are never present in generated code. "The security boundary isn't just a sandbox that gets thrown away; it's a permission architecture that structurally prevents writes from happening without your approval." See patterns/agent-sandbox-with-gateway-only-egress. This is the first in-wiki production instance of the MCP permission system formalised at the protocol-consumer layer rather than hand-coded in the agent loop.

Quantified context-window win vs naive baseline (Project Think, 2026-04-15)

Cloudflare's 2026-04-15 Project Think launch quantifies the Code Mode compression against the explicit naive alternative for the first time (Source: sources/2026-04-15-cloudflare-project-think-building-the-next-generation-of-ai-agents):

"The Cloudflare API MCP server demonstrates this at scale. We expose only two tools (search() and execute()), which consume ~1,000 tokens, vs. ~1.17 million tokens for the naive tool-per-endpoint equivalent. This is a 99.9% reduction."

This is the same number family as the <1,000-tokens-for-~3,000- operations claim in the CLI post, now paired with the baseline it was never previously quantified against. The comparison is directional rather than a refutation of the realistic alternative — a hand-crafted tool-minimised MCP surface following patterns/tool-surface-minimization would not hit 1.17M tokens either. But as a worst-case illustration of why code-gen over tool-calls is load-bearing at scale-of-API-surface, the number is now on the wiki. See also systems/code-mode for the full framing.

Pre-connect discovery via MCP Server Card (2026-04-17)

Cloudflare's 2026-04-17 Agent Readiness Score post surfaces a draft MCP spec extension — the MCP Server Card — that lets a site publish a static JSON document describing an MCP server before any agent connects:

  • Path: /.well-known/mcp/server-card.json (with a slight variant at /.well-known/mcp.json used by some reference implementations including isitagentready).
  • Contents: server identity (name, title, version), protocolVersion, transport (e.g. streamable-http + endpoint), authentication requirements, and the full tool list with input schemas.

An agent can fetch one HTTP GET, evaluate whether the server's tools fit its need, and decide to commit to a session — no authentication dance, no protocol negotiation, no list_tools round-trip against N candidate servers. The shape is analogous to API Catalog (RFC 9727) for classical HTTP APIs but at the MCP layer.

Draft status: proposal at modelcontextprotocol/modelcontextprotocol issue #1649. Early adoption: per Cloudflare Radar on the top 200k domains, MCP Server Card + API Catalog combined appear on fewer than 15 sites. Positioned by the Agent Readiness Score as an early-adopter opportunity under the Agent Actions dimension. See systems/mcp-server-card and well-known-endpoint-discovery for the broader /.well-known/ cluster of agent-ergonomic standards this belongs to.

  • sources/2026-04-17-cloudflare-introducing-the-agent-readiness-score-is-your-site-agent-ready — canonical wiki instance for MCP Server Card + the broader agent-readiness positioning of MCP as "a first- class discovery primitive for agent actions at site level." Cloudflare's isitagentready.com itself ships an MCP server exposing a scan_site tool over Streamable HTTP — publishing its own Server Card at https://isitagentready.com/.well-known/mcp.json.
  • sources/2025-04-08-flyio-our-best-customers-are-now-robots — MCP framed as the robot interop protocol whose long-lived SSE connections are a session-affinity routing requirement on multitenant deployments. Canonical Fly.io framing: "LLMs all speak a protocol called MCP. MCP is what enables the robots to search the web, use a calculator, launch the missiles, shuffle a Spotify playlist, &c. If you haven't played with MCP, the right way to think about it is POST-back APIs like Twilio and Stripe, where you stand up a server, register it with the API, and wait for the API to connect to you. Complicating things somewhat, more recent MCP flows involve repeated and potentially long-lived (SSE) connections. To make this work in a multitenant environment, you want these connections to hit the same (stateful) instance." Canonical wiki datum for mcp-long-lived-sse and the session-affinity routing pattern. Also the first wiki disclosure of MCP as an RX-shaping protocol for platform-level routing primitives.

  • sources/2026-04-01-cloudflare-emdash-wordpress-spiritual-successor — MCP shipped as a CMS primitive: every EmDash instance runs its own built-in MCP server exposing the Admin UI's capability set. Gives an agent full programmatic management of the CMS (content, media, schema, collections) via MCP without a per-site integration. Sibling shape to the Cloudflare Email Service MCP server (2026-04-16) and the Agent Lee MCP surface (2026-04-15) — MCP is now the default admin-surface discovery protocol for new Cloudflare products. First wiki instance of MCP in a content- management / CMS context.

  • sources/2025-05-19-flyio-launching-mcp-servers-on-flyio — fly mcp launch — remote-MCP-server deploy subcommand (flyctl v0.3.125). Canonical wiki instance of remote-mcp-server-via-platform-launcher + the canonical motivation statement for mcp-client-config-fragmentation. The post leads with the three-shape MCP server taxonomy ("basically two types of MCP servers. One small and nimble that runs as a process on your machine. And one that is a HTTP server that runs presumably elsewhere and is standardizing on OAuth 2.1. And there is a third type, but it is deprecated.") and the config-file-fragmentation complaint naming Claude Desktop's ~/Library/Application Support/Claude/claude_desktop_config.json (MCPServer key) vs Zed's ~/.config/zed/settings.json (context_servers key) vs OS-dependent per-tool variants. One command handles it: fly mcp launch "npx -y <server>" --claude --server <name> --secret K=V deploys a Fly Machine running the stdio MCP server as a remote HTTP endpoint, with bearer-token auth on by default on both ends, client-config JSON rewritten in place for 6 built-in clients (Claude, Cursor, Neovim, VS Code, Windsurf, Zed), --secret flags piped through to Machine secrets, and all Fly platform knobs (auto-stop, Flycast, Volumes, region, VM size) available. Pairs with the 2025-04-10 flymcp post to span both axes of MCP-server ergonomics: wrap a local CLI as a local MCP server (flymcp, patterns/wrap-cli-as-mcp-server) and deploy a local MCP server as a remote MCP server (fly mcp launch, remote-mcp-server-via-platform-launcher). Beta status acknowledged — "examples as shown are thought to work. Maybe."

As an enterprise hosted ecosystem (Pinterest, 2026-03-19)

Pinterest's 2026-03-19 retrospective (sources/2026-03-19-pinterest-building-an-mcp-ecosystem-at-pinterest) is the wiki's first canonical enterprise-hosted MCP ecosystem at measurable scale: 66,000 invocations/month across 844 MAUs, saving an estimated ~7,000 engineer-hours/month as of January 2025. The post's substance is a set of opinionated architectural choices — each explicitly reasoned — that together constitute the hosted-mcp-ecosystem pattern:

  • Hosted over local on the paved path (local-mcp-server-risk). Local stdio servers reserved for experimentation; production is always cloud-hosted so "internal routing and security logic can best be applied."
  • Many small domain-specific servers (Presto, Spark, Airflow, Knowledge) over one monolith. Reasoning: per-server access control + context-window hygiene. patterns/tool-surface-minimization applied at the server-decomposition axis.
  • Central MCP registry as source of truth for approved-for-production servers. Dual-surface: human Web UI + AI-client API with pre-flight authorization. Canonical wiki instance of mcp-registry.
  • Unified deployment pipeline — platform handles deployment + scaling; teams define only tools + per-tool policy.
  • Two-layer auth — end-user JWTs validated at Envoy + SPIFFE mesh identities for service-only flows + in-process @authorize_tool(policy='…') decorator (per-tool-authorization-decorator) for fine-grained per-tool policy.
  • Business-group-based access gating on sensitive servers — Presto MCP is reachable from broad surfaces like the company chat, but only specific business groups (Ads, Finance, specific infra teams) can open a session.
  • Elicitation gate + human-in-the-loop for mutations — MCP's elicitation primitive confirms dangerous actions; agent guidance mandates human approval (optionally batched) before sensitive / expensive actions.

Contrast with the MCP OAuth spec

Pinterest explicitly rejects the spec's per-server OAuth consent flow for internal traffic:

"The MCP specification defines an OAuth 2.0 authorization flow where users explicitly authenticate with each MCP server, typically involving consent screens and per-server token management. Our approach is different: users already authenticate against our internal auth stack when they open a surface like the AI chat interface, so we piggyback on that existing session. There is no additional login prompt or consent dialog when a user invokes an MCP tool."

This is the wiki's first canonical enterprise-SSO piggyback statement — a deliberate counter-positioning to the protocol's native-per-server-OAuth shape, applicable inside-the-org but not for cross-org / public MCP. The pattern transfers wherever an organisation already has an SSO-issued JWT that carries identity + group claims.

Three integration surfaces named

Pinterest's MCP is integrated into (a) an internal LLM web chat used by the majority of Pinterest employees daily, (b) AI bots on the internal chat platform with per-channel tool visibility ("Spark MCP tools are only available in Airflow support channels"), and (c) IDE integrations. Each handles OAuth transparently via the registry API. Canonical wiki datum for MCP-at-enterprise-scale-integrated-into-existing-surfaces.

Observability is baked in

"All MCP servers at Pinterest use a set of library functions that provide logging for inputs/outputs, invocation counts, exception tracing, and other telemetry for impact analysis out of the box."

North-star metric: time saved. Owner-supplied minutes-saved × invocation counts → ~7,000 engineer-hours/month. Directional ("order-of-magnitude view"), owner-attested, but transparent about both properties.

Cloudflare OS: MCP tool access is not data authorization (2026-08-05)

Cloudflare OS consumes existing MCP servers through MCP Server Portals, but explicitly identifies MCP's boundary: knowing which tools an agent can call does not reveal which underlying resources the tools returned or control where data derived from them can flow. Cloudflare OS supplies that missing layer through service-specific Gatekeepers and observation-coupled authorization. This is a third answer to MCP's documented lack of built-in multi-tenancy/auth: beyond a central proxy or external policy evaluator, retain concrete read provenance and re-check it at collaboration and egress sinks. (Source: sources/2026-08-05-cloudflare-os-an-open-platform-for-agents-apps-and-work)

Agentic Internet: MCP as the "callable" standard (2026-08-06)

In Cloudflare's Agentic Internet framing, MCP is one of the open standards (alongside x402, Web Bot Auth, PACT) that keep the rails neutral. The browser-side companion WebMCP exposes a page's actions as MCP-style tools via document.modelContext.registerTool — making the tool contract explicit and reusing the user's in-page session — while Code Mode has agents write code against those tools rather than emit prose tool calls. (Source: sources/2026-08-06-cloudflare-building-an-open-agentic-internet)

MCP goes stateless: the 2026-07-28 spec (2026-08-06)

The 2026-07-28 specification turned MCP into a fully stateless protocol — the single biggest change since launch. The mandatory initialize/initialized handshake, the Mcp-Session-Id header, and protocol-level sessions are removed from the core request path. Each request self-describes (protocol version, client identity, capabilities); a server can be inspected optionally via server/discover. A request can arrive, invoke a tool/prompt/resource, and return a result with no session to store, migrate, or drain (Source: sources/2026-08-06-cloudflare-the-next-generation-of-mcp). This is the wiki's canonical instance of concepts/stateless-compute.

What this changes, per Cloudflare's framing:

  • McpAgent is no longer required. Because there's no protocol session to hold, MCP servers run as ordinary HTTP workloads on request-scoped Workers — no stateful infrastructure. Durable Objects remain the right primitive when the application needs state, but MCP itself no longer requires one to speak the protocol. See concepts/serverless-compute + concepts/scale-to-zero.
  • Elicitation without an open stream. Server-initiated requests like elicitation/create previously needed an open stream. The new Multi Round-Trip Request (MRTR) pattern returns an input_required result; the client collects the answer and retries the operation with it. Breaking change, but stateless and simpler.
  • HTTP infra understands MCP. New Mcp-Method and Mcp-Name headers (plus MCP-Protocol-Version) on Streamable HTTP let gateways / rate limiters / WAFs decide from headers without parsing JSON-RPC bodies — canonical protocol-metadata-in-http-headers.
  • Cache stability. ttlMs + cacheScope hints on the */list and resources/read results, plus deterministic tool-catalog ordering, keep upstream prompt caches stable across reconnects (concepts/context-engineering).
  • Authorization tightens. Preference order pre-registered → CIMD → DCR (deprecated, removal after summer 2027); RFC 9207 issuer iss check; RFC 8707 audience-restricted tokens bound to the canonical server URI. Implemented by Workers OAuth Provider.
  • Formal feature lifecycle. Active / Deprecated / Removed with a ≥12-month window; Roots, Sampling, Logging, DCR, and the legacy HTTP+SSE transport are deprecated. New capabilities (MCP Apps, Enterprise-Managed Authorization, Tasks) move through an extensions framework. See feature-lifecycle-deprecation-policy.
  • SDKs. createMcpHandler graduated from the Agents SDK into the official MCP TypeScript SDK, which was replatformed from Node.js to Web Standards (better Bun/Deno/Workers interop). One /mcp endpoint serves both the new protocol and legacy 2025 stateless clients; deliberate session-dependent servers migrate via patterns/shadow-migration. In production: Sentry shipped on it pre-finalization without breaking prod; Cloudflare's Code Mode MCP server scaled to thousands of req/s and billions of tool calls.

Contradiction

Earlier sections of this page (and the wiki's earlier MCP coverage) describe MCP as a stateful protocol requiring a persistent connection — Mcp-Session-Id-tagged sessions, session affinity / sticky routing for the long-lived SSE transport, and (on Cloudflare) an McpAgent backed by a Durable Object to hold that session. That was accurate for the pre-2026-07-28 transports.

  • Old position (MCP origins → 2025 Streamable HTTP, tagged sse, long-lived-connection, session-affinity): MCP begins with an initialize/initialized handshake, assigns a session id, and every request resolves that session; well-behaved remote servers manage sticky sessions, held-open streams, and message replay. Server-initiated elicitation rides an open stream.
  • New position (2026-07-28, Source: sources/2026-08-06-cloudflare-the-next-generation-of-mcp): the handshake, session header, and protocol sessions are removed from the core path; MCP is stateless; elicitation is re-expressed as MRTR retries with no open stream; the legacy HTTP+SSE transport is deprecated (≥12-month window).

Both are correct for their eras. The /mcp endpoint serves legacy stateless 2025 clients alongside the new protocol during the deprecation window, so the older sessionful shape persists in the field until drained — see patterns/shadow-migration.

AWS Well-Architected reading of the stateless spec (2026-09-01)

AWS independently read the same 2026-07-28 revision against the Well-Architected Agentic AI Lens, mapping the protocol changes onto all six pillars and arguing the stateless core natively achieves what the old session-based protocol could only reach through compensating AWS infrastructure (Source: sources/2026-09-01-aws-mcp-went-stateless-is-your-aws-mcp-server-deployment-well-architected). It frames the migration as deleting infrastructure that existed only to preserve sessions:

  • Deployment table. ALB stickiness → round-robin; session state in DynamoDB / ElastiCache → server-minted identifiers as tool arguments (server-minted-continuation-token); Lambda workarounds → Lambda as a first-class host; body-parsing gateways → header routing (protocol-metadata-in-http-headers); Last-Event-ID stream resumption → idempotent tools + client re-issue (idempotent-retry-on-broken-stream).
  • requestState as continuation token. MRTR's opaque token carries resume context so any instance continues an interrupted interaction; servers must protect it with HMAC/AEAD and enforce ownership per identifier because it is model-visible (server-minted-continuation-token).
  • Observability in-protocol. W3C Trace Context in _meta traces end-to-end through OpenTelemetry / CloudWatch; resultType (complete/input_required) plus Mcp-Method/Mcp-Name give per-operation signals without body parsing; protocol logging deprecated for stderr/OTel.
  • Protocol-declared caching. ttlMs + cacheScope are now required on list/resource-read results; cacheScope: "public" on tenant-specific data is flagged as a multi-tenant disclosure risk.
  • Standardized error codes. -32000..-32019 implementation-defined; -32020..-32099 reserved for MCP — canonical retry/backoff/circuit-break signals.
  • Cost / sustainability. delete-session-infrastructure — a two-node ElastiCache cache.t4g.micro session store ≈ $23/mo, but the real win is eliminating a whole class of infra + sticky-routing's uneven load; teams behind AgentCore Gateway get protocol management and back-compat handled for them.

This is a second Tier-1 source corroborating the stateless shift, adding the AWS-service deployment specifics, the Well-Architected framing (well-architected-framework), and server/discover for optional capability negotiation.

Seen in

  • sources/2026-09-25-databricks-from-data-to-dialogue-how-sp-global-energy-made-its-structured-data-estate-conversational — Managed MCP server auto-generated per Genie space + FastMCP composition + external-consumer bridge. S&P Global Energy exposes its structured-data estate to agents by making every Genie Agent a Databricks-managed MCP server at /api/2.0/mcp/genie/{genie_space_id} — nothing to deploy or host — with a two-tool ask-then-poll surface (genie_query_space submits a natural-language question; genie_poll_response polls by conversation + message ID for the SQL + result set), executing asynchronously against a SQL warehouse. The managed servers are governed by Unity Catalog and authenticated by the platform ("we inherited the [security layer] we already had"). Because MCP is an open standard, the same endpoints serve internal agents, customer-facing AI, and external customers' own MCP-compatible agents — one bridge, every client crosses it. A FastMCP proxy composes the scoped per-group Genie MCP servers into per-commodity composite endpoints with name-spaced tools (patterns/mcp-as-centralized-integration-proxy).

  • sources/2026-09-01-databricks-how-we-eliminated-1-million-a-year-of-wasted-ai-agent-spend — MCP tool signatures are kept deliberately under-specified (tool-selection-accuracy) to save the per-call token cost of parameter descriptions. That looseness lets a model fill gaps with reasonable guesses; tools that accept only one shape then crash, producing silent tool-failure cost. Databricks' remedy is to build tools that adapt to how LLMs naturally call them.

  • sources/2026-09-22-databricks-genie-one-mcp-give-any-ai-agent-the-right-business-context — MCP as the governed-analytics access surface + MCP Apps interactive views. Databricks' Genie One MCP server exposes governed conversational analytics as five tools (genie_ask / genie_poll_response / genie_get_query_result / genie_cancel_response / view_ask) to any MCP-compatible agent (ChatGPT, Claude, Copilot, Claude Code), with a warehouse_id _meta parameter pinning execution. Two protocol-level data points: (1) MCP Apps (ext-apps) — an extension letting the server return an interactive rendered view (visuals, metrics, ontology citations) instead of plain text, with automatic text-only fallback on clients that don't support it; view_ask is the MCP-Apps variant of genie_ask. (2) External MCP servers as Unity Catalog securables governed through standard grants, with OBO recommended so the end user's identity (and UC row filters / column masks) flows through — reinforcing the "register an external MCP as a UC securable" model from the 2026-05-20 governance post. Also names the scoped Genie Agent MCP server (/api/2.0/mcp/genie/{genie_space_id}) as the single-curated- domain alternative, and the "tune Genie in Databricks, not from the client system prompt" operational guidance.

Last updated · 766 distilled / 2,225 read