What is MCP?

Summary

MCP standardizes the connection between an AI application and an external capability. The protocol does not replace the model, external API, application logic, authorization, or human approval. The useful unit is a narrow server contract that a specific host can discover, limit, test, and monitor.

• Host responsibilities include the user experience, model conversation, connection policy, and approvals.
• Each MCP client represents the host's route to one server.
• Servers expose typed tools, addressable resources, or reusable prompts.
• Stdio fits local child processes; Streamable HTTP fits remote services.
• Trust, least privilege, validation, and audit records still need deliberate implementation.

Start with the current official introduction to Model Context Protocol.

What does MCP mean?

In this context, MCP means Model Context Protocol. It is a published protocol for exchanging context and capabilities between AI applications and external systems. The word context can cover a file, database schema, application record, image, tool description, operation result, or structured interaction template.

MCP is not an AI model and an MCP server does not need to contain a model. The model runs through the host. Host policy decides which server capabilities enter the conversation and routes approved requests through an MCP client. Server-side validation and policy apply before the backing system is reached.

When did MCP come out?

Anthropic introduced and open-sourced Model Context Protocol on 25 November 2024. In December 2025, Anthropic donated MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation. Today's ecosystem has a community specification, SDKs, development tools, reference servers, and a registry.

Check Anthropic's original MCP announcement and release date.

See the announcement about donating MCP to the Agentic AI Foundation.

Follow the current MCP specification

MCP evolves through dated specification versions. The 28 July 2026 release changed the protocol core from a hidden session and initialization handshake to self-describing requests. It added optional server discovery, header-based routing, cache hints for list results, a formal extension system, and authorization hardening.

That release also deprecated roots, sampling, logging, Dynamic Client Registration, and the legacy HTTP plus Server-Sent Events transport, with a documented transition window. Older clients and servers can still implement earlier versions. Record the version each side supports instead of copying configuration from an undated tutorial.

See the official notes for the 2026-07-28 MCP specification.

Understand the MCP architecture

Host

The host is the AI application a person uses, such as a chat product, coding environment, or custom agent. It coordinates the model, creates MCP clients, applies connection policy, presents consent, and decides which results enter the conversation. Host support varies, so a server feature is useful only when the chosen host implements it.

Client

An MCP client is a component inside the host that communicates with one MCP server. Most hosts create a separate client for each server. The client sends protocol requests, receives results, and reports the server's available capabilities to the host. The user usually configures the host rather than operating this component directly.

Server

An MCP server is a program that exposes a focused set of capabilities. Server describes its protocol role, not its physical location. Local implementations can run as child processes on the same computer. Remote implementations can run as shared HTTP services. Both can sit in front of files, databases, SaaS APIs, internal services, or other systems.

Data and transport layers

The data layer defines JSON-RPC messages, protocol versions, capability discovery, tools, resources, prompts, and utility behavior. The transport layer carries those messages and handles connection details. Keeping these layers separate lets the same capability model work through local standard input and output or remote HTTP.

Find the current roles and layers in the official MCP architecture overview.

How does MCP work?

A connection can discover capabilities before a task or send a self-describing request directly when both sides use the current specification. Client policy still decides what the model and user can reach. A typical tool request follows six stages:

1. 1The user asks for an outcome in the host application.
2. 2Host policy selects an allowed server capability and gathers required context.
3. 3The MCP client sends a typed JSON-RPC request through the configured transport.
4. 4Server policy authenticates the caller where required, authorizes the operation, and validates its inputs.
5. 5Execution reaches the backing file system, API, database, or service and returns a structured result or error.
6. 6Finally, the host shows the result, asks for required approval, or lets the model continue with the returned evidence.

MCP standardizes the envelope and capability contract. It does not decide whether a request is wise, whether returned data is true, or whether an action should be approved. Those decisions remain with the host, server, backing system, and people responsible for the workflow.

Choose tools, resources, or prompts

MCP tools

A tool is a named operation with a description, typed inputs, and a result. Use one for search, calculation, creation, update, deletion, or another action. A good tool separates read and write behavior, states its side effects, validates inputs at execution time, and returns errors the host can explain. Natural-language descriptions help selection but do not enforce security.

MCP resources

A resource is addressable context, usually identified by a URI. It can represent a file, schema, documentation page, application record, or generated view. Use a resource when the host needs readable data with identity and structure. Do not disguise a side effect as a resource read.

MCP prompts

A prompt is a server-provided interaction template with optional arguments. It can make a repeated workflow easier to start, such as preparing a release review for a named project. Prompts support usability and consistency. They are not an authorization layer and cannot replace enforced policy.

Compare tools, resources, and prompts in the official server concepts guide.

Choose a local or remote transport

Stdio for a local process

With stdio, the host launches a local command. Messages move through the process's standard input and output streams. This fits a tool that needs local files, a repository, or a developer-only process. Inspect the exact command and package before running it. The child process can inherit powerful local access unless the host or operating system restricts it.

Streamable HTTP for a remote service

Streamable HTTP fits a hosted or shared server. It supports ordinary HTTP deployment and remote authorization patterns. Check the canonical endpoint, TLS, operator, tenant boundary, scopes, token audience, and action policy. Do not paste a bearer token into an unverified server or commit credentials in a client configuration file.

Follow one MCP example

