Tools, resources and prompts

An MCP server offers three kinds of thing: tools, which are actions the agent can ask it to perform; resources, which are data the agent can read; and prompts, which are reusable templates for a task. For a server built around source code, the tools carry almost all of the weight, because understanding code is mostly about asking questions and getting answers.

Three primitives, one server

When an AI agent connects to a Model Context Protocol server and asks what it offers, the answer is not a single blob of capability. It is sorted into three categories, and the categories are worth learning by name because they map onto three genuinely different things an agent might want. The protocol calls them tools, resources, and prompts. A useful way to keep them straight is to think in verbs: tools are for doing, resources are for reading, and prompts are for reusing a way of asking.

A kitchen makes the split concrete. The tools are the things the kitchen can do for you on request: grill this, chop that, plate the dish. The resources are the things you can simply read to inform yourself: the ingredient list, the day’s specials board, the nutrition card. The prompts are the recipes: written procedures that capture a known good way to make something, so nobody has to reinvent it each time. All three come from the same kitchen, but they answer different needs, and a good server, like a good kitchen, is clear about which is which.

Tools: things the agent can do

A tool is an action the server can perform when the agent asks for it, usually taking some inputs and returning a result. This is the most active of the three primitives, and the one that changes what an agent is capable of. A tool might search a body of text, look up a record, run a calculation, or compute the consequences of a change. The agent decides it wants the action done, names the tool, supplies the inputs, and reads back what the tool returns.

The important property of a tool is that the work happens on the server’s side, not in the model’s head. When an agent calls a search tool, it is not the model doing the searching from memory. The server actually looks through the real data and returns real results. This is exactly why tools matter: they let an agent reach past what it was trained on and act on the specific, current state of the world in front of it. Without tools, the model can only talk about your code in the abstract. With them, it can find out what your code actually says.

A tool also has a shape, and the shape is part of what makes it usable. Each tool declares what inputs it takes, so the agent knows what it must supply, and it returns its result in a predictable form the agent can read. A search tool might take a phrase to look for and return a list of places that matched. A lookup tool might take an identifier and return the record it names. The agent does not have to know how any of that is implemented on the far side. It only has to hand over the expected inputs and read back the result, which is the whole point of a tool being a clean, named action rather than a loose request.

Resources: things the agent can read

A resource is a piece of data the server makes available for the agent to read, identified so the agent can fetch it by name. Where a tool is a verb, a resource is a noun. It does not perform an action or take inputs to compute something new. It is content that already exists and can be pulled in: a document, a file’s contents, a configuration, a record. The agent reads a resource to inform itself, the way you might pull a reference off a shelf before starting work.

The line between a tool and a resource can feel blurry at first, and the cleanest way to tell them apart is to ask whether anything happens. Reading a resource does not change the world and does not require the server to compute an answer; it just hands over data that was already there. Calling a tool asks the server to do something, even if that something is only a search. In practice the distinction guides the agent: it reaches for a resource when it wants to know a fixed piece of context, and for a tool when it wants an answer computed from the live state of things.

Prompts: reusable ways of asking

A prompt, in this specific MCP sense, is a reusable template for a task that the server offers so that a common request does not have to be written from scratch every time. Think of it as a saved recipe. Someone has already worked out a good way to phrase a particular job, including which pieces of context it needs, and the server keeps that procedure on hand so the agent, or the person driving it, can invoke it by name.

This is the least universal of the three primitives, in the sense that many perfectly useful servers offer few prompts or none, while nearly all of them offer tools. Prompts shine when a task is common and has a known best shape, so capturing that shape once saves everyone from rediscovering it. But they are a convenience layered on top, not the engine. If tools are what a server can do and resources are what it knows, prompts are just tidy, pre written ways of putting those to work.

Tools are for doing, resources are for reading, and prompts are for reusing a way of asking. Keep the verbs straight and the three never blur together.

Why tools carry the weight for a code server

