# Model Context Protocol Source: John Bradshaw — https://bradshaw.cloud URL: https://bradshaw.cloud/strategy/mcp/ Type: insight Date: 2026-04-01 Updated: 2026-08-19 Tags: Protocol, AI, Integration > How to assess MCP as an integration contract: where it reduces repeated connector work, and where identity, trust, and operating responsibility remain. ## How MCP works ### Without a shared contract: N × M integration work Five AI applications and eight systems can create forty client-to-system connectors. Each connector needs an auth model, schema handling, failure path, and an owner. **Business take:** The multiplication is a planning risk, not just a coding problem. Each new client or system can create another support surface unless a shared contract removes part of the repeated work. ### With MCP: a shared contract, not automatic connectivity A compatible client and server can use the same protocol instead of a bespoke connector for that pair. The model moves towards N + M only when revisions, transports, identity, scope, and operations are compatible. **Business take:** The gain is reduced protocol duplication. It does not remove the work of deciding what an agent may do, how a token is scoped, or who responds when a tool action fails. ### MCP architecture: hosts, clients, servers The host is the AI application. It manages clients that connect to MCP servers. A server exposes tools, resources, or prompts through JSON-RPC; it is not necessarily one tool or one conventional server. **Business take:** The important boundary is responsibility: which principal is acting, what scope is granted, and who owns the server and its tool definitions after the pilot ends? ### An airline agent: define the trust boundary first An agent might use separate servers for flight status, rebooking, and loyalty data. The shared protocol can simplify the interaction shape; it does not decide who may change a booking or see customer data. **Business take:** Before replacing connectors, name the irreversible actions, token scope, approval step, audit trail, and failure owner. A protocol decision is only useful when those controls are concrete. ### MCP has a current spec and active governance MCP is an Agentic AI Foundation project. The 2026-07-28 specification defines a stateless core, header-based routing, and opt-in extensions. **Business take:** That makes MCP reasonable to evaluate as a common contract. It does not make a server safe by default or remove the need to test compatibility, governance, and exit cost in your own estate. ## Frequently asked questions ### What is the Model Context Protocol (MCP)? MCP is an open JSON-RPC protocol for connecting AI applications with tools, resources, prompts, and related capabilities. A compatible client and server can use the same interaction model instead of carrying a bespoke connector for that pair. Compatibility still depends on the protocol revision, transport, identity model, scope, network path, and the server operator. ### What problem does MCP solve? It can reduce the N × M integration surface. Without a shared protocol, five AI applications and eight systems can imply forty client-to-system connectors, each with its own auth, schema, error handling, and owner. MCP can move the protocol work towards N + M, but that is a planning model—not an automatic saving. The integration still needs compatible behaviour, authorisation, observability, and support. ### How does MCP work — what are hosts, clients, and servers? Three roles. The host is the AI application. It manages MCP clients, which connect to MCP servers. A server exposes one or more tools, resources, or prompts; it is not necessarily a single tool or a conventional infrastructure server. The important design question is ownership: which principal is acting, what scope is granted, and who investigates a failed or unexpected tool call? ### Is MCP a single-vendor protocol or genuine industry infrastructure? MCP is an Agentic AI Foundation project under the Linux Foundation and has an active specification and implementation ecosystem. That is a reason to evaluate it as a common contract, not a reason to treat it as mandatory. A production decision should rest on your target clients, server maturity, authorisation model, audit requirements, and exit cost. ### When should we use MCP instead of building a custom integration? Use MCP when several compatible AI clients need a stable, governed way to reach the same system and you can own the server as production infrastructure. A bespoke connector can still be the lower-risk choice for a single bounded workflow, an unsupported client, or an API whose permissions cannot be constrained safely. Start with one reversible use case, then prove the identity, audit, and support model before widening access. ## Diagrams Standalone SVG diagrams, licensed CC BY 4.0 with attribution to John Bradshaw — link back to https://bradshaw.cloud/strategy/mcp/ when embedding. - [Without a shared contract: N × M integration work (SVG)](https://bradshaw.cloud/strategy/mcp/diagrams/problem.svg) - [With MCP: a shared contract, not automatic connectivity (SVG)](https://bradshaw.cloud/strategy/mcp/diagrams/solution.svg) - [MCP architecture: hosts, clients, servers (SVG)](https://bradshaw.cloud/strategy/mcp/diagrams/architecture.svg) - [An airline agent: define the trust boundary first (SVG)](https://bradshaw.cloud/strategy/mcp/diagrams/whatsapp.svg) - [MCP has a current spec and active governance (SVG)](https://bradshaw.cloud/strategy/mcp/diagrams/ecosystem.svg) ## Related - [MCP security & governance](https://bradshaw.cloud/writing/mcp-security-governance/) — the control map for taking protocol adoption into production. - [Agentic AI patterns](https://bradshaw.cloud/strategy/agentic-ai/) — the architecture choices that determine what MCP-connected agents should be allowed to do. - [View all strategy insights](https://bradshaw.cloud/strategy/)