Model Context Protocol (MCP) is an open protocol for connecting AI applications to external data and actions through a consistent client-server interface.

The useful mental model is a standard capability boundary, not “a plugin that gives the model unlimited access.” MCP makes capabilities discoverable and structured; the application and server still own consent, policy, and security.

The MCP architecture

MCP separates three roles:

The host is the AI application the user interacts with.
An MCP client inside that host maintains a connection to one server.
The MCP server exposes bounded capabilities backed by local or remote systems.

A host can connect to many servers while keeping each connection isolated. The protocol uses JSON-RPC messages and a lifecycle that begins with initialization and capability negotiation.

Read the official MCP architecture documentation for the normative terminology.

Capability discovery

After initialization, a client can discover the capabilities the server supports:

Primitive	Purpose	Example
Tools	Model-invoked actions	Create a ticket or run a query
Resources	Application-readable context	Read a specification or schema
Prompts	User-controlled templates	Start a review workflow

These primitives serve different control paths. Treating every integration as a tool can create unnecessary risk. If data only needs to be read, a resource may be the clearer interface.

Transports

MCP commonly uses:

stdio for a local process launched and supervised by the client;
Streamable HTTP for a remote service shared across clients or users.

Choose transport based on deployment and trust boundaries. A local stdio server fits tools that need workspace access. A remote server fits centralized integrations, organization-wide policy, and managed availability.

Authentication is not authorization

For a remote server, authentication establishes who is connecting. Authorization decides what that identity may do.

A secure server evaluates authorization on every operation and object—not only when the connection begins. It should enforce tenant boundaries, scopes, roles, and resource ownership in the underlying service. Never rely on a model’s instruction-following as an access-control layer.

Tool design for reliable model use

Good MCP tools are narrow and explicit:

Use action-oriented names that distinguish reads from writes.
Describe when the tool should and should not be used.
Keep required inputs small and unambiguous.
Return stable structured data rather than decorative prose.
Report actionable error codes and safe retry guidance.
Make repeated calls idempotent when practical.
Separate preview or validation from a consequential commit.

A tool named manage_project hides too much. Tools such as get_task, validate_release, and submit_approval_request give the client clearer choices and make policy enforcement easier.

The main security risks

Prompt injection through retrieved content

Tool results, documents, issue comments, and web pages are untrusted data. A server should not transform instructions found inside content into privileged operations.

Over-broad permissions

A database credential with global write access turns a mistaken call into a large incident. Use per-user credentials, least privilege, and narrow service accounts.

Hidden side effects

Tool names and descriptions must disclose mutations, cost, notifications, and irreversible consequences. Sensitive actions should support a preview and an explicit approval step.

Secret leakage

Do not return credentials to the model, log authorization headers, or embed secrets in resource URIs and error messages.

Cross-tenant access

Remote servers must derive tenant context from authenticated identity and re-check it in the data layer. Never trust a tenant ID supplied by a tool argument on its own.

A production-readiness checklist

Before connecting a server to real systems:

Threat-model the data and every side effect.
Minimize the exposed capability set.
Define identity, scopes, and object-level authorization.
Add schema validation and output limits.
Separate read, preview, approve, and commit operations.
Add timeouts, cancellation, idempotency, and rate limits.
Redact logs and preserve an audit trail for sensitive actions.
Test malformed input, prompt injection, permission bypass, and replay.
Document recovery and credential revocation.

The official MCP tools specification describes tool discovery and invocation. Use the current protocol specification when implementing a server.

Frequently asked questions

Is MCP tied to one model vendor?

No. It defines a client-server protocol that multiple AI applications and server implementations can support.

Does MCP make an integration safe automatically?

No. MCP standardizes communication. The host and server remain responsible for permissions, consent, input validation, data protection, and operational controls.

When should I avoid MCP?

Avoid adding a server when a static document or existing built-in integration already solves the need. Every new capability increases maintenance and attack surface.