Protocolo de contexto del modelo (MCP), y notas sobre la implementación del servidor MCP en Go

Artículo extenso sobre las especificaciones e implementación de MCP en GO

Índice

Aquí tenemos una descripción del Protocolo de Contexto del Modelo (MCP), notas breves sobre cómo implementar un servidor MCP en Go, incluyendo la estructura de mensajes y las especificaciones del protocolo.

Robots y MCP

Visión general del Protocolo de Contexto del Modelo (MCP)

El Protocolo de Contexto del Modelo (MCP) es un marco abierto y estandarizado (introducido por Anthropic a finales de 2024) para conectar modelos de lenguaje artificial a fuentes de datos externas, herramientas y sistemas. Su objetivo es resolver el problema de “N×M integración” proporcionando una interfaz universal para cosas como leer archivos, ejecutar funciones (herramientas) y usar prompts contextuales en diferentes aplicaciones. El MCP no es un protocolo propietario o interno; es un estándar abierto con una especificación oficial e implementación de referencia de código abierto. De hecho, principales proveedores de IA (incluyendo OpenAI y Google DeepMind) anunciaron su apoyo al MCP después de su introducción, lo que subraya que se pretende que sea un estándar ampliamente adoptado en lugar de una solución específica para un proveedor.

Propósito y arquitectura del MCP

El MCP tiene como objetivo estandarizar cómo las aplicaciones proporcionan contexto a LLMs – la analogía comúnmente utilizada es “un puerto USB-C para aplicaciones de IA”. Al definir un protocolo común, el MCP permite que asistentes de IA y herramientas interfazquen de forma fluida con bases de datos, sistemas de archivos, APIs y otros recursos sin integraciones personalizadas. Esto ayuda a los modelos de lenguaje a generar respuestas más relevantes y actualizadas al darles acceso seguro a los datos que necesitan.

Arquitectura: El MCP sigue un modelo cliente-servidor con una separación clara de roles:

  • Anfitrión MCP: La aplicación principal (por ejemplo, un cliente de chat o un IDE) que gestiona las conexiones. Contiene una o más clientes MCP (conectores).
  • Cliente MCP: Una instancia de conector (dentro del anfitrión) que establece una sesión 1:1 con un servidor MCP. El cliente maneja el ciclo de vida de la sesión, enruta mensajes y aplica cualquier permiso de usuario o política de seguridad.
  • Servidor MCP: Un servicio liviano que expone capacidades específicas (acceso a ciertos datos o funciones) mediante el protocolo MCP. Cada servidor puede envolver una fuente de datos (archivos, base de datos, API, etc.) o una herramienta. Pueden ejecutarse varios servidores en paralelo, cada uno proporcionando diferentes integraciones.
  • Fuentes de datos/servicios: Los recursos reales con los que los servidores se interfazan – esto puede incluir archivos y bases de datos locales o servicios remotos (APIs web, aplicaciones SaaS, etc.). El servidor MCP actúa como adaptador para estos recursos, asegurando que el LLM solo acceda a los datos a través del protocolo estandarizado.

Este diseño está inspirado en el Protocolo de Servidor de Lenguaje (LSP) del mundo de los IDE. Al igual que el LSP permite que cualquier editor soporte cualquier lenguaje de programación mediante un protocolo común, el MCP permite que cualquier aplicación de IA se conecte a cualquier integración de datos/herramientas que hable MCP. Esta desacoplación significa que los desarrolladores de herramientas de IA pueden escribir un servidor MCP una vez y que funcione con muchos clientes de IA, y los desarrolladores de aplicaciones de IA pueden agregar nuevas integraciones simplemente conectando un servidor MCP, evitando el código de integración personalizado.

Protocolo y estructura de mensajes

Comunicación: La comunicación del MCP se basa en sesiones persistentes y con estado utilizando mensajes JSON-RPC 2.0. Todos los pedidos y respuestas se ajustan al formato de JSON-RPC (con un campo "jsonrpc": "2.0", nombres de métodos, parámetros y IDs correlacionados). Cualquier lado – cliente o servidor – puede enviar pedidos o notificaciones, lo que permite una interacción bidireccional. Una sesión de MCP suele comenzar con un apretón de manos:

  • El cliente inicia con una solicitud initialize, proponiendo una versión del protocolo y anunciando sus capacidades (qué características soporta). Por ejemplo, el cliente podría indicar que puede manejar solicitudes de “muestreo” impulsadas por el servidor o proporcionar ciertos puntos de acceso para archivos. El servidor responde con su propia versión del protocolo soportada y capacidades, finalizando qué características están habilitadas para esta sesión (el MCP utiliza un sistema de negociación de capacidades similar a las características opcionales en el LSP). Si las capacidades críticas o la versión son incompatibles, la conexión se aborta con elegancia.
  • Al alcanzar un acuerdo, el cliente envía una notificación initialized para marcar su preparación. Después de esto, las operaciones normales pueden proceder. La sesión permanece abierta para un intercambio continuo de mensajes JSON-RPC hasta que un lado emita un cierre.

