MCP tools, resources and prompts: what each piece of an MCP server can do
Published on 2026-10-26 by frfrand
Explain the MCP protocol and how to choose tools, resources, and prompts
When you connect an AI with server tools an important question arises: what can it do and what can it only query? MCP separates tools that execute actions, resources that provide context, and prompts that structure interactions.
Let's get down to earth: what it means, how to test it, and what happens when you use it with clients or real information. Most problems are not fixed with a magic button, but with steps you can repeat and measure.
What MCP tools, resources, and prompts are and why they matter
Model Context Protocol defines capabilities for a client to interact with MCP servers. Tools can have real effects, such as creating resources; resources expose identifiable content; and prompts deliver message templates. Concrete support varies by client and server.
One thing is for a demo to work for five minutes and another is to sustain a service every day. For that you need limits, permissions, activity logs, and procedures to resolve failures without improvising.
Implementation or diagnosis example
// Ejemplo conceptual de herramienta MCP
{
"name": "listar_servicios_vps",
"description": "Consulta servicios sin modificarlos",
"inputSchema": {
"type": "object",
"properties": { "vps_id": { "type": "integer" } },
"required": ["vps_id"]
}
}It is a didactic reference, not a template you should blindly run in production. Replace the example values, choose identities with minimal permissions, and make sure no sensitive key ends up in a log or repository.
How I would put it into operation
- Define first what the agent needs to achieve and what information is enough to read.
- Create read-only tools for frequent queries and separate actions for changes.
- Describe parameters, effects, and errors in a schema that the client can understand.
- Request confirmation for destructive or high-impact operations according to the product.
- Record the identity, affected resource, and result of each executed operation.
After each step, verify a concrete result: an authorized action, an HTTP status, a processed task, a recorded cost, or a stable metric. If something does not work, check what the first failure was before retrying in a loop.
An example that may appear in a real project
An agency asks an AI what apps are on its VPS. Listing services can be a query tool. Restarting an API is another distinct tool, with permissions, confirmation, and logs. Mixing them into a generic terminal tool increases risk.
If that application has several clients, separate contexts and resources. It is especially important when a chatbot or an agent can query data: the ease of connecting tools must not bypass privacy and authorization limits.
The most common error
Do not think that putting the phrase "read-only" in the description makes a tool safe: the backend must apply real permissions. A resource with secrets should also not be accessible to any connected client.
A configuration with good defaults helps, but does not eliminate the need for testing. For services that write data or trigger actions, consider retries, duplicates, and midway failures.
Where does ArduMaker come in?
ArduMaker's MCP allows managing platform resources through compatible agents. Design what operations each identity can perform and verify their permissions, especially in multi-tenant environments.
With ArduMaker you can host the backend on a VPS, deploy from Git, configure an HTTPS domain, and use database, service, and MCP tools according to the project. This makes it easier to gather operations in one environment, although business and security rules remain the responsibility of the software.
What I would measure to know if it improved
I would not measure only "works/does not work". I would also review resource consumption, errors, response times, or API usage, depending on the functionality. Define a success metric before the change and compare it with the same scenario afterward.
If a piece of data seems strange, check the sample and the time window. An average can hide extreme cases, and a single successful run does not prove that an automation can handle thousands of requests.
Frequently asked questions
Do I need a large infrastructure to get started? Not necessarily. First solve the problem with a simple architecture and measure the point where it starts to fall short.
What happens if the external provider fails? You need timeouts, a retry policy, and a useful response for the user. Do not assume external APIs are always available.
How do I maintain control? Log important events, separate permissions, and keep a tested procedure to undo changes or recover information.
References to follow
Final idea: Automating and measuring is worth it when you also know how to detect an error, limit its effects, and recover.