MCP tools, resources y prompts: qué puede hacer cada pieza de un servidor MCP
Publicado el 2026-10-26 por frfrand
Explicar el protocolo MCP y cómo elegir tools, resources y prompts
Cuando conectás una IA con herramientas de servidores aparece una pregunta importante: ¿qué puede hacer y qué sólo puede consultar? MCP separa herramientas que ejecutan acciones, recursos que aportan contexto y prompts que estructuran interacciones.
Vamos a bajarlo a tierra: qué significa, cómo se prueba y qué pasa cuando lo usás con clientes o información real. La mayoría de los problemas no se arregla con un botón mágico, sino con pasos que podés repetir y medir.
Qué es MCP tools, resources y prompts y por qué importa
Model Context Protocol define capacidades para que un cliente interactúe con servidores MCP. Las tools pueden tener efectos reales, como crear recursos; los resources exponen contenido identificable; y los prompts entregan plantillas de mensajes. El soporte concreto varía según cliente y servidor.
Una cosa es que una demo funcione cinco minutos y otra es sostener un servicio todos los días. Para eso necesitás límites, permisos, registros de actividad y procedimientos para resolver fallos sin improvisar.
Ejemplo de implementación o diagnóstico
// 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"]
}
}Es una referencia didáctica, no una plantilla que debas ejecutar a ciegas en producción. Sustituí los valores de ejemplo, elegí identidades con permisos mínimos y asegurate de que ninguna clave sensible termine en un log o repositorio.
Cómo lo pondría a funcionar
- Definí primero qué necesita lograr el agente y qué información basta con leer.
- Creá herramientas de solo lectura para consultas frecuentes y acciones separadas para cambios.
- Describí parámetros, efectos y errores en un esquema que el cliente pueda entender.
- Pedí confirmación para operaciones destructivas o de alto impacto según el producto.
- Registrá la identidad, recurso afectado y resultado de cada operación ejecutada.
Después de cada paso, verificá un resultado concreto: una acción autorizada, un estado HTTP, una tarea procesada, un costo registrado o una métrica estable. Si algo no funciona, comprobá cuál fue el primer fallo antes de reintentar en bucle.
Un ejemplo que puede aparecer en un proyecto real
Una agencia pregunta a una IA qué apps hay en su VPS. Listar servicios puede ser una tool de consulta. Reiniciar una API es otra tool distinta, con permisos, confirmación y logs. Mezclarlas en una herramienta genérica de terminal aumenta riesgo.
Si esa aplicación tiene varios clientes, separá contextos y recursos. Es especialmente importante cuando un chatbot o un agente puede consultar datos: la facilidad de conectar herramientas no debe saltarse los límites de privacidad y autorización.
El error más común
No creas que por poner la palabra «read-only» en la descripción una herramienta es segura: el backend debe aplicar permisos reales. Un resource con secretos tampoco debería ser accesible a cualquier cliente conectado.
Una configuración con buenos defaults ayuda, pero no elimina la necesidad de pruebas. Para servicios que escriben datos o disparan acciones, contemplá reintentos, duplicados y fallos a mitad de camino.
¿Dónde entra ArduMaker?
El MCP de ArduMaker permite administrar recursos de la plataforma mediante agentes compatibles. Diseñá qué operaciones puede hacer cada identidad y verificá sus permisos, especialmente en entornos multiempresa.
Con ArduMaker podés alojar el backend en un VPS, desplegar desde Git, configurar dominio HTTPS y utilizar herramientas de bases, servicios y MCP según el proyecto. Eso facilita reunir operaciones en un entorno, aunque las reglas de negocio y de seguridad siguen siendo responsabilidad del software.
Qué mediría para saber si mejoró
No mediría sólo «funciona/no funciona». También revisaría consumo de recursos, errores, tiempos de respuesta o gasto de API, según la funcionalidad. Definí una medida de éxito antes del cambio y compará con el mismo escenario después.
Si un dato parece extraño, comprobá la muestra y la ventana temporal. Un promedio puede esconder casos extremos, y una única ejecución exitosa no demuestra que una automatización soporte miles de solicitudes.
Preguntas frecuentes
¿Necesito una infraestructura grande para empezar? No necesariamente. Primero resolvé el problema con una arquitectura simple y medí el punto donde empieza a quedarse corta.
¿Qué pasa si falla el proveedor externo? Necesitás timeouts, política de reintentos y una respuesta útil para el usuario. No asumas que las APIs externas están siempre disponibles.
¿Cómo mantengo el control? Registrá eventos importantes, separá permisos y conservá un procedimiento probado para deshacer cambios o recuperar información.
Referencias para seguir
La idea final: automatizar y medir vale la pena cuando también sabés detectar un error, limitar sus efectos y recuperarte.