Conectar una IA a un servidor MCP no significa simplemente "dar acceso al servidor". El protocolo de contexto modelo separa lo que ofrece un servidor en tres primitivas centrales: herramientas, recursos y indicaciones. Representan diferentes superficies: funciones ejecutables, datos utilizados como contexto y plantillas de interacción.
Esta distinción es importante porque el riesgo de una integración no depende solo del nombre del servicio conectado. Un servidor de calendario, por ejemplo, puede proporcionar un recurso para consultar citas, una herramienta para crear eventos y un aviso que organiza un flujo de planificación. Saber que el servidor "accede al calendario" todavía no explica qué podrá leer, ejecutar o qué podrá hacer la IA.
La referencia utilizada aquí es la especificación MCP 2026-07-28, publicada el 28 de julio de 2026 y vigente a la fecha de esta revisión. Esta versión mantuvo herramientas, recursos y avisos como primitivos del servidor central, aunque cambió otras partes importantes del protocolo.
La propia documentación de MCP asocia un modelo de control diferente con cada primitiva. Las herramientas están diseñadas para ser controladas por el modelo; recursos, por la aplicación; indicaciones, por parte del usuario. Esto describe quién normalmente decide cuándo se utiliza esa capacidad, no quién tiene la autorización final sobre los sistemas externos.
| Primitivo |
Qué ofrece el servidor |
Control típico |
Pregunta principal al revisar |
| Herramientas |
Funciones ejecutables que pueden consultar sistemas, llamar a API, calcular o producir efectos externos |
Modelo, sujeto a controles del cliente |
¿Qué puede hacer esta función y qué datos recibe? |
| Recursos |
Datos y contenido que se pueden recuperar como contexto, identificados por URI |
Aplicación |
¿Qué información se puede leer y poner en el contexto de la IA? |
| Indicaciones |
Plantillas de instrucciones y mensajes personalizables con argumentos y definidos por el servidor |
Usuario |
¿Qué instrucción elijo y qué otras características incorpora? |
Esta clasificación es más útil que dividir MCP simplemente en “lectura” y “escritura”. Una herramienta puede simplemente consultar una base de datos, sin modificar nada. Al mismo tiempo, otra herramienta puede enviar un correo electrónico, crear un evento o cambiar un archivo. El hecho de que ambas sean herramientas indica que son operaciones invocables, no que tengan el mismo nivel de riesgo.
Las herramientas son operaciones que la IA puede solicitar
Una herramienta es una interfaz ejecutable descrita por el servidor. Tiene un nombre, una descripción, un esquema de entrada y, opcionalmente, un esquema de salida. El modelo puede descubrir las herramientas disponibles y solicitar una ejecución a través de herramientas/llamada.
Aquí es donde generalmente aparecen las capacidades más fáciles de reconocer como “acciones”: crear una cita, enviar un mensaje, modificar un archivo o llamar a una API.. Pero las herramientas también pueden realizar operaciones sin efectos de escritura, como buscar vuelos, consultar datos o realizar cálculos. La pregunta correcta, por lo tanto, no es simplemente “¿este servidor tiene herramientas?”, sino qué operaciones implementa cada herramienta.
La especificación llama a este modelo controlado por modelo: la IA puede descubrir e invocar automáticamente herramientas según el contexto y la solicitud del usuario. Esto no significa que el protocolo requiera una ejecución ilimitada. La propia especificación recomienda mantener una persona capaz de denegar llamadas y guiar las aplicaciones para aclarar las herramientas expuestas, señalar ejecuciones y presentar confirmaciones.
Para operaciones sensibles, la recomendación técnica va más allá de un simple botón de "conexión". Los clientes deben considerar la confirmación del usuario, mostrar los datos que se enviarán a la herramienta antes de la llamada, validar los resultados y registrar el uso para la auditoría.
Esto crea una distinción importante: la existencia de una herramienta en el catálogo de servidores no equivale, en sí misma, a una autorización incondicional para utilizarla. El host o cliente de MCP aún puede aplicar sus propias políticas, permisos y confirmaciones.
Los recursos son datos disponibles como contexto
Recursos representan información que el servidor pone a disposición para lectura: contenido de archivos, registros, esquemas de bases de datos, documentación o información específica de la aplicación. Cada recurso tiene un URI que lo identifica.
A diferencia de las herramientas, los recursos se describen como basados en aplicaciones. La aplicación anfitriona decide cómo incorporar estos datos. Puede ofrecer un selector manual, permitir la búsqueda y el filtrado, o incluso agregar contexto automáticamente mediante heurística o selección asistida por IA. El protocolo no requiere el uso de una única interfaz.
Esto también significa que "recurso" no debe entenderse como "datos que la IA siempre verá". El servidor puede proporcionar un catálogo de recursos, pero depende del cliente decidir cómo recuperarlos y cuándo colocarlos en el contexto del modelo.
La superficie de visualización, sin embargo, sigue siendo relevante. Un recurso puede representar un documento interno, un calendario, información de una API u otro contenido confidencial. La especificación requiere la validación de los URI y recomienda controles de acceso y verificación de permisos para recursos protegidos.
Los recursos aún pueden usar plantillas de URI. En lugar de presentar sólo direcciones fijas, un servidor puede ofrecer plantillas parametrizadas para recuperar diferentes conjuntos de datos. La documentación actual también proporciona recursos de texto y binarios, así como metadatos que ayudan al cliente a decidir cómo utilizarlos.
Por lo tanto, al analizar una conexión, los recursos responden principalmente a la pregunta: ¿qué información puede este servidor entregar al cliente y potencialmente colocar frente al modelo?
Las indicaciones son plantillas proporcionadas por el servidor
En MCP, los mensajes no son solo el mensaje que el usuario escribe en la conversación.. Son plantillas estructuradas publicadas por el propio servidor y recuperables por el cliente. Pueden aceptar argumentos para personalizar un flujo, como una plantilla para revisar el código, planificar o redactar un mensaje.
Aquí hay un matiz importante. Las indicaciones se describen como controladas por el usuario porque la intención es que el usuario elija explícitamente cuándo usarlas. Sin embargo, el contenido de la plantilla lo define el servidor. La especificación hace esta distinción explícitamente.
Un mensaje tampoco necesita funcionar de forma aislada. Puede contener texto, imágenes y otros tipos de contenido, así como recursos de referencia o incrustados. Esto le permite crear flujos en los que la plantilla ya reúne instrucciones y contexto proporcionado por el servidor.
Además, un mensaje puede guiar al modelo para que funcione con determinadas herramientas. Por lo tanto, clasificarlo como “sólo texto” puede minimizar su importancia. El mensaje no ejecuta una herramienta en sí, pero puede estructurar la interacción que llevará al modelo a solicitar una acción disponible.
La especificación actual también exige que las implementaciones validen las indicaciones de entrada y salida para reducir riesgos como la inyección de instrucciones y el acceso no autorizado a los recursos.
Las tres primitivas pueden aparecer combinadas
Las herramientas, los recursos y las indicaciones son categorías distintas, pero no forman compartimentos cerrados.
Una herramienta puede devolver contenido estructurado, enlaces a recursos o incluso recursos integrados. Del mismo modo, los mensajes de un mensaje pueden contener referencias o contenidos de recursos.
Imagine un servidor conectado al correo electrónico y al calendario. Podría ofrecer un recurso para recuperar próximas citas, una herramienta para crear un nuevo evento y un mensaje llamado "organizar mi semana", que estructura las instrucciones e incorpora información relevante.
En este escenario, evaluar solo la herramienta que crea eventos dejaría fuera parte de la superficie de exposición. El recurso determina qué información se puede recuperar; el mensaje puede influir en cómo se combinan esta información y herramientas.
Por lo tanto, una revisión técnica útil comienza con el catálogo completo de capacidades, y solo luego pasa a los permisos otorgados.
Lo que ofrece el servidor y lo que tú autorizas son cuestiones diferentes
La especificación permite que los conjuntos de herramientas, recursos y mensajes disponibles varíen dependiendo de la autorización presentada en la solicitud. En otras palabras, el servidor puede poseer una capacidad sin necesariamente dársela a cada usuario o cada token de acceso.
La documentación de seguridad de MCP también recomienda minimizar los alcances. Los permisos demasiado amplios aumentan el impacto de un token comprometido, hacen que las auditorías sean menos claras y pueden permitir el acceso a operaciones no relacionadas con la necesidad inicial. La guía actual propone un modelo progresivo de privilegios mínimos, con elevación del alcance cuando una operación realmente requiere más acceso.
Esto ayuda a separar dos pasos que a menudo se confunden:
Primero, haga un inventario de la capacidad técnica. Descubra qué herramientas se pueden llamar, qué recursos se pueden leer y qué mensajes publica el servidor.
Luego evalúe la autorización. Compruebe cuáles de estas capacidades estarán disponibles con las credenciales otorgadas, a qué datos externos llegan y qué acciones requieren confirmación.
Una pantalla de consentimiento genérica podría indicar que un servicio tendrá acceso al calendario. El catálogo de MCP puede revelar que, técnicamente, existen operaciones muy diferentes bajo esta misma etiqueta: buscar eventos, leer detalles, crear citas o ejecutar otros flujos. El nivel de revisión debe rastrear la operación real, no solo el nombre de la integración.
Cómo analizar un servidor MCP antes de conectarlo
Al revisar una integración, comience verificando si el cliente le permite ver lo que ofrece el servidor. Para herramientas, busque nombres, descripciones, parámetros de entrada y propósito de cada operación. La especificación guía las aplicaciones para dejar claras las herramientas disponibles para el modelo.
A continuación, identifique los recursos. La cuestión no es sólo contar cuántos hay, sino comprender el dominio de los datos: archivos locales, documentos corporativos, bases de datos, mensajes, calendario u otra fuente. Los recursos sensibles deben tener sus propios controles de acceso.
Revise también las indicaciones disponibles. Como el contenido lo define el servidor, una plantilla merece ser tratada como parte de la integración y no como un simple acceso directo a la interfaz. Observa qué instruye, qué argumentos recibe y si incorpora recursos.
Finalmente, compare este inventario con lo que se solicita en la autorización. La documentación oficial recomienda autorización para servidores que manejan datos de usuario específicos u operaciones que dependen del consentimiento y destaca la minimización de alcances como medida de seguridad.
El resultado de este análisis debería permitirnos responder preguntas más concretas que "¿confío en este MCP?": ¿qué datos puede proporcionar, qué operaciones ofrece, qué plantillas pueden guiar la interacción y qué parte de todo esto estoy autorizando realmente?
Una vez que comprenda lo que el servidor puede exponer, la siguiente decisión es cuánto acceso otorgar. Para este paso, consulte también “Antes de conectar un agente de IA a su correo electrónico, calendario y navegador: qué revisar” y revise los permisos, las confirmaciones y el alcance de las credenciales antes de completar la conexión.
Temas de este articuloAgentes de IAIntegraçõesMCPModel Context ProtocolPermissões de acessosegurança de IA
