Model Context Protocol (MCP): A Complete Guide for Developers and Businesses
What the Model Context Protocol is and how it works in 2026: hosts, clients and servers, tools, resources and prompts, transports, the stateless 2026-07-28 specification, authorization and practical use cases.
Quick answer
The Model Context Protocol (MCP) is an open standard for connecting AI applications to tools and data. An MCP server exposes tools (functions the model can call), resources (readable data) and prompts (templates) from a system such as a CRM or database. AI applications (hosts) connect through MCP clients over stdio for local servers or Streamable HTTP for remote ones, discover what a server offers and call it. The 2026-07-28 specification made MCP stateless, and remote servers use OAuth 2.1-based authorization. MCP complements APIs rather than replacing them.
Where This Fits
Building a server is covered in how to build an MCP server, positioning against APIs in MCP vs API and security in MCP security. For agents talking to other agents, see agent-to-agent communication. Agent design generally is in AI agent development.
Why MCP Exists
Before MCP, every AI application integrated every tool its own way: one connector for each pair of app and system. MCP turns that many-to-many problem into a standard interface. A company can expose its order system once as an MCP server, and any compatible assistant, IDE or agent framework can use it, with consistent discovery, schemas and authorization.
Anthropic introduced MCP in November 2024; in December 2025 it was contributed to the Agentic AI Foundation under the Linux Foundation, with support from several major AI and cloud companies.
MCP Architecture: Hosts, Clients and Servers
| Role | What it is | Example |
|---|---|---|
| Host | The AI application the user works in | A chat assistant, IDE or agent platform |
| Client | The connector inside the host, one per server | Handles protocol messages and auth |
| Server | A program exposing capabilities from a system | An MCP server for your CRM or file store |
Server Capabilities: Tools, Resources and Prompts
Tools are functions with a name, description and JSON Schema for inputs (and optionally outputs). The model decides when to call them; the host typically asks the user to approve. Resources are data identified by URIs, such as files or records, which the application can read and include as context. Prompts are templates a user can choose, such as 'summarize this ticket'. Servers can also declare optional extensions, a formal mechanism added in the 2026-07-28 revision; long-running work uses the official tasks extension.
What Changed in the 2026-07-28 Specification
The 2026-07-28 revision is the largest change since launch, so older tutorials may be out of date:
- Stateless core: the initialize handshake and protocol-level sessions (the Mcp-Session-Id header) are removed; each request carries its protocol version and client capabilities in metadata
- server/discover: servers must implement it to advertise versions, capabilities and identity
- Multi Round-Trip Requests: servers that need more input return an input_required result instead of sending requests to the client
- subscriptions/listen: one opt-in stream for change notifications replaces older subscription mechanisms
- Deprecations: Roots, Sampling and Logging features, the HTTP+SSE transport, and Dynamic Client Registration in favour of Client ID Metadata Documents
- Caching hints: list and read results carry ttlMs and cacheScope fields
Transports
stdio: the host launches the server as a local process and exchanges messages over standard input and output. Simple and private, suited to developer tools and desktop assistants. Servers must not write logs to stdout, which would corrupt messages.
Streamable HTTP: the server runs as a web service and clients send requests over HTTP, with streamed responses where needed. Suited to remote, shared and SaaS-hosted servers, and the transport where authorization applies.
Want your product or internal systems available to AI assistants?
ZSpace Labs designs and builds MCP servers with narrow tools, proper authorization and the testing needed for production use.
Authorization and Security
Remote MCP servers use OAuth 2.1-based authorization. The server publishes protected resource metadata so clients can discover its authorization server; clients use the authorization code flow with PKCE and request audience-bound tokens; the server must validate that tokens were issued for it and must not pass the client's token through to upstream APIs. Beyond authorization, the main risks are over-broad tools, untrusted servers and prompt injection through tool results. See MCP security.
Practical Use Cases
| Use case | What the MCP server exposes |
|---|---|
| Internal assistant over company systems | Read tools for CRM, tickets and documents |
| Developer tooling | Repository, CI, issue tracker and database access |
| SaaS product integration | Your product's actions for customers' AI assistants |
| Operations agents | Narrow write tools such as creating tickets or updating orders |
| Data analysis | Query tools over a warehouse with row limits and read-only roles |
MCP vs Other Standards
MCP connects an AI application to tools and data. It is complementary to A2A, which connects agents to other agents, and to ordinary APIs, which MCP servers usually call underneath. Model providers' function-calling features define how a model requests a tool call; MCP standardizes how those tools are discovered and reached across applications.
Advantages and Limitations
| Advantages | Limitations |
|---|---|
| Build once, use from many AI applications | Specification is evolving quickly; implementations lag |
| Standard discovery and schemas | Client support for features varies |
| Defined authorization model for remote servers | Security depends on careful implementation |
| Open governance under the Linux Foundation | Not a substitute for well-designed APIs |
How to Adopt MCP Step by Step
- 1. Pick one system and a handful of high-value tools
- 2. Decide local (stdio) or remote (Streamable HTTP) based on who will use it
- 3. Design narrow tools over your existing APIs, read-only first
- 4. Implement with an official SDK targeting the current specification
- 5. Add authorization for remote servers and least-privilege access
- 6. Test with the MCP Inspector and real clients
- 7. Monitor usage and extend tools based on evidence
MCP in the Enterprise: Governance
As MCP use spreads, organizations need the same governance they apply to other integrations. Maintain a catalogue of approved MCP servers (internal and third-party) with owners, data access and permitted clients; block unapproved servers on managed devices; require security review for servers that touch sensitive data or perform writes; and route remote server access through identity providers with audit logs. Treat MCP servers as production services with versioning, monitoring and incident response.
Common MCP Server Patterns
| Pattern | Description | Watch for |
|---|---|---|
| API adapter | Wraps an existing REST or GraphQL API in task-level tools | Keep business rules in the API |
| Data access | Read-only queries over a database or warehouse | Row limits, read-only roles, no free-form SQL for untrusted users |
| Document source | Exposes files or knowledge as resources | Permissions per document |
| Workflow trigger | Starts approved automations | Approvals and idempotency |
| Developer tooling | Repositories, CI, issue trackers | Local execution risk, token scopes |
How MCP Fits With Function Calling
Model providers' function calling and MCP operate at different levels. Function calling is the model-side mechanism: the model returns a structured request to call a tool, and the application executes it. MCP is the integration-side standard: how the application discovers available tools from servers, how it calls them and how authorization works for remote servers. An AI host typically lists MCP tools to the model through function calling, receives the model's tool call and routes it to the right MCP server. Several model platforms can also connect to remote MCP servers directly from their APIs.
Planning an MCP Rollout
- Inventory: which systems should AI clients reach, and for whom
- Prioritize: start with read-only, high-value tools
- Design: task-level tools over existing APIs, with clear descriptions
- Secure: OAuth-based authorization for remote servers, least-privilege scopes, approvals for writes
- Govern: catalogue approved servers, owners and data classes
- Operate: logging, tracing, versioning and support
- Track the specification: plan upgrades when new revisions ship
Worked Example
An illustrative scenario, not a client case: a B2B software company wants customers' AI assistants to check account status and open support tickets. It builds a remote MCP server over its existing public API with three tools (get account summary, list open tickets, create ticket), OAuth-based authorization tied to customer accounts and per-tool scopes, and logs every call. Customers connect from their preferred assistant without a custom integration for each.
Common Mistakes
- Following pre-2026 tutorials that rely on the removed initialize handshake or sessions
- Exposing a generic 'run any query' tool
- Passing user tokens through to upstream APIs
- Connecting unvetted third-party servers to sensitive data
- Writing logs to stdout in stdio servers
Planning an MCP integration?
Talk to ZSpace Labs about MCP server development and API and backend integration.
Conclusion
MCP is becoming the standard way to give AI applications access to tools and data. Build narrow, well-authorized servers on top of your APIs, target the current specification and treat security as a first-class concern. Next: build an MCP server, MCP vs API and MCP security.
Common questions
An open protocol that standardizes how AI applications connect to external tools, data and prompts. An MCP server exposes capabilities once, and any MCP-compatible AI application can discover and use them.