Glossary

MCP

Model Context Protocol (MCP) standardises how an AI application discovers and uses external tools, resources, and prompt templates. It includes an authorization framework for HTTP, but does not itself establish server trust, business permission, or secure integration configuration.

Short definition

A standard interface between an AI application and external capabilities.

MCP separates an AI application from specific integrations. A server describes its capabilities, and the host creates a client for it that passes context or call results back to the host.

The current specification uses JSON-RPC. A server can expose tools for operations, resources as contextual data, and prompts as interaction templates. The protocol does not decide whether an action should occur or who may approve it; that remains the responsibility of the host, identity, and specific integration.

The problem it solves

Fewer one-off connectors and clearer capability interfaces.

MCP is useful when one AI application needs to work with multiple data sources or tools without creating a custom integration protocol for each one.

giving an AI tool standardised access to project documentation and read-only data
connecting an issue tracker, internal API, or test command through explicitly described capabilities
separating the AI host from the implementation of the service that holds data or performs an action
dynamically discovering which tools, resources, and prompts a server actually offers
passing structured arguments and results without parsing natural language as an integration format
more consistent management of remote and local integrations when supported by the host and SDK in use

Practical example

A development tool with documentation, tickets, and tests

A developer AI tool can connect several MCP servers: a resource containing repository rules, read-only ticket search, and a test tool in an isolated directory. The host discovers their capabilities and exposes only operations permitted by policy.

When the model needs to verify a requirement, the host reads the resource or calls search. Changing a ticket or running a dangerous command requires approval. MCP does not decide access to production data, secrets, or the network; the host, server, and identity in use enforce those rules.

How it works

Text flow: host → client → MCP server → capability → result → host

The flow matches the current model for local and remote servers. The implementation makes security decisions on top of it.

Host The AI application manages connections, the model, the user interface, and policy.
Client and transport The client sends JSON-RPC over stdio or Streamable HTTP; custom transports may also be supported.
Discovery and capabilities The server announces versions and supported features; the client must not assume them.
Tools, resources, and prompts A tool is called with arguments, a resource provides context, and a prompt is a reusable template.
Server response The server returns a result or error; external content must not be trusted without validation.
Policy and auditing MCP describes an authorization framework for HTTP, but the host and server still enforce business permissions, approval of sensitive actions, and logging.

Main components

MCP roles and capabilities are not the same as permissions.

The specification distinguishes communication participants from the features a server may offer. Not every implementation supports every capability.

Host, client, and server

The host is the AI application, a client communicates with one particular server, and the server provides context or operations locally or remotely.

Tools

Executable functions with named input and output; their description is not permission to act.

Resources

Provide contextual data. They are usually read, but this distinction does not guarantee security or that the data is non-sensitive.

Prompts

Server-provided interaction templates; the host decides whether to use them.

Discovery and capability negotiation

The client discovers supported features instead of assuming them. The modern stateless model uses server/discover and request metadata; older implementations may use initialisation.

Transports

Stdio connects local processes. Streamable HTTP uses HTTP requests and, where needed, Server-Sent Events for streaming messages.

Benefits and limitations

A uniform interface does not reduce operational responsibility.

When it can help

reduces the number of product-specific connectors between hosts and services
makes server capabilities clearer through named tools, resources, and prompts
separates the AI application from the internal implementation of a data source or action
supports gradual discovery of versions and capabilities instead of fixed server assumptions

Limitations and common mistakes

the HTTP authorization framework does not replace business authorization or automatic user approval
a poorly designed MCP server can expose more sensitive operations than the original integration
an overly general tool complicates validation, auditing, and least privilege
specification versions and SDK support evolve, so the specific implementation must be verified

Pragmatic use

Start with a small, clear, restricted server.

MCP is worthwhile when a capability will be used by multiple AI hosts or when a separate boundary around data and actions simplifies operations. A new protocol may not be necessary for one fixed automation. The server’s purpose, identity, data sensitivity, and auditing should be clarified before listing tools.

The first integration should be read-only and narrowly focused, such as documentation search or a test in a sandbox. Writes are added only with precise scopes, argument validation, an audit identity, and, where appropriate, human confirmation.

Security and trust

MCP is a channel for capabilities, not a security boundary by itself.

A trustworthy MCP solution must limit the impact of model errors, malicious content, and a compromised server. Permissions are evaluated for each specific action and data source.

separate read-only and write tools, give the server only necessary scopes, and avoid accounts with broader rights
treat resources and tool results as untrusted; prompt injection can come from a document, ticket, website, or database
show the impact and request confirmation before a sensitive action; the model must not decide about secrets, payments, or production changes by itself
for Streamable HTTP, verify origin, authentication, and tokens; do not expose a local server needlessly to the network, and restrict it with a sandbox
log calls, identities, approvals, and errors without unnecessary secrets, and review scopes and the specification regularly

Common questions

What matters about MCP

Is MCP the same as an AI agent?

No. MCP standardises external capabilities; an agentic workflow controls how a model pursues a goal. An agent may or may not use MCP.

Does MCP replace conventional APIs?

No. An MCP server can call REST, GraphQL, a database, or a command-line tool internally. It does not replace every integration interface.

Does MCP provide secure authorization automatically?

No. MCP describes an authorization framework for HTTP, but security also depends on identity, scopes, token validation, host policy, tool permissions, and server operations.

Are tools, resources, and prompts always supported?

No. The server announces capabilities, and the client must work with what is actually supported.

Should a server receive production secrets to be useful?

Not automatically. Read-only or restricted access is preferable. Sensitive access requires narrow scope, secure storage, and auditing.

How I use AI integrations in development

An integration needs the same boundaries and auditing as any other backend access.

I connect AI tools to project resources so their capabilities, permissions, and outputs remain controllable.

View my AI development experience Discuss your project without obligation