Guide · Connecting
Model Context Protocol and tool use
The Model Context Protocol is an open standard for connecting AI assistants to outside systems: files, databases, APIs and applications. Anthropic published it in November 2024, and it has since been adopted well beyond them. It replaces one custom integration per tool per assistant with one server any client can speak to.
How long does it take to learn?
Connecting an existing server takes ten minutes. Understanding what you just granted takes an evening. Writing your own server is a weekend if you can already code, and it is the point where the whole idea stops being abstract.
The fastest path, in order
- 01
Learn the three pieces
A host is the app you use, a client lives inside it, a server exposes one system. That separation is the entire idea: the server is written once and every client can use it, which is why the standard exists at all.
- 02
Connect an existing server first
Filesystem, GitHub or a Postgres server, attached to a client you already use. Seeing an assistant read your own repository is what makes the abstraction click, and it costs nothing.
- 03
Learn what tools, resources and prompts each mean
Tools are actions the model can take, resources are things it can read, prompts are reusable templates the server offers. Most confusion about MCP is these three being blurred together.
- 04
Understand the permission you just granted
A tool call is code running on your machine with your access. Read what a server can do before connecting it, and treat a third-party server the way you would treat a browser extension asking for everything.
- 05
Write a small server of your own
One tool, one resource, against something you actually use. The official SDKs make this an afternoon, and having written one is what makes every other server legible.
- 06
Design for failure
Tools time out, return nonsense and get called with arguments you did not anticipate. A server that fails clearly is worth more than one with ten features, because the model reads your error message and can act on it.
Tools worth your time
| Tool | What it is for |
|---|---|
| Claude Desktop and Claude Code | The reference clients: the fastest way to have a working MCP setup today. |
| Official MCP SDKs | TypeScript and Python libraries for writing a server without handling the protocol yourself. |
| MCP Inspector | Local tool for calling your server's tools by hand, which is how you debug one. |
| Filesystem server | The canonical first connection: scoped read and write access to a directory you choose. |
| GitHub server | Issues, pull requests and code, which turns an assistant into something that knows your project. |
| Database servers | Postgres and friends, read-only until you are certain. Start read-only and stay there a while. |
Server directories are growing quickly and are not curated in any meaningful sense. A server runs with your permissions on your machine. Read the source of anything you did not write, prefer servers whose scope you can restrict, and connect one at a time.
Mistakes that cost people weeks
Connecting everything on day one
Twelve servers, an assistant that has too many tools to choose well, and no idea which one just did something surprising. Add one, use it for a week, then add the next.
Granting write access to get started
Read-only teaches you the same thing with none of the risk. Write access is a decision to make deliberately, once you know exactly what the server can reach.
Assuming MCP is only for coding
It is a protocol for connecting a model to systems, and the systems that pay off fastest are usually the boring ones: notes, calendars, internal documents, a database of your own work.