Model Context Protocol

Definition

Model Context Protocol, usually shortened to MCP, is a protocol for connecting AI applications to external context and capabilities.

The plain-English version:

an AI app can talk to external servers that expose useful context and actions

An MCP client lives inside or near the AI application. An MCP server exposes capabilities. Those capabilities commonly include resources, prompts, and tools.

The protocol matters because AI products need a cleaner boundary than "paste random data into the prompt" or "let the model call any internal API."

Why This Concept Exists

AI applications often need information and actions outside the model.

A coding assistant may need files, tests, and repository metadata.

A support assistant may need ticket history, account records, and policy documents.

A personal assistant may need calendars, emails, tasks, or documents.

Without a protocol boundary, every integration becomes custom glue:

app-specific connector
custom tool schema
custom auth behavior
custom result format
custom lifecycle rules

MCP exists to make this integration shape more standard. It gives AI applications and capability providers a shared way to describe and exchange context.

The Beginner Mental Model

A beginner may think:

MCP is just function calling with a new name.

That is too small.

Function calling is one way a model-backed workflow can request an operation. MCP describes a broader connection between clients and servers, including lifecycle, capabilities, tools, resources, prompts, and transport concerns.

A better mental model is:

AI application -> MCP client -> MCP server -> context or capability

The model may decide to use a tool, but the product and protocol boundary still decide what is exposed, authorized, executed, and returned.

Core Building Blocks

The most important server-side primitives are:

• prompts: reusable templates or interaction patterns
• resources: structured data or content that can provide context
• tools: executable capabilities the model-backed system may use

Those words are easy to blur, so keep the control boundary in mind.

Prompts are typically chosen by the user or application flow.

Resources are contextual material the application can attach or expose.

Tools are callable operations, often with arguments and results.

This distinction matters because reading a file, showing a prompt template, and creating a calendar event have different product risks.

Capability Negotiation And Lifecycle

An MCP connection is not only "send a tool call."

The client and server need to establish what each side supports. The application needs to know which capabilities exist, what shape they have, and how to call or read them.

That creates an engineering flow:

connect
negotiate capabilities
discover available tools, resources, or prompts
make requests
handle results and errors
close or maintain session

This is why MCP belongs in AI engineering, not only in prompt design. It affects integration architecture.

Authorization And Trust

MCP servers may expose sensitive data or side-effecting operations.

That means authorization is not optional as a product concern, even when a local development setup feels harmless.

Engineers need to ask:

• who is the user?
• what server is being accessed?
• what scopes or permissions apply?
• can this tool create side effects?
• should approval be required?
• how are tokens, logs, and results protected?

The model should not be treated as the permission system. The MCP client, server, and surrounding application need enforceable boundaries.

A Concrete Example

Imagine a coding assistant connected to a repository server.

The MCP server may expose:

resource: current file contents
resource: git diff
tool: searchRepository(query)
tool: runTests(testPattern)
prompt: explain failing test

The assistant can now inspect useful context and request bounded actions through a known interface.

That does not mean it can do anything on the machine. The server decides what capabilities exist. The client and product decide how much autonomy to allow.

Failure Modes

Common MCP integration failures include:

• exposing broad tools when narrow tools would be safer
• treating tool descriptions as security policy
• returning too much private data as context
• ignoring authorization because the first server was local
• hiding tool failures from the model or user
• making every server result look equally trusted
• failing to log enough trace data for debugging

The protocol creates a cleaner interface. It does not remove the need for product judgment.

Product Examples

In a coding assistant, MCP can connect the AI workflow to files, diagnostics, tests, and repository operations.

In an enterprise assistant, MCP can expose internal knowledge systems through permission-aware servers.

In a local productivity assistant, MCP can connect calendars, tasks, notes, or browser state through controlled capabilities.

In an agent platform, MCP can make tools and resources portable across workflows instead of hardcoding each integration.

Common Confusions

MCP is not the model.

It is an integration protocol around the model-backed application.

MCP is not only tools.

Tools are important, but resources and prompts are also part of the capability shape.

MCP does not make an integration safe by default.

Authorization, scopes, approval policy, logging, and careful tool design still matter.

MCP is not the same thing as RAG.

RAG is a retrieve-then-generate product pattern. MCP can expose resources or tools that support retrieval, but it is a broader protocol boundary.

What This Does Not Mean

MCP does not mean every product should expose every internal system to a model-backed workflow.

The safer design is usually narrow, typed, permission-aware capabilities with clear result shapes and auditability.

It also does not remove context engineering. MCP can provide context and capabilities, but the application still decides what enters the model request.

Related Topics

• Context Engineering
• Tool Use And Function Calling
• What Is An AI Agent?
• Agent Loops