Consider a support assistant connected to an issue tracker. Its server might expose an issue as a resource and search as a read-only tool. It could offer comment creation as a write tool and an incident-summary prompt. Application policy controls which capabilities the user and model see.

A safe workflow retrieves the issue first, cites the issue identifier, drafts the comment, and asks for approval before writing. The server checks that the caller can view the issue and add comments. It rejects missing fields and logs the external operation. MCP carries the requests and results; the issue tracker's own API remains the system of record.

MCP compared with nearby concepts

MCP and APIs

An API defines how software reaches a particular system. MCP defines how an AI host discovers and calls capabilities across servers. Server implementations often wrap one or more existing APIs. Those APIs retain their authentication, rate limits, validation, and domain rules. A direct API integration fits when one application owns a stable, narrow connection and MCP interoperability adds no value.

Function calling

Function calling is the model or API feature that produces a structured request for a named operation. MCP can supply the operation catalog, discovery rules, transport, and result exchange used by a host. The application may convert MCP tools into the function format its model accepts. The two layers can work together.

Retrieval

Retrieval-augmented generation selects evidence for a model response. MCP can expose a search tool or readable resources used by a retrieval system, but it does not define chunking, ranking, citations, freshness, or evaluation. Keep the retrieval design separate and test whether the returned evidence actually answers the task.

Plugins

A plugin or extension can bundle interface code, commands, skills, or configuration for one product. MCP is a protocol boundary. A product may package an MCP server inside an extension, yet installation, updates, permissions, and distribution still belong to that product's plugin system.

Decide when MCP fits

• Several compatible hosts need the same external capability.
• Capabilities need typed discovery instead of a hard-coded tool list in each host.
• The integration benefits from clear tools, resources, prompts, and transport boundaries.
• The process or service can enforce its own authentication, authorization, and input rules.
• The team can test client compatibility and maintain the server as the specification evolves.

• One application calls one stable API and no other host needs the integration.
• The proposed server would expose broad administrator access without enforceable scopes.
• A static document or direct answer meets the need without executable code.
• The backing system has no reliable source contract, ownership, or audit trail.
• The host does not support the required MCP feature or specification version.

How to use an MCP server safely

1. 1Write the exact outcome and decide whether it needs reading, writing, or both.
2. 2Choose a host that supports the server's transport, features, and specification version.
3. 3Confirm the operator, source repository, package, endpoint, documentation, release, and maintenance record.
4. 4Inspect the command, environment variables, scopes, directories, domains, tools, and side effects before connecting.
5. 5Start with one server, read-only access, test data, and a disposable project when practical.
6. 6List the exposed capabilities and test one harmless request with an observable expected result.
7. 7Add write access only for a named workflow, require approval where the consequence warrants it, and retain an audit record.
8. 8Remove unused servers and review changes to tools, schemas, packages, endpoints, and permissions.

The configuration method differs across ChatGPT, Claude, Cursor, Visual Studio Code, and other hosts. Use the current documentation for the chosen client. A command copied from a search result can execute local code, while a remote URL can send data to another operator. Treat both as software installation decisions.

Review MCP security before connection

MCP creates a path between a model-driven application and real systems. Main risks include untrusted local commands, excessive filesystem or network access, and prompt injection in retrieved content. Other risks include misleading tool descriptions, unsafe tool composition, credential exposure, confused-deputy flows, server-side request forgery, and unauthorized writes.

• Enforce authorization in code and the backing service, not in a prompt.
• Use least-privilege scopes, short-lived tokens, secure storage, HTTPS, and audience validation for remote servers.
• Show the full local command before execution and sandbox its filesystem and network access where possible.
• Separate read tools from mutation tools and confirm consequential actions near execution time.
• Validate every input, constrain outputs, redact secrets, and record tool identity, caller, arguments, result, and time.

Read the official MCP security best practices before implementing authorization or one-click installation.

Evaluate an MCP integration

Test the task, boundary, and failure path rather than celebrating a successful connection. Create a small test matrix. Include allowed and blocked reads and writes, invalid inputs, expired credentials, unavailable dependencies, slow responses, cancellation, and changed tool schemas. Use real host behavior because support and approval patterns differ.

Measure task completion, wrong-tool selection, unnecessary calls, approval quality, rejected requests, latency, error recovery, context use, cost, and external side effects. Review logs against the backing system. A polished model response cannot prove that the right account, record, branch, tenant, or permission was used.

Common MCP mistakes

• Calling MCP an AI model, database, or security layer.
• Using an old transport or initialization tutorial without checking the specification date.
• Connecting many overlapping servers before testing one narrow workflow.
• Treating tool descriptions or user approval as server-side authorization.
• Giving one tool both broad read and destructive write behavior.
• Assuming the host supports every server feature because both products mention MCP.
• Publishing secrets, tokens, personal paths, or private endpoints in shared configuration.
• Measuring successful calls while ignoring whether users completed the intended task.

Frequently asked questions

Next step

Choose one read-only task with a clear expected result. Name the host, server operator, backing system, transport, specification version, requested access, and owner. Connect it in a disposable project and inspect the exposed capabilities. Run one harmless request, then verify the result against the system of record before expanding access.

Install Better Design as an MCP server in a supported coding client.

Use the MCP Claude guide for client-specific setup and permission checks.

Follow the Linear MCP Codex guide for a focused remote-server example.

Browse more Better Design guides.