MCP Core Concepts

MCP is a protocol for connecting AI applications to external context and capabilities.

The important point is not “another API wrapper.” MCP defines roles, message shapes, and capability boundaries so many AI applications can connect to many tools and data sources without every pair needing a custom integration.

The Problem MCP Solves

Without a common protocol, every AI app needs a custom integration for every tool or data source:

AI app A -> GitHub integration A
AI app A -> Slack integration A
AI app B -> GitHub integration B
AI app B -> Slack integration B

MCP inserts a common layer:

AI apps / hosts -> MCP clients -> MCP servers -> tools and data sources

That reduces the N x M integration problem. A client that supports MCP can connect to compatible servers, and a server can expose a capability once for many clients.

Roles

flowchart LR
    H["Host\nAI application"] --> C["MCP client\nconnector inside host"]
    C --> S["MCP server\ncapability provider"]
    S --> D["External systems\nfiles, APIs, DBs, SaaS"]

Role	Meaning
Host	The AI application the user interacts with
Client	The connector inside the host that speaks MCP
Server	The service that exposes context, prompts, tools, or other capabilities

The host might be a chat app, IDE, coding assistant, workflow runner, or internal agent platform. The server might wrap a local filesystem, database, GitHub, Slack, CRM, search service, or internal system.

Server Features

MCP servers primarily expose three kinds of features.

Feature	Control model	Use it for
Tools	Model-controlled	Actions the model may decide to call
Resources	Application-controlled	Data/context the client app can list, read, attach, or subscribe to
Prompts	User-controlled	Reusable templates or workflows users can explicitly invoke

This separation matters. Not every useful capability should be a model-invoked tool.

Tools

Tools are functions exposed by servers and invoked through tools/call.

Use tools when the model should decide whether and when to act:

search docs
query a database
create an issue
update a CRM record
run a calculation
write a file

Good tools need clear names, descriptions, input schemas, and safe behavior. Current MCP also supports structured tool results through structuredContent and optional output schemas, which makes tool responses easier for clients and models to consume predictably.

Security note: tool calls can trigger arbitrary external actions, so hosts should show users what tools are exposed and ask for confirmation for risky operations.

Resources

Resources are server-provided data identified by URIs.

Use resources when the application should decide how context is surfaced:

files
database schemas
logs
generated JSON state
documentation pages
project artifacts

Resources are application-driven. A client can present them in a picker, attach them to a conversation, search them, or include them automatically using its own rules. Servers can also support subscriptions and list-change notifications so clients can react when resources change.

Prompts

Prompts are reusable templates exposed by a server.

Use prompts for workflows users may intentionally invoke:

/review-pr
/summarize-incident
/draft-release-note
/analyze-contract

Prompts can accept arguments and can include embedded resources. They are useful when a server knows the right way to ask the model to perform a task, but the user should choose when to start that workflow.

Client Features

MCP is not only server-to-client. Clients can also expose capabilities back to servers.

Feature	What it enables
Roots	Clients tell servers what filesystem/workspace boundaries are available
Sampling	Servers request LLM inference through the client, while the client controls model access
Elicitation	Servers ask the user for missing information through the client

These are important for agent systems because they let servers participate in richer workflows without directly owning the user’s model, workspace, or UI.

Roots

Roots define filesystem or workspace boundaries.

For example, an IDE host can tell a filesystem-aware MCP server which project directories are in scope. The server can request the roots list, but it should respect those boundaries and handle root changes gracefully.

Roots are useful when an MCP server needs access to local files but should not assume it can operate across the whole machine.

Sampling

Sampling lets a server request an LLM call through the client.

This is useful when a server needs intelligence, but the client should retain control over:

model choice
user approval
cost
privacy
prompts shown to the model
what response the server is allowed to see

In current MCP, sampling can also support tool use when the client declares that capability. That makes sampling relevant for nested agentic behaviors, not just one-off text completion.

Elicitation

Elicitation lets a server ask the user for missing information through the client.

Use it when the server cannot safely proceed without clarification:

“best flight” could mean cheapest, fastest, or fewest stops
a form needs a required business field
a workflow needs user consent or selection

Current MCP supports form-style elicitation for structured user input and URL-mode elicitation for sensitive interactions that should not pass through the MCP client, such as secrets or payment credentials.

Transports

MCP messages use JSON-RPC 2.0.

Current standard transports are:

stdio for local process-style servers
Streamable HTTP for remote servers

Streamable HTTP replaced the older HTTP+SSE transport from the initial protocol version. Custom transports are possible, but stdio and Streamable HTTP are the standard paths to understand first.

Registry

The MCP Registry is a metadata layer for discovering publicly accessible MCP servers.

It is currently in preview. Its purpose is not to host server code directly. Instead, it stores metadata such as:

server name
where to find it
package or remote URL information
installation/configuration details
capability/discovery metadata

The registry helps with discovery, verification, and ecosystem distribution. For private enterprise servers, teams should use private registries or internal discovery systems rather than publishing private endpoints to the public registry.

MCP And Agent Frameworks

MCP does not replace agent frameworks.

Agent frameworks still own:

orchestration
memory and context compression
model routing
planning loops
parallel or sequential subtask execution
UI and product behavior

MCP owns the integration contract for context and capabilities. In practice, an agent framework can use MCP servers as standardized tools, resources, and prompt providers.

Practical Design Rule

Use the right primitive:

Need	Prefer
Model should decide whether to act	Tool
App should surface/read context	Resource
User should launch a known workflow	Prompt
Server needs workspace boundaries	Roots
Server needs model intelligence via client	Sampling
Server needs missing user input	Elicitation
Client needs server discovery	Registry or private registry

Key Takeaways

MCP standardizes how AI apps connect to external context and capabilities.
Tools, resources, and prompts are separate because the model, application, and user need different control surfaces.
Roots, sampling, and elicitation make MCP more than simple tool calling.
Stdio and Streamable HTTP are the current standard transports.
Registry is useful for discovery, but private systems still need private governance.
MCP complements agent frameworks; it does not replace the agent loop.