You have probably hit the wall already: your AI assistant is brilliant at reasoning but blind to your actual world. It cannot read the file on your disk, query your database, check today's tickets, or call your internal API — unless you hand-build a one-off bridge for every single connection. The Model Context Protocol (MCP) is the open standard that ends that fragmentation. Introduced by Anthropic in late 2024 and since adopted across the industry, MCP gives AI applications a single, consistent way to plug into tools and data. The project's own analogy is the cleanest one: think of MCP as a USB-C port for AI — one connector, anything on the other end.
This guide walks through what MCP actually is, the small handful of concepts you need, how to connect your first server in a couple of minutes, and how to write a minimal server of your own. It assumes you are comfortable editing a config file and running a terminal command, but not that you have ever touched the protocol before.
The problem MCP solves
Before MCP, every AI app spoke its own dialect. If you had three assistants and four tools you wanted them to use, you were potentially on the hook for twelve bespoke integrations — and each one broke whenever either side changed. This is the classic M×N integration explosion. MCP collapses it into M+N: each app ships one MCP client, each tool ships one MCP server, and they all speak the same language.
The architecture: hosts, clients, and servers
MCP has three roles. The host is the AI application you actually use — Claude Desktop, Claude Code, an IDE plugin, or any agent. Inside the host runs one or more MCP clients, each maintaining a dedicated connection to a single MCP server. The server is a lightweight program that exposes some capability — access to your filesystem, a GitHub repo, a Postgres database — and the client and server talk over a simple JSON-RPC message format, either locally over standard input/output or remotely over HTTP.
The three things a server exposes
An MCP server can offer three kinds of capability, and the distinction matters because each is controlled by a different party. Tools are model-controlled actions the AI can decide to invoke — run a query, send a message, write a file. Resources are application-controlled, read-only data the host can load into context, like a document or a set of rows. Prompts are user-controlled templates a person triggers deliberately, much like a slash command. Keeping these straight is the single biggest conceptual win when designing a server.
Connecting your first server
You do not need to write any code to benefit from MCP — dozens of servers already exist for filesystems, GitHub, Slack, databases, and more. To wire one up in Claude Desktop, you add it to the app's configuration file. Here is the canonical example that gives the assistant scoped access to a folder on your machine:
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/your/folder"]
}
}
}Restart the app, and the assistant can now list, read, and write files inside that folder — and only that folder. In Claude Code, the equivalent is a single command such as claude mcp add, which registers the server for that project. The same server definition is portable: the host changes, the server does not.
Writing a minimal server
When no existing server fits, building one is refreshingly small. Using the official Python SDK, a complete server that exposes one tool looks like this:
from mcp.server.fastmcp import FastMCP
mcp = FastMCP("weather")
@mcp.tool()
def get_forecast(city: str) -> str:
"""Return today's forecast for a city."""
return f"Sunny in {city}, around 24C."
if __name__ == "__main__":
mcp.run()That is a real, working server. The docstring and type hints are not decoration — MCP sends them to the model as the tool's schema, so the AI knows what the tool does and what arguments it expects. Clear names and descriptions are the difference between a tool the model uses correctly and one it ignores. SDKs exist for TypeScript, Python, and several other languages, all following the same shape.
Security and good habits
Because servers can read data and take actions, treat them like any other privileged dependency. Install only servers you trust, and read what permissions they request. Scope filesystem and database access as narrowly as the task allows — a folder, not your home directory; a read-only role, not an admin one. Prefer servers that confirm before destructive actions, and remember that the model can be steered by the content it reads, so a malicious document could try to trigger a tool. Granting least privilege per server is your main line of defense.
The payoff for getting comfortable with MCP is leverage: every server you add is a capability every MCP-aware assistant inherits, today and tomorrow. Instead of rebuilding integrations for each new model or app, you teach the ecosystem once. That is why MCP went from an Anthropic proposal to a default expectation across the major AI platforms in barely a year — and why learning it now pays off across whatever tools you adopt next.