For a server whose subject is source code, the useful surface is overwhelmingly its tools, and it is worth being precise about why. Understanding a codebase is not mostly a matter of reading one fixed document. It is a matter of asking pointed questions and getting answers computed from the actual structure of the code: what calls this function, what would break if I changed it, where is this defined, what tends to change alongside this file. Every one of those is a question with a computed answer, which is to say it is a tool, not a resource.

You could, in principle, expose a codebase as a pile of resources, one per file, and let the agent read them. But that puts the hard work back on the agent, which then has to reconstruct all the connections between files by itself, the very thing it is bad at on a large project. A code server earns its keep precisely by answering the relationship questions directly, and answering a question is a tool’s job. So while such a server may offer resources and prompts too, its tools are where nearly all of its value lives.

There is a second reason tools dominate here, which is that code changes constantly. A resource is at its best when the data is fixed and can be read once. But the answer to what calls this function is only true for the code as it stands this minute, and the next commit can change it. A tool computes its answer fresh each time it is called, against the current state of the code, so it stays correct as the project moves. A pile of pre written resources would go stale the moment someone edited a file. This is a general pattern: the more the underlying reality shifts, the more the useful surface has to be tools that compute on demand rather than resources that were captured at some earlier moment.

How a tool is described so a model knows when to call it

A tool is only useful if the agent knows when to reach for it, and the agent is not a mind reader. It relies on the description the server provides for each tool during discovery. That description is doing real work. It has to say, in plain language, what the tool does, what inputs it expects, and by implication the kind of question it answers, all clearly enough that a model can match a situation it is in to the tool that fits.

Go back to the menu. A good menu entry does not just name a dish, it says enough about it that you can tell whether it is what you want right now. A tool description is the same. If a tool is described vaguely, the agent will call it at the wrong times or fail to call it when it should, not because the tool is bad but because the label on it was unclear. A well described tool, by contrast, is close to self selecting: faced with a question about what a change would affect, an agent that has been handed a clearly labeled tool for exactly that will pick it. The deeper mechanics of how a model turns a described tool into an actual call are the subject of Tool use and function calling; here the point is narrower, that the description is the bridge between the agent’s situation and the server’s capability.

A concrete tool surface: Koragraph’s nine tools

Koragraph is a code knowledge graph server, so by everything above you would expect its surface to be almost entirely tools, and it is. It exposes nine tools. Grouping them by the job they do makes the shape of the surface clear.

Understanding structure and connections

The first group answers the relationship questions that are the whole reason a code graph exists. explore lets the agent move through the graph of the code. neighbours returns what sits directly next to a given piece of code, its immediate connections. blast_radius answers the change safety question: given a piece of code, what else would be affected if it changed. changes_with surfaces what tends to change together, drawn from the history of the project rather than from the syntax alone.

Finding and reading code

The second group is about locating things. search_code finds code across the repositories. file_symbols hands back the declarations found in a single file, the functions and classes it defines. overview gives a high level picture, a way to orient before diving in. These are the tools an agent reaches for when it needs to find where something lives or get its bearings.

Remembering across sessions

The third group is memory. recall reads back facts that were saved earlier, and remember writes a new fact down. remember is the only one of the nine that writes; the rest only read. This pair is what lets knowledge persist from one working session to the next, so the agent is not starting from a blank slate every time.

Notice that all nine are tools, not resources or prompts. That is not an oversight; it is the natural result of what a code server is for. Every one of these is a question with a computed answer or, in the case of remember, an action that changes stored state. There is no useful way to reduce what calls this function to a static document. It has to be asked, and asking is what tools are.

Where this leads

Once you see a server as a set of described tools an agent may call, the natural next question is how the agent actually decides to call one, turns its intent into a well formed request, and folds the result back into its reasoning. That decision procedure is the subject of Tool use and function calling. And if you want to step back to the standard that lets any of these tools reach any client at all, that is The Model Context Protocol, while the question of who talks to whom, the client and the server, is taken up in MCP servers and clients.