Transportes: El MCP no impone un solo transporte – funciona sobre cualquier canal que pueda transportar texto JSON. Comúnmente, un servidor MCP se ejecuta como un subproceso y se comunica a través de STDIO (tuberías stdin/stdout) para integraciones locales. Esto es análogo a cómo operan los servidores de lenguaje y es conveniente para herramientas locales (el anfitrión puede iniciar el proceso del servidor y canalizar mensajes). Alternativamente, los servidores MCP pueden ejecutarse como servicios independientes accesibles a través de HTTP. La especificación de MCP define un transporte de HTTP en streaming donde el servidor expone un solo punto final de HTTP para llamadas JSON-RPC (los clientes POSTean solicitudes y el servidor puede responder o enviar resultados mediante Server-Sent Events para operaciones de larga duración). En cualquier caso, los mensajes son líneas de JSON UTF-8, y el protocolo soporta respuestas en streaming y mensajes iniciados por el servidor (el enfoque HTTP+SSE permite que el servidor envíe notificaciones o resultados parciales de forma asincrónica). Las directrices de seguridad recomiendan que los servidores locales se enlacen a localhost y validen los encabezados Origin para prevenir el acceso remoto no deseado, y que se utilice una autenticación adecuada (por ejemplo, tokens o flujos OAuth) para servidores remotos.

Formato del mensaje: El MCP aprovecha los tres tipos de mensajes de JSON-RPC: Solicitudes, Respuestas y Notificaciones. Una solicitud contiene un id, una cadena method y (opcionalmente) params (normalmente un objeto JSON de argumentos). El receptor debe responder con una respuesta correspondiente (con un id coincidente) que contenga ya sea un result o un objeto error. Las notificaciones son como mensajes unidireccionales con un method y parámetros pero sin id (por lo tanto, no reciben una respuesta). El MCP impone algunas reglas adicionales sobre JSON-RPC base (por ejemplo, id debe ser no nulo y no reutilizado durante una sesión) para mantener la claridad.

Sesión y estado: La conexión se considera con estado – el cliente y el servidor mantienen contexto sobre las capacidades del otro y posiblemente algunos estados de sesión (como suscripciones a cambios, operaciones en curso, etc.). También hay procedimientos definidos para el cierre amable (por ejemplo, un cliente puede enviar una solicitud de cierre o simplemente cerrar el transporte; los servidores deben manejar la limpieza, y ambos lados implementan tiempos de espera para operaciones colgadas). El manejo de errores sigue las convenciones de JSON-RPC (las respuestas de error tienen un código y un mensaje) y la especificación define códigos de error estándar para ciertas condiciones (por ejemplo, permiso denegado, herramienta no encontrada, etc.). El MCP también proporciona utilidades para preocupaciones transversales: por ejemplo, hay notificaciones integradas para actualizaciones de progreso, cancelación de una solicitud de larga duración (CancelledNotification), mensajes de registro/depuración y cambios de configuración. Estas ayudan a gestionar interacciones largas o complejas (el cliente puede cancelar una llamada de herramienta en curso, o el servidor puede enviar advertencias al cliente, etc.).

Características y operaciones del MCP

