Mission Log

MCP (Model Context Protocol) Explained for AI Practitioners

MCP is Anthropic's open protocol for connecting AI models to external tools and data. Here are the core concepts and why it matters for agents.

AI

You have an AI agent that can reason about problems and write coherent text, but it cannot read your files, query your database, or remember what it did yesterday. Every session starts from zero. Every tool integration is a custom hack — a bespoke API wrapper, a fragile function-calling shim, a context window stuffed with manually pasted data. MCP (Model Context Protocol) is an open protocol designed to fix this. It provides a standard interface for connecting AI models to external tools, data sources, and persistent memory, so you stop rebuilding the same plumbing for every integration.

TL;DR

  • MCP is an open protocol from Anthropic that standardizes how AI models connect to external tools and data sources.
  • It uses a client-server architecture: MCP servers expose capabilities (tools, resources, prompts), and AI clients consume them through a standard interface.
  • The protocol enables persistent memory, tool access, and context sharing across sessions without custom integration code per tool.
  • It matters for AI agents because it turns isolated chat completions into systems that can act on the world and remember what they did.

Why This Matters

The biggest limitation of current AI systems is not intelligence — it is connectivity. A model can reason through a complex problem, but if it cannot access your actual data or use your actual tools, that reasoning happens in a vacuum.

Before MCP, every tool integration was custom. Want your AI to query a database? Write a function, register it, handle the serialization. Want it to read files? Build another integration. Want it to remember context between sessions? Roll your own persistence layer. Multiply that by every tool and every AI client you use, and you get an explosion of bespoke glue code.

MCP proposes a standard. One protocol. Any tool that implements an MCP server can be consumed by any AI client that speaks MCP. That composability is what changes the equation from “AI as chatbot” to “AI as operational tool.”

What MCP Is

MCP (Model Context Protocol) is an open protocol released by Anthropic in late 2024. It defines a standard way for AI applications to discover and interact with external capabilities.

Think of it like a USB port for AI. Before USB, every peripheral needed its own connector and driver. USB standardized the interface so any device could plug into any computer. MCP does something similar for AI-tool integrations: it standardizes the interface so any tool can plug into any AI client.

The protocol is JSON-RPC based, transport-agnostic (it works over stdio, HTTP, WebSockets), and designed to be implemented by anyone. It is not locked to Anthropic’s products. Claude Desktop, VS Code with Copilot, Cursor, and other AI clients have adopted it as an integration standard.

The Client-Server Model

MCP uses a straightforward client-server architecture.

MCP Servers expose capabilities. A server might provide access to a filesystem, a database, a knowledge graph, a set of API endpoints, or any other external resource. The server defines what it can do and publishes that through the MCP protocol.

MCP Clients are the AI applications that consume those capabilities. When you use Claude Desktop or an AI-enabled IDE, the client discovers available MCP servers, inspects their capabilities, and makes them available to the model during conversations.

The host is the application that manages the lifecycle of client-server connections. In practice, this is often the AI application itself (Claude Desktop, for example) or a gateway that brokers multiple server connections.

The separation matters because it means tool authors and AI client developers can work independently. If you build an MCP server for your homelab’s Docker environment, it works with any MCP client — not just the one you built it for.

Core Concepts

MCP defines four primary capability types that servers can expose.

Tools

Tools are functions the AI model can call. They are the most common MCP capability and the one most people encounter first.

An MCP tool has a name, a description (so the model understands when to use it), and a defined input schema. When the model decides to use a tool, the MCP client sends the request to the server, the server executes the function, and the result flows back to the model.

Examples of MCP tools:

  • Read or write files on a filesystem
  • Execute a database query
  • Search a knowledge graph
  • Run a shell command
  • Call an external API

The critical difference from traditional function calling is standardization. You define a tool once in an MCP server, and any MCP-compatible client can discover and invoke it. No per-client integration work.

Resources

Resources are data the model can read. Unlike tools, which perform actions, resources provide context — files, documents, database records, configuration data.

A resource has a URI, a name, and a content type. The AI client can list available resources and read their contents. This is how you give a model access to your codebase, your documentation, or your project’s configuration without copy-pasting into the context window.

