MCP tools vs resources vs prompts: who decides what

A model connected to your banking system or your ERP doesn’t touch the data by itself: someone decided that this specific action was allowed to run. Sherpa Platform exposes financial and banking information through an MCP server, and who controls each decision changes depending on the case.

ARTURO G. BRUNO
Software Engineer

Connecting language models to production systems is becoming routine, and Model Context Protocol (MCP) is the standard that makes it possible without bespoke integrators. MCP tools vs resources vs prompts is the distinction that decides, in each case, who controls that connection: the model, the application, or the user.

The model decides when to call a tool; the application decides which resource it loads into the context; the user decides when to invoke a prompt. That’s why designing an MCP server starts with a question that comes before any line of code: which capabilities do you want to expose? The answer to that is what determines whether each capability is born as a tool, a resource, or a prompt — not the other way around.

The problem MCP solves: bespoke integrations that stop scaling

Before MCP, connecting an AI application to an external system meant writing your own connector for every combination. For three applications and three data sources, that’s nine separate integrations someone has to maintain. Keeping those nine integrations alive costs more than writing them: every time the model changes, or the external system, or whoever touched them last, someone has to go through them one by one.

MCP fixes that problem because it is an open protocol, with a public specification and SDKs in several languages, with no single owner, that standardises how an AI client talks to a capability server using JSON-RPC 2.0 messages for requests, responses, and notifications. If an AI application and an external tool both speak that protocol, connecting them stops being a bespoke integration project: it’s enough that both speak MCP. Anthropic launched it in late 2024, and it keeps evolving: it’s versioned by date, not by version number.

MCP rests on three pillars worth being clear about before getting into the architecture:

• Open. Any compatible client talks to any compatible server, with no prior agreement between the people who built them.
• Client-server. The server exposes capabilities; the client consumes and controls them.
• JSON-RPC 2.0. All traffic between client and server goes through this message format.

We’ve been seeing the same pattern for years in software development projects: the more bespoke an integration is, the more expensive it gets to sustain if you ever have to change a single piece of the system. MCP carries that same principle over to the connection between models and external systems, with one added benefit: if you switch LLM provider tomorrow, your MCP server keeps working because it never depended on which model was on the other side.

Host, client and server: the roles in the protocol

Understanding who’s who in an MCP connection avoids a misunderstanding I’ve seen come up again and again: assuming the model accesses the data directly. That never happens, because between the model and the external system there are three pieces with separate responsibilities — host, client and server — and it’s precisely that separation that stops the model from touching anything on its own. It’s worth going through them one by one.

Host

This is the AI application the user interacts with: it hosts the MCP client (or clients) and manages the interaction with the model.

Client

It lives inside the host and does one thing only: connect to one specific MCP server — the relationship is always one to one. When the model wants to use a capability, it’s the client that formulates the JSON-RPC request and sends it to the server.

Server

It exposes those capabilities over the external system and answers the client’s request.

The lifecycle of a connection

Every connection goes through two phases.

• In initialisation there’s a handshake: client and server introduce themselves and negotiate which capabilities each one supports, because not every client supports all of them.
• Once that’s done, the operation phase begins: the normal flow of requests, responses and notifications for the rest of the session.

Transport: stdio and Streamable HTTP

The specification defines two transport standards:

• stdio for local connections — a development integration, a desktop tool —
• Streamable HTTP for remote connections, the usual option when the server is exposed to external users.

The old two-endpoint transport with HTTP + SSE was deprecated in the 2025-03-26 specification. A remote connection needs authentication: normally OAuth, which we go into in the second article of this series.

MCP tools vs resources vs prompts: what sets each one apart

The server can offer three types of capability and what distinguishes them is who decides when they get used:

1. Tools. Functions the model can invoke to query or act on the external system. The model controls them: it decides when to call them, with which arguments, and how to chain them until it has enough information to answer.
2. Resources. Read-only data, identified by URI, either text or binary. The application controls them: the host decides what it loads into the model’s context and when. Not every client consumes them the same way either: some let the user choose, others inject them directly.
3. Prompts. Predefined, parameterisable interaction templates, designed to be invoked as slash commands. The user controls them, deciding when to fire them.

A tool’s flow always follows the same pattern: the user asks in natural language, the model proposes calling a tool, the client executes that call against the server, and the response travels back until the model has what it needs to answer — or asks for another tool. That back and forth can repeat several times within a single turn, and it’s exactly what you see in the demo in the next section.

The protocol is also bidirectional: the server can ask things of the client.

• Roots. The client sets the boundaries of which file paths the server can operate on.
• Sampling. The server delegates to the client’s LLM to reason about something.
• Elicitation. The server asks the user for extra information midway through an operation.

In all three cases the client always mediates: the server never talks directly to the user, and the model never decides on its own which files to read. It’s the same control logic as the rest of the protocol, running in the opposite direction: every action always goes through the piece the protocol designated to decide it.

What it looks like in practice: a real query over Sherpa Platform data

Sherpa Platform is the outsourced financial management service we built at Orbitant for a client. A model being able to answer questions about a specific company’s sales or bank liquidity, without anyone hand-coding that answer, is exactly the scenario where MCP tools vs resources vs prompts stops being theory.

To check it against real code, we ran an internal training session where we put everything explained so far to the test, live, against Sherpa Platform’s MCP server.

Sales report

The opening query was deliberately open-ended: “give me a sales report for last month”, over data from a demo company. Since the question doesn’t mention any company, the first thing the model did, without anyone asking it to, was call the tool that lists the available company groups: it didn’t know which company it was being asked about, and that tool is the only way to resolve it.

With the company identified, it chained a call to the profit and loss report — because sales live there — and, in the same response, a search for sales documents from that period. All of that happened in seconds; on screen you only see the question and the final answer.

Bank liquidity and a chart

The second query asked for something different — bank liquidity, with an explicit request for a distribution chart — and the model responded with a different combination: first the bank liquidity tool, because it’s the only one that holds that data, and then building the requested chart, because that’s what it was asked to deliver.

Nobody told that model which tool to call first or in what order to combine them: it worked it out from the catalogue and from what it was asked. The design of the tools — their names, their descriptions, what each one promises to return — is what made that sequence possible. That design is the real interface the model works with.

The missing code and the full recording

That code — how Sherpa Platform’s MCP server is put together, and how OAuth authentication is added so that this smooth conversation doesn’t mean anyone with the URL can read any company’s data — is what we cover in the next article in this series.

Here’s the full recording, with this same demo live:

Frequently asked questions

Does MCP replace function calling in models?
It complements it. Function calling is the model’s ability to propose calling a function; MCP standardises how that function is discovered, exposed and executed against an external system, so you don’t reinvent that discovery layer in every integration.

Do you have to expose the MCP server over HTTP?
It depends on the use case. For local development or desktop tools, stdio is the usual option and needs no extra authentication. Streamable HTTP comes into play when the server has to be reachable remotely, and that’s where you need to think about authentication from the start.

What’s the difference between a tool and a resource?
The model invokes a tool when it decides it needs to run an action or a query; the application loads a resource, not the model: it’s read-only content identified by a URI. What changes is who has control over when that information enters the context.