5 cosas que debes saber sobre MCP (Model Context Protocol)

Un agente puede redactar una consulta SQL, pero eso no significa que tenga acceso a una base de datos. También puede explicar cómo crear un issue en GitHub sin tener permiso para hacerlo. Para actuar sobre sistemas externos necesita una integración. El problema aparece cuando cada aplicación y cada servicio resuelven esa integración de una manera distinta.

Model Context Protocol (MCP) ofrece un protocolo abierto para conectar aplicaciones de IA con herramientas y fuentes de información a través de interfaces comunes. No sustituye al modelo, al agente ni a los controles de seguridad del sistema.

Estas son cinco ideas que conviene comprender antes de instalar o desarrollar un servidor MCP.

1. MCP es un protocolo, no un modelo de IA

MCP define cómo una aplicación de IA y un servidor intercambian información sobre capacidades disponibles y cómo se invocan esas capacidades. El modelo puede participar decidiendo cuándo utilizar una herramienta, pero el modelo no es MCP.

Una comparación útil: una API define operaciones de un servicio; MCP permite describir y utilizar capacidades en un formato que distintos clientes de IA pueden reconocer. No convierte automáticamente cualquier API en una herramienta segura ni elimina el código necesario para integrarla.

2. Su arquitectura separa host, cliente y servidor

En una integración típica hay tres piezas:

Host: aplicación donde trabaja el usuario, por ejemplo un asistente de programación compatible con MCP. Gestiona la experiencia y las conexiones.
Cliente MCP: componente del host que establece la comunicación con un servidor MCP. Conceptualmente, cada conexión cuenta con su cliente.
Servidor MCP: programa que expone capacidades concretas hacia el host a través del protocolo.

Diagrama conceptual: un host suele administrar una conexión de cliente por cada servidor; aquí se agruparon para facilitar la lectura.

3. Un servidor expone capacidades específicas

Un servidor MCP puede ofrecer operaciones sobre GitHub, un sistema de archivos, un catálogo de productos o una API empresarial. Solo expone las capacidades que su implementación y configuración permiten.

Por ejemplo, un servidor diseñado para revisar un catálogo de food trucks podría ofrecer buscar_foodtrucks(pueblo) sin permitir modificar los registros. Eso es preferible a exponer una herramienta genérica que ejecute SQL arbitrario.

Los servidores pueden ejecutarse localmente, comunicándose mediante entrada y salida estándar (stdio), o de forma remota mediante transportes compatibles como Streamable HTTP. Elegir un transporte depende de dónde vive la integración, quién la utiliza y cómo se gestionan los accesos.

4. Tools, Resources y Prompts tienen responsabilidades distintas

Capacidad	Función	Ejemplo
Tools	Ejecutar operaciones o consultar datos mediante funciones	`buscar_foodtrucks("Ponce")`
Resources	Exponer contenido que el cliente puede leer	Manual interno de una API
Prompts	Ofrecer plantillas de interacción reutilizables	«Analiza esta incidencia y propone un plan»

No todas las aplicaciones muestran estas capacidades de la misma forma. Una herramienta puede solicitarse desde una interacción con el modelo; un recurso puede ser seleccionado por el cliente y un prompt puede ser elegido por el usuario. Su disponibilidad depende de lo que el servidor anuncie y el host soporte.

MCP no es lo mismo que un Skill

Un Skill suele describir un procedimiento: qué pasos seguir, qué criterios aplicar y qué formato entregar. Un servidor MCP ofrece capacidades de integración: qué información consultar o qué acción ejecutar. Un agente puede seguir un Skill que le indique usar una herramienta MCP, pero ninguna de las dos piezas sustituye a la otra.

5. Conectarse no significa tener permiso ilimitado

El protocolo facilita una interfaz común; la autorización real debe implementarse en el host, en el servidor y en los sistemas de destino según corresponda. Antes de habilitar una integración:

Inspecciona las herramientas ofrecidas y evita instalar servidores desconocidos con acceso amplio.
Usa credenciales de alcance mínimo y no las incluyas en prompts ni repositorios.
Separa operaciones de lectura y escritura; considera confirmación humana para cambios destructivos.
Valida entradas en el servidor y aplica autorización en cada operación que lo necesite.
Registra actividades relevantes sin almacenar secretos o datos sensibles innecesarios.

También hay riesgos de instrucciones maliciosas contenidas en respuestas de herramientas o documentos externos. El hecho de que un dato llegue por MCP no lo convierte en una instrucción confiable.

Ejercicio: tu primer servidor MCP con .NET 10

Crearemos un servidor local de solo lectura que devuelve información de un catálogo de ejemplo. No requiere base de datos, credenciales ni un servicio externo. El cliente MCP compatible podrá descubrir la herramienta y ejecutarla.

Requisitos: .NET 10 SDK y un host compatible con servidores MCP por stdio.

Paso 1. Crear el proyecto

