AI
What MCP actually is
A protocol. Your tool exposes functions a model may call, and the rest is plumbing.
More on this is coming, and asking moves it up the list.
Or sit with someone on it instead of waiting for us to write it.
AI
AI
A protocol. Your tool exposes functions a model may call, and the rest is plumbing.
More on this is coming, and asking moves it up the list.
Or sit with someone on it instead of waiting for us to write it.
Want this written up?
Sign in and tell us. We write the ones people actually ask for, and asking takes one click.
Sign in to askMCP is a protocol. That is the whole of it, and almost every explanation you will read makes it sound like more.
A model can only work with what it is handed. MCP is an agreement about how a program hands it things: what a tool is called, what arguments it takes, what comes back. Once two programs agree on that, any model that speaks it can use any tool that speaks it, without either side knowing about the other in advance.
Before an agreement like this, every combination was its own integration. Five AI clients and five tools meant twenty-five pieces of glue, each written twice and maintained by nobody.
An agreed protocol turns that multiplication into addition. Five clients and five tools is ten implementations, each written once. That is the entire argument, and it is the same argument as USB, or HTTP, or the language server protocol that stopped every editor writing its own support for every language.
Nothing about MCP is clever. Protocols rarely are. They are valuable precisely because they are boring enough that everyone can agree.
Three kinds of thing, and the distinction matters more than it first appears.
Tools are functions the model may call. search_notes(query). They can have
effects, they take arguments, and the model decides when to invoke one. This is
the part people mean when they say MCP.
Resources are things the model may read. A file, a record, a page. No arguments, no effects, just content the client can pull in as context.
Prompts are templates a user can invoke deliberately, rather than something the model reaches for on its own.
The useful line is between tools and resources: a tool is something you let the model do, a resource is something you let it see. Getting that boundary wrong is how an integration becomes dangerous. A model that can read your database is a research assistant. A model that can write to it is a liability unless you meant it.
Messages are JSON-RPC. They travel over stdio when the server is a local process the client launched, or over HTTP when it is not.
Both of those are decades old and that is the point. Nothing here needed inventing, so nothing here can surprise you. If you can read a JSON request in a log, you can debug an MCP server, which is more than can be said for most of the stack above it.
It is not an agent. MCP describes how a tool is offered; deciding which tool to call and when is the model's job and lives entirely outside the protocol.
It is not a security boundary. A server exposing a delete function will have that function called eventually. Authorisation is yours to enforce inside the tool, exactly as it would be for a public HTTP endpoint, and for the same reason: something on the other end will call it with arguments you did not anticipate.
It is not a reason to expose everything. The most common mistake in a first MCP server is offering thirty tools because you can. A model choosing between thirty similar options chooses badly. Five well-named tools beat thirty vague ones.
inode is our knowledge base in Go: notes and commands saved from the terminal,
retrieved later in plain English through a real retrieval pipeline.
It exposes an MCP server, and deliberately a read-only one. An editor can query the knowledge base; it cannot write to it. That was not caution for its own sake. Saving something is a decision a person should make, and the moment a model can save things too, you no longer trust what is in there.
That constraint is most of what we learned worth passing on: decide what the model may do before you decide what it may see, because the second question is easy and the first one is where the damage lives.
The specification is short and readable, which is unusual and worth taking advantage of. Read the tools section, then write a server with one tool in it. An hour of that teaches more than any overview, this one included.