Established operators are useful because they expose concrete decisions made under real product constraints. They are not interchangeable benchmark laboratories. A product manual establishes supported behavior; an engineering post establishes what its authors report; neither reveals all incidents, operating costs, or customer workloads.
All sources below were checked on 15 October 2026. Living documentation may change. We use five cases to challenge our design, not to borrow authority for an untested implementation.
GitHub: a catalog needs controls
GitHub’s official server supports toolsets, individual tool selection, exclusions, and read-only configuration. Its documentation states that read-only mode takes precedence over tool inclusion. It also distinguishes lockdown filtering from an authorization boundary: filtering public repository content does not reduce everything the underlying credential can access. Official configuration documentation.
Transferable lesson: distinguish the surface offered to a host from the authority of the credential behind it. Give consumers a way to limit the catalog, and enforce dangerous-operation policy in the provider as well as the host.
Evidence limit: the configuration manual is strong evidence of product controls, not a measured rate of prevented prompt injection. Do not describe lockdown as a complete security solution or assume every host honors every configuration path.
Our design decision: the incident provider starts with a small read surface. Write permission is checked at execution even if a write tool is discoverable. A customer’s deployment policy can additionally hide writes entirely.
Stripe: onboarding and revocation are product features
Stripe documents OAuth for interactive access and agent API keys for independent persistent access. Its controls distinguish live and sandbox environments and include administrative MCP access and revocation. Its tool surface includes API search/details and separate read/write entry points, rather than requiring every API method to be a separate model-visible tool. Stripe MCP documentation.
Transferable lesson: successful customer onboarding includes account selection, environment, permission grants, revocation, and support diagnostics. A working endpoint is only one part of that experience.
Evidence limit: this is supported product behavior, not proof that the same tool design is optimal for a much smaller incident product. Authentication policies are time-sensitive; follow the live provider instructions when connecting, rather than copying old secret-key examples.
Our design decision: show tenant and environment clearly, ship a read-only first workflow, and provide a documented revoke-and-reconnect path. Do not use a single organization-wide superuser credential as the default integration.
Cloudflare: catalog size can change the interface
Cloudflare’s February 2026 Code Mode account describes exposing its broad API through discovery and execution capabilities. It reports a compact initial tool surface rather than loading definitions for thousands of endpoints. Its engineering article and published server repository make the approach inspectable.
Transferable lesson: when the API is large and tasks require composition, exposing code over a constrained capability surface can reduce repeated model round trips and catalog overhead.
Evidence limit: an initial token footprint is not end-to-end task cost, latency, or correctness. Generated code adds runtime isolation, resource limits, credential mediation, and per-operation authorization requirements. A generic execute tool must not bypass controls enforced on individual operations.
Our design decision: begin with four curated tools. Introduce programmable composition only if measurements show the small surface is inadequate. Adopting a large-provider architecture before encountering its problem would add work without evidence.
Cloudflare again: transport state has operational consequences
Its August 2026 account explains how earlier protocol sessions complicated autoscaling, deploys, and instance loss, and why the new stateless request model fits ordinary HTTP infrastructure more naturally. The next generation of MCP.
Transferable lesson: remove accidental routing dependencies. A request should not require reaching the particular instance that previously handled a handshake when the business operation itself needs no such affinity.
Evidence limit: stateless protocol requests do not make databases, workflows, consent grants, subscriptions, or rate limits stateless. The article supports a hosting design direction, not the capacity or availability of our proposed fleet.
Our design decision: use stateless request handlers with external durable business state. Treat compatibility with older clients as an explicit supported mode, and load-test the actual mix.
Anthropic: avoid transporting every intermediate result through the model
Anthropic’s November 2025 engineering account identifies tool definitions and intermediate results as sources of context overhead. It describes loading capabilities on demand and composing calls in code, while acknowledging the need for a secure execution environment. Code execution with MCP.
Transferable lesson: separate computation and data movement from what the model needs to read. Join and filter structured evidence in code when that preserves the information needed for the decision.
Evidence limit: the article’s illustrative token savings do not establish a universal percentage improvement. Its runtime pattern must be evaluated with your tasks, models, tool schemas, and security constraints.
Our design decision: the worked client joins small structured results deterministically. The later model evaluation must test whether the selected evidence is sufficient, including truncated results and ambiguous matches.
Block: the data destination matters
Block’s security team published a March 2025 account of building and securing MCP integrations for goose. It discusses the consequences of exposing confidential data to an agent that uses a third-party model provider. The named authors and organizational context make it a useful firsthand security perspective. Securing the Model Context Protocol.
Transferable lesson: evaluate the full data path, including the model provider and logs, rather than stopping at server authentication.
Evidence limit: the article predates the 2026 protocol. Its local deployment assumptions should not be copied into a modern remote architecture. It is an operator account, not a controlled safety study.
Our design decision: data classification and permitted destinations are part of connection onboarding. Read-only access does not waive restrictions on disclosure.
What the cases collectively support
Our synthesis is that mature MCP integration is a product and systems problem built around a shared protocol. The recurring work is capability selection, authority management, data movement, compatibility, and operation ownership.
This is an inference from the cases, not a formal industry survey. The sources do not tell us that all providers use the same implementation, that MCP always improves productivity, or that a particular number of tools is optimal.
| Observation | Decision to test in our system | Evidence needed locally |
|---|---|---|
| Catalog controls exist in mature products | Small default surface with optional expansion | Selection accuracy and task coverage |
| Permission and environment UX are explicit | Guided onboarding and revocation | Completion and denial tests with real identity infrastructure |
| Large catalogs motivate code execution | Keep it an option, not a default | End-to-end task quality/cost comparison |
| Stateless transport simplifies hosting | Externalize durable business state | Restart, concurrency, and compatibility tests |
| Data can flow beyond the source service | Enforce destination and disclosure policy | Cross-source adversarial scenarios |
A source discipline worth keeping
Prefer a versioned specification for protocol requirements, official code or product documentation for supported behavior, and firsthand engineering accounts for implementation experience. Treat issue reports as evidence that a scenario occurred, not a prevalence estimate.
We intentionally do not turn stars, installation counts, vendor slogans, or a successful demo into evidence of production reliability. The next chapter is a proposed provider design. It must earn confidence through its own tests.