Model Context Protocol (MCP) is an open standard for connecting AI applications to the systems where data and capability live: databases, file systems, SaaS APIs, internal services, developer tools. Introduced by Anthropic in late 2024 and adopted broadly across the industry since, MCP defines a common way for an AI application (the host: a chat assistant, an IDE copilot, an agent runtime) to discover and use external capabilities through standardized servers, replacing the per-app, per-integration custom connectors that preceded it.
The problem it solves is the integration combinatorics that throttled the assistant era. Before a standard, every AI application built its own connector to every system it needed (the N×M problem: N applications times M data sources, each pairing a bespoke integration), which meant capability was duplicated, quality was uneven, and most systems were never connected to most assistants at all. MCP's wager is the USB-C analogy its documentation embraces: one protocol between hosts and capability servers, so a connector built once (the Postgres server, the GitHub server, the internal-CRM server) works with every MCP-speaking application, and the integration economy shifts from pairwise builds to an ecosystem of reusable servers.
The architecture is deliberately simple. An MCP server is a lightweight program that exposes capabilities from some system; an MCP client lives inside the host application and maintains a connection to each server; the protocol (JSON-RPC over stdio for local servers, HTTP-based transport for remote ones) defines how clients discover what a server offers and invoke it. Servers expose three primitive types: tools (model-invoked actions: run this query, create this ticket, send this message), resources (application-controlled data the host can read into context: this file, this schema, this document), and prompts (user-invokable templates the server contributes). The host application orchestrates: it decides which servers to connect, what the model sees, and (decisively, for safety) what gets executed under what approval.
The strategic significance outgrew the plumbing within a year. MCP became the de facto interface layer of the agent era: the major model providers and AI applications adopted client support, the server ecosystem grew into the thousands (official servers for the major SaaS platforms, community servers for the long tail, internal servers as the new enterprise integration pattern), and the protocol absorbed the roles that "plugins" and per-vendor function-calling ecosystems had partially played. For enterprises, MCP reframed a familiar question: connecting AI to internal systems stopped being a per-assistant project and became the design of an internal MCP server estate, with all the governance questions (authentication, authorization, audit, least privilege) that real integration always carries.
This page covers how the protocol actually works, the server ecosystem and the enterprise integration pattern, the security model and its sharp edges, and the adoption judgments that separate working MCP estates from connector sprawl with a new acronym.
The integration wall is what every assistant project hit first. The model is capable; the value is in the company's systems (the CRM, the warehouse, the ticketing system, the codebase); and the gap between them was, before standardization, a custom engineering project per connection: bespoke function-calling schemas, per-app plugin formats, hand-rolled API wrappers, each locked to one host application and one vendor's conventions. The result was predictable: integration effort dominated assistant projects, connectors could not be shared across tools, and the long tail of internal systems never got connected at all.
MCP's design borrows a proven playbook. The explicit model is the Language Server Protocol (LSP), which solved the same combinatorics for code editors (every editor times every language) by standardizing the middle; MCP applies the move to AI capability: a common protocol, capability discovery at connection time (the client asks the server what it offers; nothing is hardcoded), and a deliberately small surface (three primitives, JSON-RPC, two transports) that is easy to implement in an afternoon for a simple server. The simplicity is strategic: server-building had to be cheap enough that the ecosystem would actually fill in the long tail, and it did.
The three primitives divide the labor deliberately. Tools are model-controlled: the model decides (within the host's approval regime) to invoke them, which makes them the protocol's action surface and its risk surface. Resources are application-controlled: the host decides what data enters context, which keeps context assembly a deliberate act rather than a model whim. Prompts are user-controlled: pre-built interactions the server offers for humans to invoke. The division encodes a safety philosophy: actions, data, and user intent have different control planes, and conflating them (everything as a tool the model can call) is the design smell the primitives exist to prevent.
A request's lifecycle makes the roles concrete. The host connects to a configured server (launching a local process or reaching a remote endpoint), the client performs the handshake (capabilities, protocol version), and discovery returns the server's offerings (tool schemas with descriptions, resource listings). When the user asks something requiring capability, the host includes the relevant tool schemas in the model's context; the model emits a tool call; the host (per its approval policy: auto-approve, prompt the user, or deny) executes the call through the client; the server performs the action against the underlying system and returns results; the host feeds results back to the model, which continues. Every step has a controller, and the protocol's discipline is keeping those controllers explicit.
What MCP deliberately does not do also defines it. It does not specify the model (any LLM behind any host can drive MCP tools), does not own orchestration (how an agent plans multi-step work is the host's affair), does not replace APIs (servers wrap existing APIs; the underlying systems' interfaces remain authoritative), and does not solve authorization by itself (it carries the machinery: the OAuth-based flows for remote servers arrived in protocol revisions, but who may do what remains the estate's design problem). MCP is the wire and the grammar; the intelligence and the governance remain where they were, which is the correct reading of every protocol that ever succeeded.
The server ecosystem stratified quickly into recognizable tiers. Official and vendor-maintained servers for the major platforms (the cloud providers, the big SaaS suites, databases, browsers, developer tools), with vendor maintenance as the quality signal; community servers covering the long tail (thousands of them, with the quality variance any open ecosystem carries); and registries and marketplaces emerging as the discovery-and-trust layer (curated catalogs, signing and verification mechanisms maturing in response to the obvious supply-chain question). The practical enterprise stance toward third-party servers mirrors open-source dependency policy generally: vendored sources, version pinning, review before adoption, and an internal allowlist rather than a free-for-all.
The internal server estate is the enterprise integration pattern. The recurring design: a small set of internal MCP servers, each wrapping a domain's systems (the customer-data server fronting the warehouse's governed views, the ticketing server, the deploy-tools server, the knowledge-base server), built by the platform or domain teams that own the underlying systems, published in an internal registry, and consumed by whatever AI applications the organization runs (the chat assistant, the IDE tooling, the agent runtimes). The estate pattern carries the familiar platform virtues: capability built once and reused across hosts, ownership aligned with the owning team (the data-mesh instinct applied to AI capability), and a governable surface (the server is where policy attaches) instead of a thousand direct API integrations from prompts.
Server design quality is the new integration craft. The difference between a good and bad MCP server is the difference between a usable and dangerous one: tool descriptions written for model comprehension (the description is a prompt: ambiguous descriptions produce wrong invocations), schemas that constrain inputs honestly (enums and formats over free strings), granularity tuned to intent (a "create\_invoice" tool, not a raw "execute\_sql" tool, for the finance estate), errors that the model can act on (structured, explanatory, recoverable), pagination and result-shaping that respect context budgets (returning 10,000 rows into a context window is a denial-of-service against your own model), and read/write separation (the read server and the write server as different trust grants). The craft is teachable and checklist-able, and organizations are converging on internal server standards exactly as they once did on API style guides.
The protocol's evolution keeps tracking the agent era's needs. The remote-transport and authorization work (OAuth-based flows, resource indicators) matured the hosted-server story beyond the local-process origins; registry and discovery standardization is following; and multi-server composition (agents working across many servers in one task) is the operative pattern that pushes on context budgets (every connected server's tool schemas consume context) and on host-side routing (which servers to surface for which task). The steering of the protocol moved toward open governance with broad industry participation, which is what the USB-C ambition requires: a standard owned by everyone is the only kind that ends integration wars rather than starting one.
And the competitive frame clarified: MCP versus nothing, not MCP versus APIs. The underlying systems keep their APIs; MCP servers are the AI-facing adapter layer, and the alternatives that matter are the older patterns it absorbs (per-vendor plugin formats, hand-rolled function-calling integrations, screen-scraping agents) rather than the APIs it wraps. The strategic question for a platform owner is no longer whether to expose capability to AI applications but in what shape: and the emerging answer (a governed MCP server over the platform's governed APIs) keeps the integration investment in exactly one reusable place.
The threat model changed when the model got hands. A chat assistant that only talks can at worst say something wrong; an MCP-connected host can read files, query databases, send messages, and change systems, which makes the AI application's security perimeter suddenly include every connected server's capability set. The foundational discipline is least privilege at the server boundary: servers scoped to the minimum capability their purpose requires (read-only servers wherever reading suffices, narrow tools over general ones, the database server that exposes three governed queries rather than raw SQL), credentials scoped per server (the server's service account, not the user's god-token), and the blast-radius question asked at design time: what is the worst action this server makes possible, and who approved that possibility?
Prompt injection is the era's signature attack, and MCP widens its consequences. The pattern: malicious instructions hidden in content the model reads (the web page, the email, the document, the ticket) hijack the model's behavior, and with tools attached, the hijack becomes action: the email that instructs the assistant to forward the inbox, the document that instructs the agent to exfiltrate the file it can read through one server to the channel it can write through another (the lethal-trifecta shape: private data access plus untrusted content plus an egress channel). The defenses are layered and none is sufficient alone: host-side approval gates on consequential actions, server-side scoping (the server that cannot exfiltrate because it cannot write), content provenance awareness (untrusted content treated as untrusted), and the architectural instinct to keep read-everything and write-anywhere capabilities out of the same session.
The server supply chain is the second front. A malicious or compromised server is code running with real credentials (local servers run as processes on the user's machine; remote servers hold service credentials), and the attack catalog arrived on schedule: typosquatted servers, tool-description injection (the server whose tool descriptions carry hidden instructions to the model), rug-pulls (the benign server that turns malicious in an update), and the confused-deputy patterns where a server's legitimate authority gets misdirected. The countermeasures are dependency hygiene transplanted: allowlisted registries, version pinning, signature verification as it matures, review of server code and tool descriptions before adoption, and runtime monitoring of what servers actually do versus what they declared.
Authorization is where enterprise adoption gets serious. The questions that the protocol's OAuth machinery carries but does not answer: does the AI act with the user's identity and permissions (the delegation model, correct for assistants) or with its own service identity (the automation model, correct for pipelines), how are scopes mapped from human-grained roles to tool-grained capabilities, where is the audit log of which principal invoked which tool with which arguments (the answer must be: everywhere, immutably), and who reviews the standing grants as the estate grows. The mature shape borrows from the zero-trust playbook: per-server identity, short-lived credentials, capability-grained scopes, centralized policy at an MCP gateway tier (the pattern emerging for exactly this: a policy-enforcing proxy in front of the server estate), and audit as a first-class output.
And human approval is the backstop that needs design, not just existence. Approval fatigue is the failure mode: a host that prompts for everything trains its user to click yes forever, which is approval theater. The working pattern tiers consequence (auto-approve the read of a public document, prompt with diff for the database write, require explicit confirmation with explanation for the irreversible or external-facing action), makes the approval informative (what exactly will run, against what, with what arguments), and treats every auto-approval rule as policy with an owner. The protocol gives hosts the hooks; the safety lives in how deliberately they are used, which is the recurring sentence of this entire security section.
Start from the use case, not the protocol. The working adoption sequence mirrors every platform discipline in this glossary: pick one or two AI applications with real users and a concrete capability gap (the support assistant that needs ticket and customer context; the engineering copilot that needs the internal service catalog), build or adopt the two or three servers that close that gap (governed, scoped, owned), and let the estate generalize from working examples. The anti-pattern arrived with the hype: the MCP-everything program that wraps every internal API in a server nobody's assistant asked for, producing an integration estate with the maintenance bill of SOA and the usage of a demo.
Treat servers as products with owners, because they are. Each internal server carries the data-as-a-product checklist transplanted: a named owning team (the team that owns the underlying system), documented capability and scope (what it can do, deliberately, and what it cannot), versioned releases with deprecation discipline (hosts and agents are consumers; breaking a tool schema is breaking a contract), quality bars (tool descriptions tested against the models that will read them: the eval discipline extended to integration), and a registry entry that makes discovery and trust legible. The estate that skips this becomes connector sprawl with a new acronym, which is the failure mode the standard was supposed to end.
Wire the governance in at the gateway tier. The pattern consolidating across enterprise deployments: an MCP gateway (or policy proxy) between hosts and the server estate, carrying authentication and identity mapping, capability-grained authorization policy, rate and budget limits (agents can be enthusiastic), full audit logging of tool invocations, and the allowlist of which hosts may reach which servers. The gateway is where the security section's requirements become enforceable infrastructure rather than per-server diligence, and it is the natural home for the observability (which tools are used, by whom, with what outcomes, at what cost) that turns the estate into a managed platform.
Plan for the context economics. Every connected server's tool schemas occupy context; agents connected to twenty servers spend meaningful budget reading tool descriptions before any work happens, and tool-selection quality degrades as the catalog grows. The maturing countermeasures: host-side server selection per task (surface the relevant servers, not all of them), hierarchical and searchable tool discovery (the model queries for tools rather than reading the full catalog), and server design that consolidates related operations sensibly. The estate's information architecture (how capability is organized, named, and described) is becoming a performance discipline in its own right, which is one more way integration craft has re-emerged as a first-class skill.
And keep the strategic posture honest: MCP is infrastructure, not strategy. The protocol determines how AI applications reach capability; it does not determine whether the capability is governed (the data platform's work), whether the AI's outputs are trustworthy (the evaluation and observability disciplines), or whether the use case earns its costs (the portfolio question every AI program faces). Organizations that adopted MCP atop governed data, owned systems, and evaluated applications compounded their advantages; organizations that adopted it as the strategy connected their assistants, efficiently and at scale, to their chaos. The standard is the wire; what flows through it was always the actual work.
A minimal server is an afternoon; a good one is a design exercise. The mechanical part is genuinely small: the official SDKs (TypeScript and Python first among them) scaffold the protocol handling, a simple server is a few hundred lines wrapping an existing API, and local testing against a desktop host closes the loop the same day. The design part is where the time belongs: which capabilities to expose at all (the purpose-shaped subset, not the API's full surface), at what granularity (intent-level tools over raw primitives), and with what guarantees (idempotency where retries are possible, pagination where results are large, explicit errors where the model must recover).
Tool descriptions are prompts, and they deserve prompt engineering. The model chooses and parameterizes tools entirely from their names, descriptions, and schemas, which makes the description field load-bearing: when to use this tool (and when not to), what each parameter means in domain language, what the output contains, and the examples that disambiguate the confusable cases. Teams discover this empirically: the tool that gets invoked wrongly is usually described ambiguously, and the fix is editorial. The mature practice tests descriptions the way prompts are tested: an eval set of realistic requests, scored on whether the model selects and calls correctly, re-run when descriptions or models change.
The operational wrapper is what makes a server production-grade. Beyond the protocol handling: authentication to the underlying system with scoped credentials (the server's identity, not a borrowed admin token), input validation that does not trust the model (schemas enforced server-side, injection-resistant query construction), rate limiting and timeout discipline toward the wrapped system (an enthusiastic agent is a load test), structured logging of every invocation (the audit trail the governance tier needs), and versioning with deprecation discipline (hosts are consumers; schema changes are contract changes). This list is the API-engineering canon applied to a new consumer, which is exactly what it is.
Testing a server means testing two interfaces. The deterministic one: unit and integration tests against the tools (given these arguments, this behavior against the wrapped system), the familiar half. The probabilistic one: whether models actually use the server well (selection, parameterization, recovery from errors), which needs the eval-harness treatment: a suite of realistic tasks run through a host with the server attached, scored on outcomes, in CI when the server or its descriptions change. Servers that ship with only the first half tested work perfectly and get used wrongly, which in production is indistinguishable from broken.
An open standard that lets AI applications discover and use external tools and data through reusable servers, replacing per-application custom connectors with one protocol between AI hosts and the systems where capability lives.
The N×M integration problem: every AI application building bespoke connectors to every data source. With a standard protocol, a connector (server) built once works with every MCP-speaking application, shifting integration from pairwise projects to a reusable ecosystem, the same move the Language Server Protocol made for code editors.
The three server primitives, divided by who controls them: tools are model-invoked actions (query, create, send) and constitute the action and risk surface; resources are application-controlled data the host reads into context; prompts are user-invokable templates the server contributes. The division keeps actions, data, and user intent on separate control planes.
Over JSON-RPC, with two transports: stdio for local servers (a process the host launches) and HTTP-based transport for remote servers, with OAuth-based authorization flows for the hosted case. At connection, the client discovers the server's capabilities (tool schemas, resource listings); at runtime, the host executes the model's tool calls through the client under its approval policy.
It is securable, which is different. The protocol provides the machinery (transports, authorization flows, the host's approval hooks); the security is estate design: least-privilege servers, scoped credentials, gateway-tier policy and audit, injection-aware architecture (keeping untrusted content, sensitive data, and egress channels apart), and supply-chain hygiene for third-party servers. Connected AI inherits real integration risk, and treating it casually is the era's emerging incident category.
Malicious instructions hidden in content the model reads, hijacking its behavior. Without tools, the damage is bad words; with MCP-connected tools, hijacked behavior becomes hijacked action (data exfiltration, unwanted writes). Defenses are layered: approval gates on consequential actions, servers that structurally cannot perform the dangerous combination, and treating all read content as untrusted input.
Use-case-first: one AI application with real users, the two or three internal servers that close its capability gap (built by the teams owning the underlying systems, scoped least-privilege), a gateway for identity, policy, and audit, and an internal registry. Generalize the estate from what works; resist the wrap-every-API program that produces unused, unmaintained connector sprawl.
It originated at Anthropic in late 2024 and moved to open, industry-wide governance, with client support across the major AI applications and model providers and a server ecosystem in the thousands (official, vendor, community, and internal tiers). The breadth of neutral adoption is the point: a connector standard is only valuable if everyone speaks it.
Yes, as the AI-facing layer over them: your APIs remain authoritative, and MCP servers adapt them into the shape AI applications consume (discoverable, model-comprehensible, approval-gated capability). The integration platform keeps its process-choreography role; MCP covers the new consumer (models and agents) that neither REST documentation nor iPaaS workflows were designed to serve.