Prompts

Prompts are reusable prompt templates that servers can expose. They define parameterized message sequences that clients can present to users or inject into conversations.

This is less commonly used than tools and resources but useful for standardizing how specific workflows start. A code review server might expose a “review-file” prompt template that structures the model’s analysis in a consistent way.

Sampling

Sampling allows servers to request completions from the AI model through the client. This inverts the typical flow — instead of the model calling the server, the server asks the model to generate text.

This enables agentic loops where a server can use the AI model’s reasoning as part of its own processing. It is a more advanced capability and requires explicit user consent in most implementations.

Why It Matters for AI Agents

Without MCP, an AI agent is a stateless text processor. It receives a prompt, generates a response, and forgets everything. Giving it memory, tool access, and context requires building custom infrastructure for each capability.

MCP changes this in three concrete ways.

Persistent memory. MCP servers can implement knowledge graphs or other storage backends that persist across sessions. When an agent starts a new conversation, it can query its memory server for previous context, decisions, and observations. This is not chat history — it is structured knowledge that the agent accumulates over time.

Composable tool access. An agent connected to multiple MCP servers can use tools from all of them in a single conversation. A filesystem server, a database server, and a deployment server can all be active simultaneously. The model decides which tools to use based on the task.

Context sharing across clients. Because MCP servers are independent processes, the same server can be consumed by different AI clients. The memory server you use with Claude Desktop is the same one available to your CI/CD agent or your IDE assistant. Context is shared, not siloed.

If you have built custom tool integrations for an AI agent, you know how much glue code each one requires. MCP replaces that glue with a protocol, and the reduction in per-tool overhead is significant.

Real-World Use Cases

MCP is not theoretical. Here are concrete ways people are using it.

Homelab automation. An MCP server that wraps Docker commands lets an AI agent manage containers, inspect logs, and deploy services. Combined with a memory server, the agent remembers your deployment patterns and can apply them consistently across sessions.

Knowledge graphs. MCP memory servers backed by knowledge graphs let agents build and query structured knowledge over time. This is how you get an agent that learns your codebase, your architecture decisions, and your operational patterns instead of starting fresh every conversation.

IDE integration. AI-enabled editors use MCP to give models access to your project files, build systems, and development tools. The model can read your code, run tests, and propose changes through standard MCP tool calls instead of through editor-specific plugins.

API integration. MCP servers that wrap external APIs (Slack, GitHub, databases, monitoring systems) give agents the ability to interact with your operational tools. An agent can check CI status, post updates, query metrics, and file issues without custom integration code per service.

The Ecosystem Today

MCP adoption is growing. Claude Desktop, Cursor, VS Code (via extensions), and several other AI clients support MCP natively. Docker provides an MCP gateway for containerized servers. The community maintains servers for filesystems, databases, web search, and dozens of other integrations.

The protocol specification is open and versioned. Anthropic maintains it, but it is designed for community implementation. MCP servers can be written in any language — the reference implementations are in TypeScript and Python, but the protocol is language-agnostic.

The main limitation today is that MCP is still maturing. Not every AI client supports every capability. Server quality varies across community implementations. And the security model — particularly around which tools an agent can invoke and what data it can access — is still being refined across implementations.

Summary

  • MCP is an open protocol that standardizes how AI models connect to external tools, data, and memory.
  • The client-server architecture separates tool implementation from AI client implementation, enabling composability.
  • Four capability types — tools, resources, prompts, and sampling — cover the range of AI-external interactions.
  • For AI agents, MCP enables persistent memory, composable tool access, and context sharing across sessions and clients.
  • The ecosystem is growing, with support across major AI clients and a community of open-source server implementations.

What’s Next?

If you want to see MCP in action rather than in theory, the best starting point is wiring a memory server into an existing workflow. For a practical implementation of MCP memory in a homelab repo, see our agent memory contract guide.

Are you using MCP servers in your development workflow or homelab automation? What servers have been most useful, and where have you hit limitations? The protocol is still early enough that practitioner feedback shapes the direction — sharing what works and what does not matters.