dotnet new console -n BoricuaCoder.McpDemo -f net10.0
cd BoricuaCoder.McpDemo
dotnet add package ModelContextProtocol
dotnet add package Microsoft.Extensions.Hosting

Paso 2. Reemplazar `Program.cs`

using System.ComponentModel;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Logging;
using ModelContextProtocol.Server;

var builder = Host.CreateApplicationBuilder(args);

// En stdio, los mensajes de protocolo usan stdout.
// Los logs se envían a stderr para no romper la comunicación.
builder.Logging.AddConsole(options =>
{
    options.LogToStandardErrorThreshold = LogLevel.Trace;
});

builder.Services
    .AddMcpServer()
    .WithStdioServerTransport()
    .WithToolsFromAssembly();

await builder.Build().RunAsync();

[McpServerToolType]
public static class CatalogTools
{
    [McpServerTool, Description("Lista los pueblos disponibles en el catálogo de ejemplo.")]
    public static string ListTowns() => "Ponce, Bayamón, Caguas";

    [McpServerTool, Description("Busca food trucks de ejemplo por pueblo, sin modificar datos.")]
    public static string FindFoodTrucks(
        [Description("Pueblo que deseas consultar.")] string town)
    {
        var catalog = new Dictionary<string, string[]>(StringComparer.OrdinalIgnoreCase)
        {
            ["Ponce"] = ["Ruta del Sabor", "Cocina Sobre Ruedas"],
            ["Bayamón"] = ["Sabor Urbano"],
            ["Caguas"] = ["Parada Criolla"]
        };

        return catalog.TryGetValue(town.Trim(), out var trucks)
            ? string.Join(", ", trucks)
            : "No hay resultados en este catálogo de demostración.";
    }
}

Los nombres del catálogo son datos ficticios para el ejercicio. Los atributos [McpServerToolType] y [McpServerTool] permiten al SDK encontrar las herramientas cuando se utiliza WithToolsFromAssembly().

Paso 3. Compilar y conectar

dotnet build

Configura tu host MCP para iniciar el proceso dotnet con estos argumentos (ajusta la ruta absoluta al directorio del proyecto):

{
  "command": "dotnet",
  "args": [
    "run",
    "--no-build",
    "--project",
    "/ruta/absoluta/BoricuaCoder.McpDemo/BoricuaCoder.McpDemo.csproj"
  ]
}

Este bloque describe el comando y sus argumentos; no es un archivo de configuración universal. Cada host tiene su propio formato y ubicación para registrar servidores. Consulta la documentación de tu cliente y evita ejecutar el servidor directamente en una terminal esperando texto interactivo: stdio intercambia mensajes de protocolo, no un menú.

Paso 4. Probar las herramientas

Desde el host, comprueba que se descubran ListTowns y FindFoodTrucks. Prueba solicitudes como:

¿Qué pueblos están disponibles en el catálogo de demostración?

Busca los food trucks de Ponce utilizando la herramienta MCP.

Revisa si la aplicación mostró o solicitó autorización para ejecutar la herramienta y verifica la respuesta. Si el servidor no aparece, confirma la ruta, las dependencias y que no haya mensajes impresos manualmente en stdout.

Beneficios y limitaciones

Beneficios: interfaces consistentes para integraciones, reutilización de servidores entre hosts compatibles y una división clara entre agente y servicio externo.

Limitaciones: cada integración requiere operaciones reales, permisos y mantenimiento; los clientes no admiten necesariamente todas las capacidades; el protocolo no garantiza la calidad de la información ni la seguridad de una herramienta.

Errores comunes

Instalar cualquier servidor sin revisarlo. Un servidor es software con permisos reales.
Confundir conexión con autorización. Estar conectado no justifica acceder a todos los datos.
Exponer una acción demasiado genérica. Mejor una herramienta de negocio limitada que ejecutar comandos arbitrarios.
Tratar la salida externa como instrucciones. Los resultados de herramientas pueden contener contenido no confiable.
Mezclar logs con stdout en stdio. Puede impedir que el cliente interprete los mensajes del protocolo.

Un caso de uso realista

Imagina un portal de administración donde un agente necesita responder: «¿Cuántos registros pendientes hay en Ponce?». Un servidor MCP podría exponer contar_registros_pendientes(pueblo) y consultar una API interna usando credenciales controladas. Así el agente no recibe acceso directo a toda la base de datos; obtiene una capacidad acotada. Si después se necesitara aprobar registros, sería una herramienta separada con controles y autorizaciones adicionales.

Reflexión final

MCP resuelve un problema de integración, no uno de razonamiento. Conocer sus componentes ayuda a decidir qué conviene conectar y qué no debería quedar al alcance de un agente. Empieza con una herramienta de solo lectura, comprueba su comportamiento y amplía las capacidades únicamente cuando exista una necesidad real.

Si vienes de la serie de BoricuaCoder, la relación es esta: un agente realiza tareas; un Skill le aporta procedimientos; un Harness ayuda a ejecutar y controlar acciones; un Workflow organiza etapas; MCP estandariza conexiones con capacidades externas.