Una vez inicializado, una sesión de MCP permite el intercambio de contexto y comandos de manera estructurada. Las características principales del lado del servidor de MCP son Prompts, Recursos y Herramientas (cada una de las cuales el servidor declara si la soporta durante la inicialización):

  • Prompts: Plantillas de prompt predefinidas o instrucciones que el servidor puede proporcionar al cliente. Estos suelen ser helpers activados por el usuario (el usuario elige explícitamente un prompt para insertarlo en la conversación, por ejemplo, mediante un comando de barra en la interfaz). El MCP proporciona métodos para listar los prompts disponibles y recuperar el contenido de un prompt. Por ejemplo, un cliente puede llamar a prompts/list para obtener una lista de plantillas de prompt (cada una con un nombre, descripción y parámetros opcionales). Para obtener un prompt, el cliente usa prompts/get con el nombre del prompt y cualquier valor de argumento; el servidor luego devuelve el contenido del prompt (a menudo como un conjunto de mensajes que el cliente inyectará en el contexto del LLM). Los prompts permiten reutilizar instrucciones o flujos de trabajo complejos (por ejemplo, “plantilla de revisión de código”) que un usuario puede invocar según sea necesario. Los servidores indican una capacidad prompts (con subcaracterísticas opcionales como listChanged para notificar al cliente si el conjunto de prompts cambia dinámicamente).

  • Recursos: Datos estructurados o contenido que proporcionan contexto al modelo. Los recursos suelen ser cosas como archivos, documentos, entradas de base de datos – información que un asistente de IA podría leer o referenciar. El MCP estandariza cómo se identifican y transfieren los recursos: cada recurso tiene un identificador URI (por ejemplo, file:///path/to/file.txt o un esquema personalizado para bases de datos). Los clientes pueden consultar qué recursos están disponibles mediante resources/list (el servidor puede exponer un árbol de directorios, una lista de documentos recientes, etc.). La respuesta del servidor incluye metadatos para cada recurso (URI, nombre, tipo, descripción, etc.). Luego, el cliente puede solicitar el contenido de un recurso específico con resources/read, pasando el URI. El servidor responde con el contenido del recurso, que podría ser texto (para archivos), o datos estructurados (el MCP soporta diferentes tipos de contenido, como texto, JSON, binario, etc., con tipos MIME). También hay soporte para plantillas de recursos (recursos parametrizados identificados por URI de plantilla, que el cliente puede completar, por ejemplo, una consulta de base de datos donde el usuario proporciona un parámetro). Si está habilitado, los servidores pueden enviar notificaciones cuando cambien los recursos (por ejemplo, notifications/resources/updated) o permitir que los clientes se suscriban a cambios en un recurso (resources/subscribe). En el diseño del MCP, los recursos son contexto controlado por la aplicación: la aplicación anfitriona (cliente) normalmente decide qué contenido de recurso alimentar realmente al prompt del modelo (a menudo después de la confirmación del usuario o según el contexto de la interfaz).

  • Herramientas: Funciones o acciones ejecutables que el servidor expone para que el modelo las invoque. Las herramientas representan operaciones que puede realizar el AI – por ejemplo, llamar a una API externa, ejecutar una consulta de base de datos, enviar un correo electrónico o modificar un archivo. Cada herramienta tiene un nombre y un esquema JSON para sus parámetros de entrada (y opcionalmente de salida), por lo que el AI (o cliente) sabe qué argumentos espera. Las herramientas suelen ser controladas por el modelo: la idea es que el modelo de lenguaje (agente) decida si y cuándo usar una herramienta durante una conversación para cumplir con la solicitud del usuario. Sin embargo, por seguridad, un usuario humano o la aplicación anfitriona pueden mediar el uso de herramientas (por ejemplo, requerir un clic de confirmación). El uso de herramientas en el MCP implica dos operaciones principales: listar y llamar. Un cliente puede llamar a tools/list para obtener las herramientas disponibles y sus esquemas. Por ejemplo, un servidor podría listar una herramienta get_weather con una descripción y un esquema de entrada que requiere una cadena “location”. Luego, cuando el modelo decida usar una herramienta (o el usuario la invoque), el cliente envía una solicitud tools/call con el nombre de la herramienta y un objeto JSON de argumentos. El servidor ejecuta la función y devuelve el resultado, típicamente como un campo result.content que puede contener texto o datos estructurados (el MCP soporta devolver múltiples partes de contenido, por ejemplo, texto más una imagen, etc., aunque el texto es común). Un ejemplo sencillo: llamar a una herramienta get_weather podría devolver una carga útil de texto como “Clima actual en Nueva York: 72°F, parcialmente nublado” como el contenido para que el asistente lo presente. Las herramientas también pueden indicar errores (la respuesta tiene una bandera isError o un objeto de error si algo salió mal). Al igual que los prompts y los recursos, la capacidad tools puede tener una bandera opcional listChanged para notificar cuando las herramientas disponibles cambien en tiempo de ejecución (por ejemplo, una carga o descarga de plugin dinámico).

Además de las características ofrecidas por el servidor mencionadas anteriormente, el MCP también define características ofrecidas por el cliente (capacidades que los servidores pueden aprovechar si el cliente las soporta). Estas incluyen Muestreo, Raíces y Elicitación:

  • Muestreo permite que un servidor solicite al cliente (y su LLM) que realice una inferencia del modelo dentro de la sesión. Por ejemplo, un servidor podría iniciar una llamada de LLM (posiblemente para continuar una cadena de pensamiento o para resumir algo) enviando una solicitud como sampling/request – el cliente luego promovería al modelo y devolvería el resultado. Esto permite comportamientos agenticos donde el servidor puede dirigir al AI para ayudar en sus propias subtareas. (Todas estas acciones están sujetas a la aprobación del usuario y a las políticas – por ejemplo, un usuario podría tener que optar por permitir que un servidor active el modelo para consultas adicionales.)

  • Raíces permite que el servidor consulte o opere dentro de ciertas raíces de sistema de archivos o URI permitidas. El cliente puede proporcionar una lista de “directorios raíz”/URI que el servidor está autorizado a acceder, mediante roots/list. Es una característica de seguridad que asegura que el servidor conozca los límites (por ejemplo, qué árboles de carpetas puede leer).

  • Elicitación permite que el servidor pida al cliente que obtenga más información del usuario si es necesario. Por ejemplo, si una herramienta necesita una pieza faltante de información que no se proporcionó, el servidor puede enviar una solicitud de elicición, que el cliente (interfaz de usuario) traduciría en un prompt para el usuario (“La integración X necesita su clave API, por favor ingrésela”). De esta manera, el servidor puede recopilar entradas interactivamente a través del cliente.

Estas características son todas opcionales y negociadas de antemano. Un aspecto clave del diseño del MCP es que la negociación de capacidades ocurre durante la inicialización – el cliente y el servidor anuncian qué características de las mencionadas anteriormente soportan, por lo que ambos lados conocen qué operaciones están disponibles en la sesión. Por ejemplo, si un servidor no declara la capacidad tools, el cliente no intentará ninguna operación tools/list o tools/call con él. Esta extensibilidad significa que el MCP puede evolucionar con nuevas características con el tiempo, manteniendo la compatibilidad hacia atrás (los métodos no soportados simplemente no se usarán si no se negocian).

Implementaciones, SDKs y construcción de un servidor MCP (especialmente en Go)

Especificación oficial y documentación: La especificación autoritativa de MCP está disponible públicamente, incluyendo un esquema formal de todos los tipos de mensajes. Se encuentra mantenida en el sitio web del Protocolo de Contexto del Modelo y en GitHub. La especificación se define en un archivo de esquema TypeScript (con un esquema JSON correspondiente) que documenta con precisión todas las solicitudes, respuestas y estructuras. El sitio de documentación (modelcontextprotocol.io) proporciona guías, un FAQ y desgloses detallados de cada característica y tipo de mensaje, así como una herramienta de “Inspector de MCP” para depuración interactiva. Aunque el MCP no es (aún) un estándar IETF o ISO, se desarrolla como un estándar abierto con entrada comunitaria y utiliza términos familiares de RFC 2119 para los requisitos. Es un protocolo en evolución (las versiones se marcan con fechas; por ejemplo, 2025-06-18 es una revisión reciente), con una política de versionado para gestionar los cambios.

Implementaciones de referencia: Anthropic abrió código fuente de varios conectores de servidor MCP y SDKs al introducir el MCP. Hay una organización de GitHub modelcontextprotocol que aloja la especificación y varios repositorios. Destacablemente, un repositorio “servers” contiene una colección de implementaciones de servidor MCP preconstruidas para servicios y fuentes de datos comunes. Estas sirven como integraciones de referencia y a menudo se pueden usar directamente o como plantillas para servidores personalizados. Por ejemplo, el repositorio oficial incluye servidores para Google Drive (acceso y búsqueda de archivos en Google Drive), Slack (mensajería de espacio de trabajo y contenido de canales), GitHub/Git (contexto de repositorio de código), PostgreSQL (consultas de base de datos de solo lectura con información de esquema), Google Maps (API de ubicación y direcciones), Puppeteer (navegación web y raspado), y muchos más. Al instalar o ejecutar estos servidores, una aplicación de IA como Claude o Cursor puede obtener inmediatamente esa integración. También hay un servicio de registro de MCP impulsado por la comunidad (abierto en Go) para indexar servidores disponibles, y muchas contribuciones de terceros que extienden el MCP a varios dominios (desde CRM hasta datos de blockchain).

SDKs y bibliotecas: Para facilitar la construcción de sus propios servidores/clientes MCP, hay SDKs oficiales en varios idiomas. Hasta 2025, el proyecto proporciona SDKs para TypeScript/Node, Python, Java (y Kotlin), C# (desarrollado con Microsoft), Ruby (con Shopify), Swift y otros. Estas bibliotecas manejan el “plomería” del protocolo – por ejemplo, gestionar el transporte JSON-RPC, implementar el esquema de especificación y proporcionar APIs de ayuda para registrar herramientas o servir recursos. Por ejemplo, el SDK de TypeScript se puede usar para escribir rápidamente un servidor en Node.js, y el SDK de Python permite integrar el MCP en aplicaciones de Python. El enfoque del SDK significa que los desarrolladores no tienen que construir manualmente mensajes JSON-RPC ni implementar la máquina de estado completa; en su lugar, llaman a métodos de alto nivel para enviar solicitudes o publicar capacidades.

Implementación en Go: Go se ha convertido en una opción popular para servidores MCP debido a su rendimiento y fortalezas en concurrencia (buena para manejar múltiples solicitudes simultáneas). Ahora está disponible un SDK oficial de Go, mantenido en colaboración con el equipo de Go en Google. (Esto se anunció alrededor de abril de 2025 y la primera versión estable está programada para agosto de 2025.) El SDK de Go proporciona un paquete mcp para construir clientes/servidores y un jsonschema helper para esquemas de herramientas. Usando el SDK de Go, los desarrolladores pueden crear un servidor MCP con solo unas pocas llamadas. Por ejemplo, se puede instanciar un nuevo servidor con un nombre y una versión, luego agregar herramientas mediante AddTool proporcionando una definición de herramienta (nombre, descripción, esquema de entrada) junto con una función de manejador de Go para ejecutar cuando se llama a esa herramienta. El SDK se encarga de exponer la herramienta en el protocolo (anunciándola en tools/list y manejando las solicitudes tools/call). De manera similar, se podrían exponer recursos o prompts con APIs análogas. Finalmente, se ejecuta el servidor – por ejemplo, server.Run(ctx, mcp.NewStdioTransport()) comenzará a procesar mensajes JSON-RPC a través de stdio hasta que el cliente se desconecte. Del lado del cliente, el SDK de Go puede generar un subproceso y conectarse mediante mcp.NewCommandTransport(exec.Command("myserver")), luego el cliente puede llamar a session.CallTool(ctx, params) para invocar una herramienta y obtener fácilmente el resultado en código Go.

Ejemplo: La documentación oficial del SDK de Go muestra un servidor “saludador” simple. El servidor registra una herramienta "greet" que toma un nombre y devuelve una cadena de saludo. Luego, el cliente llama a esta herramienta por nombre y imprime el resultado. Esto ilustra el patrón básico: definir herramienta -> cliente llama a herramienta -> obtener resultado. En segundo plano, esto corresponde a mensajes JSON-RPC ("method": "tools/call", params: {"name": "greet", ...} y la respuesta que contiene result.content con texto) como se define en la especificación de MCP.

Antes de que se lanzara oficialmente el SDK de Go, la comunidad creó sus propias bibliotecas de Go. Destacablemente, el proyecto mcp-go de Ed Zynda (mark3labs/mcp-go) se utilizó ampliamente y influyó en el diseño del SDK oficial. Otra biblioteca, mcp-golang de Metoro, proporcionó una implementación y API de Go (el post del blog de la comunidad Dev de Elton Minetto utiliza esta biblioteca a principios de 2025). Estas bibliotecas de SDK de la comunidad permitieron a los desarrolladores de Go experimentar con el MCP desde el principio – por ejemplo, un tutorial muestra cómo construir un servidor MCP que busca códigos postales brasileños (CEP) exponiendo una herramienta “zipcode” mediante la biblioteca mcp-golang de Metoro. En ese ejemplo, el servidor Go registra una función que llama a una API externa para encontrar una dirección desde un ZIP, y devuelve el resultado como texto – permitiendo que un asistente de IA obtenga información de dirección según sea necesario mediante el MCP. Otra guía demuestra envolver una base de datos en memoria personalizada (DiceDB) como un servidor MCP usando el SDK mcp-go de mark3labs: define una herramienta ping para verificar la conectividad de la base de datos y otras herramientas para operaciones de datos. Estos ejemplos destacan lo sencillo que puede ser crear una integración de MCP: la mayor parte del código es simplemente la lógica de negocio (llamadas a API, consultas a la base de datos, etc.), mientras que el SDK maneja el cableado JSON-RPC.

Construyendo un servidor MCP en Go (Resumen del tutorial)

Para esbozar el proceso, aquí hay un flujo típico usando el Go SDK o una biblioteca similar:

  1. Configurar el servidor: Inicializa una nueva instancia de servidor con información básica (nombre, versión y declara las capacidades admitidas). Por ejemplo, en Go: server := mcp.NewServer("MyServer", "1.0.0", nil) creará un servidor que, por defecto, admite características del protocolo principal. Puedes habilitar capacidades específicas como prompts/recursos/herramientas mediante opciones o simplemente registrando esas características (añadir una herramienta o un recurso implica esa capacidad).

  2. Registrar características: Añade las funcionalidades que deseas exponer:

    • Si estás exponiendo Herramientas, define el esquema de cada herramienta y su manejador. Por ejemplo, usando AddTool del SDK de Go: proporciona un mcp.Tool{Name: "...", Description: "..."} y una función manejadora que tome la solicitud de llamada y devuelva un resultado (que puede incluir texto u otro contenido). El SDK generará automáticamente un esquema JSON para las entradas basado en los tipos de parámetros de tu función manejadora (o puedes especificarlo tú mismo).
    • Si estás exponiendo Recursos, podrías usar una API para registrar listados de recursos o un callback para leer contenido. Por ejemplo, en el SDK de Python, puedes subclasear un ResourceProvider; en Go, el SDK aún está evolucionando, pero probablemente proporcionarías funciones para listar y leer recursos. Cada recurso debe tener una URI estable.
    • Si estás exponiendo Prompts, define plantillas de prompt (pueden ser archivos estáticos o cadenas) y regístralas con nombres y parámetros opcionales. El servidor los anunciará para que el cliente los pueda recuperar y mostrar a los usuarios.

  3. Implementar el transporte: Decide cómo funcionará el servidor. Lo más sencillo para uso local es el stdio – por ejemplo, server.Run(ctx, mcp.NewStdioTransport()) en Go comenzará a leer JSON-RPC desde stdin. Si tu servidor debe ser accesible en red, podrías implementar un manejador HTTP que use el SDK de Go para aceptar JSON-RPC a través de HTTP (el SDK oficial de Go podría incluir pronto un helper para el transporte HTTP/SSE también).

  4. Pruebas con el cliente: Puedes probar el servidor con un cliente compatible con MCP. Por ejemplo, Anthropic’s Claude 2 (Claude para Desktop) admite cargar servidores MCP locales; configurarías Claude para lanzar o conectarse a tu binario de servidor. También hay una herramienta CLI llamada mcp-cli y la interfaz gráfica MCP Inspector para probar servidores sin necesidad de un cliente AI completo – estas herramientas envían solicitudes MCP a tu servidor y muestran los resultados, ayudando con la depuración.

  5. Seguridad y permisos: Al construir un servidor, considera la autenticación y el ámbito. Para servidores locales, el host podría ejecutarlo con ciertos permisos del sistema operativo o proporcionar claves API a través del entorno. Para servidores remotos, usa encabezados de autenticación u flujos OAuth. MCP incluye una especificación de autorización para transportes HTTP (el servidor puede requerir un token y el cliente puede enviarlo). Siempre asegúrate de que el servidor solo acceda a los datos que el usuario permitió (por ejemplo, respeta las carpetas raíz proporcionadas por el cliente y no filtre datos en otro lugar) – las directrices de MCP enfatizan el consentimiento del usuario, la privacidad de los datos y la seguridad de las herramientas como fundamentales.

En resumen, MCP es un protocolo formal pero flexible para conectar LLMs con el mundo exterior. No es un API interno ligado a una sola empresa, sino un estándar abierto con creciente adopción y una rica ecosistema de integraciones. El protocolo define estructuras claras de mensajes (basadas en JSON-RPC) y un conjunto de operaciones (métodos para prompts, herramientas, recursos, etc.) que cualquier cliente/servidor compatible puede implementar. La documentación oficial y las especificaciones están disponibles, y numerosos SDKs, bibliotecas y servidores de ejemplo (incluyendo en Go) facilitan su implementación. Al usar MCP, los desarrolladores pueden construir aplicaciones IA que aprovechen de manera segura datos y servicios existentes, sin tener que reinventar la lógica de integración para cada nuevo modelo o conjunto de datos.

Enlaces útiles