Model Context Protocol: Crea tu primer servidor MCP hoy

El Model Context Protocol (MCP) es un estándar abierto que da a los modelos de IA una forma universal de conectarse a herramientas externas, fuentes de datos y servicios. En lugar de escribir código de integración personalizado para cada combinación modelo-herramienta, escribes un único servidor MCP y cada modelo compatible puede usarlo. Anthropic creó MCP a finales de 2024, la Linux Foundation lo gobierna ahora, y OpenAI, Google y el resto del ecosistema de IA agéntica lo han adoptado. Aquí está todo lo que necesitas entender, construir y desplegar con MCP.

MCP de un vistazo

Si quieres la versión rápida antes de sumergirte en 6.000 palabras de detalles, aquí está.

Ahora vamos a desempacar cada uno de estos puntos, comenzando por qué es realmente MCP y el problema que lo hizo necesario.

¿Qué es el Model Context Protocol?

El Model Context Protocol es un protocolo abierto basado en JSON-RPC que estandariza cómo los modelos de IA descubren e interactúan con herramientas y datos externos. Piénsalo como HTTP para integraciones de IA -- un lenguaje compartido que cualquier modelo y cualquier herramienta puede hablar.

Probablemente has escuchado la analogía USB-C, y es útil hasta cierto punto: antes de USB-C, cada dispositivo necesitaba su propio cable. MCP hace lo mismo para la IA, pero la analogía lo subestima. USB-C solo transporta datos y energía. MCP transporta definiciones de herramientas, patrones de acceso a datos, plantillas de prompts reutilizables e incluso permite que los servidores soliciten completaciones al modelo. Es un protocolo más rico de lo que sugiere una metáfora de cable.

El problema M x N que MCP resuelve

Sin MCP, conectar M modelos a N herramientas requiere M x N integraciones personalizadas. Supón que tienes 5 LLMs (Claude, GPT-4, Gemini, Llama, Mistral) y necesitas que accedan a 10 herramientas (GitHub, Postgres, Slack, Jira, etc.). Eso son 50 capas de integración a medida, cada una con su propia autenticación, manejo de errores y formato de datos.

Con MCP, cada modelo implementa el protocolo cliente MCP una vez, y cada herramienta implementa un servidor MCP una vez. Ahora son 5 + 10 = 15 implementaciones en lugar de 50. ¿Añadir un nuevo modelo? Funciona inmediatamente con las 10 herramientas. ¿Añadir una nueva herramienta? Los 5 modelos pueden usarla.

Una breve historia de MCP

Anthropic publicó MCP como código abierto en noviembre de 2024 junto con SDKs para Python y TypeScript más conectores para Claude Desktop. La adopción fue rápida. OpenAI añadió soporte MCP a ChatGPT en marzo de 2025. Google siguió para Gemini en abril de 2025. En diciembre de 2025, Anthropic donó MCP a la nueva Agentic AI Foundation (AAIF) de la Linux Foundation, co-fundada con Block y OpenAI, convirtiendo MCP en un estándar neutral para proveedores con gobernanza entre industrias.

Lo que MCP NO ES:

• No es un modelo ni un framework de IA (es un protocolo, como HTTP)
• No reemplaza a LangChain o LlamaIndex (esas son capas de orquestación; MCP está debajo de ellas)
• No está limitado a Anthropic o Claude (es agnóstico al modelo por diseño)
• No es lo mismo que el function calling (más sobre eso en la sección de comparación)

¿Cómo funciona MCP? Profundización en la arquitectura

MCP tiene tres roles, y confundirlos es el error de principiante más común. Aclaremos la distinción.

Host, Cliente y Servidor -- ¿Cuál es la diferencia?

Aquí hay un ejemplo concreto: le pides a Claude Desktop que revise tus pull requests abiertos de GitHub. Claude Desktop es el host. Su cliente MCP integrado abre una conexión al servidor MCP de GitHub. El servidor llama a la API de GitHub, obtiene tus PRs y devuelve los resultados al cliente, que los pasa al modelo.

Un único host puede ejecutar múltiples clientes, cada uno conectado a un servidor diferente. Así es como Claude Desktop puede acceder simultáneamente a GitHub, tu base de datos Postgres y Slack -- tres servidores MCP separados, tres conexiones de cliente separadas, un host.

Cómo fluyen los mensajes (JSON-RPC 2.0)

Toda la comunicación MCP usa JSON-RPC 2.0 -- un protocolo ligero de solicitud/respuesta. Así es como se ve un intercambio tools/list en la red:

// Solicitud del cliente: "¿Qué herramientas tienes?"
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list"
}

// Respuesta del servidor: una herramienta disponible
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": [
      {
        "name": "get_weather",
        "description": "Obtener el clima actual para una ciudad",
        "inputSchema": {
          "type": "object",
          "properties": {
            "city": { "type": "string" }
          },
          "required": ["city"]
        }
      }
    ]
  }
}

El modelo lee estas definiciones de herramientas, decide cuándo llamarlas según la solicitud del usuario, y el cliente envía una solicitud tools/call de vuelta al servidor con los argumentos apropiados.

Ciclo de vida de la conexión

Cada sesión MCP sigue el mismo ciclo de vida:

1. Inicializar -- el cliente envía capacidades, el servidor responde con las suyas
2. Negociación de capacidades -- ambas partes acuerdan las características compatibles (herramientas, recursos, prompts, muestreo)
3. Listo -- la conexión está activa; las solicitudes fluyen en ambas direcciones
4. Solicitudes/respuestas -- tools/call, resources/read, etc.
5. Apagado -- desconexión limpia

Este handshake asegura la compatibilidad hacia adelante. Si un servidor añade una nueva primitiva, los clientes más antiguos la ignoran elegantemente en lugar de colapsar.

Primitivas MCP: Herramientas, Recursos, Prompts y Muestreo

MCP define cuatro primitivas, y entender quién controla cada una es la clave para diseñar buenos servidores MCP.

Herramientas (controladas por el modelo)

Las herramientas son funciones que el modelo puede llamar. El servidor las declara con un nombre, descripción y definición de esquema de entrada JSON. El modelo lee estas definiciones y, cuando la solicitud de un usuario lo requiere, decide invocar la herramienta.

// El cliente envía una solicitud tools/call
{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": { "city": "Madrid" }
  }
}

Si has usado el function calling de OpenAI, las herramientas te resultarán familiares -- pero están estandarizadas para cada modelo compatible con MCP.

Recursos (controlados por la aplicación)

Los recursos son endpoints de datos de solo lectura. A diferencia de las herramientas, el modelo no decide obtener un recurso por sí solo -- la aplicación host o el usuario adjunta explícitamente recursos al contexto de la conversación. Piénsalos como endpoints GET: postgres://mydb/users/schema, file://docs/api-reference.md.

Los recursos admiten suscripciones mediante resources/subscribe, para que el cliente pueda ser notificado cuando los datos cambien.

Prompts (controlados por el usuario)

Los prompts son plantillas reutilizables que expone un servidor MCP. Un prompt code_review podría aceptar una ruta de archivo y generar una solicitud de revisión estructurada. El usuario (o la UI del host) desencadena los prompts explícitamente -- no son invocados automáticamente por el modelo.

Muestreo (iniciado por el servidor) -- Avanzado

Aquí está la primitiva que la mayoría de las guías omiten. El Muestreo permite que el servidor le pida al cliente que genere una completación usando el LLM. Esto invierte el flujo habitual: en lugar de que el modelo llame a una herramienta, la herramienta llama al modelo.

¿Por qué? Bucles agénticos. Imagina un servidor MCP que procesa tickets de soporte. Lee el ticket (un recurso), usa sampling/createMessage para pedirle al modelo un resumen, y luego usa ese resumen para enrutar el ticket mediante una herramienta. El servidor orquesta un flujo de trabajo de múltiples pasos aprovechando la inteligencia del modelo.

El muestreo está controlado por la aplicación host -- el usuario debe aprobarlo, y el host controla qué puede solicitar el servidor. Esto previene bucles descontrolados y mantiene la supervisión humana.

Construye tu primer servidor MCP: Python y TypeScript lado a lado

Suficiente teoría. Construyamos un servidor MCP funcional que exponga una herramienta get_weather. Mostraré tanto Python como TypeScript para que puedas comparar la experiencia del desarrollador y elegir el stack que se adapte a tu proyecto.

Python con FastMCP

FastMCP es el SDK Python oficial de alto nivel. Maneja toda la infraestructura del protocolo para que puedas concentrarte en la lógica de tus herramientas.

# Instalar FastMCP
pip install fastmcp

# weather_server.py
from fastmcp import FastMCP

mcp = FastMCP("Weather Server")

@mcp.tool()
def get_weather(city: str) -> str:
    """Obtener el clima actual para una ciudad."""
    # En producción, llamar a una API de clima real aquí
    weather_data = {
        "Madrid": "Soleado, 18°C",
        "Tokyo": "Soleado, 22°C",
        "New York": "Lluvioso, 8°C",
    }
    return weather_data.get(city, f"Sin datos para {city}")

if __name__ == "__main__":
    mcp.run()

Eso es todo -- 15 líneas. FastMCP infiere el esquema de entrada de la herramienta a partir de las anotaciones de tipo de Python y la docstring. Sin boilerplate de JSON Schema.

TypeScript con el SDK oficial

El SDK de TypeScript (@modelcontextprotocol/sdk) es un poco más explícito pero te da control total sobre las definiciones de esquema.

# Instalar el SDK y Zod para la validación de esquema
npm install @modelcontextprotocol/sdk zod

// weather-server.ts
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const server = new McpServer({
  name: "Weather Server",
  version: "1.0.0",
});

server.tool(
  "get_weather",
  "Obtener el clima actual para una ciudad",
  { city: z.string() },
  async ({ city }) => {
    const weatherData: Record<string, string> = {
      Madrid: "Soleado, 18°C",
      Tokyo: "Soleado, 22°C",
      "New York": "Lluvioso, 8°C",
    };
    return {
      content: [
        { type: "text", text: weatherData[city] ?? `Sin datos para ${city}` },
      ],
    };
  }
);

const transport = new StdioServerTransport();
await server.connect(transport);

La versión TypeScript usa esquemas Zod en lugar de anotaciones de tipo, y devuelve bloques de contenido estructurado. Más detallado, pero la seguridad de tipos es excelente.

Conectar a Claude Desktop

Para conectar cualquiera de los servidores a Claude Desktop, agrégalo a tu claude_desktop_config.json:

{
  "mcpServers": {
    "weather-python": {
      "command": "python",
      "args": ["weather_server.py"],
      "cwd": "/ruta/a/tu/proyecto"
    },
    "weather-typescript": {
      "command": "npx",
      "args": ["tsx", "weather-server.ts"],
      "cwd": "/ruta/a/tu/proyecto"
    }
  }
}

Reinicia Claude Desktop y ambos servidores de clima aparecen en la lista de herramientas. Pregunta "¿Cuál es el clima en Madrid?" y el modelo llama a tu herramienta get_weather automáticamente.

Probar con MCP Inspector

Antes de conectar tu servidor a un host, pruébalo de forma aislada con el MCP Inspector:

npx @modelcontextprotocol/inspector python weather_server.py

El Inspector abre una UI en el navegador donde puedes ver las herramientas descubiertas, invocarlas manualmente e inspeccionar los mensajes JSON-RPC que van y vienen. Es la mejor herramienta de depuración en el ecosistema MCP -- úsala pronto y con frecuencia.

Transportes MCP: stdio para desarrollo, Streamable HTTP para producción

Los mensajes MCP necesitan una forma de viajar entre cliente y servidor. Esa es la capa de transporte, y elegir la correcta importa.

stdio funciona iniciando el servidor MCP como subproceso y comunicándose a través de stdin/stdout. Es lo que usaste en el tutorial anterior -- sin puertos, sin TLS, sin autenticación necesaria. Perfecto para desarrollo y herramientas locales de un solo usuario.

Streamable HTTP es el transporte de producción, añadido en la actualización de especificación de 2025. Los clientes envían solicitudes HTTP POST estándar al servidor. El servidor puede responder de forma sincrónica o abrir un stream SSE para operaciones más largas. Es compatible sin estado, funciona detrás de balanceadores de carga y admite autenticación HTTP estándar.

Si ves tutoriales más antiguos que mencionan "HTTP+SSE" como dos transportes separados (uno para enviar, uno para recibir), ese es el enfoque deprecado. Streamable HTTP consolida ambos en un único mecanismo más limpio.

La decisión es sencilla: usa stdio cuando desarrolles localmente, cambia a streamable-http cuando despliegues para otros.

// Cambiar de stdio a Streamable HTTP en TypeScript
import { StreamableHTTPServerTransport } from "@modelcontextprotocol/sdk/server/streamableHttp.js";

const transport = new StreamableHTTPServerTransport({ port: 3001 });
await server.connect(transport);

MCP vs Function Calling vs REST APIs -- Cuándo usar cada uno

Esta es la pregunta que surge en cada discusión sobre MCP, así que resolverla con una comparación directa.

Cuándo el function calling es suficiente

Si tienes menos de 5 herramientas y usas un modelo, el function calling es más simple. Defines los esquemas de tus herramientas en línea con cada llamada API, el modelo devuelve el nombre de la función y los argumentos, y los ejecutas en tu código de aplicación. Sin servidor que ejecutar, sin protocolo que aprender. Para un chatbot que verifica el estado de pedidos y consulta FAQs, el function calling está perfectamente bien.

Cuándo MCP vale el esfuerzo

MCP justifica su complejidad cuando:

• Admites múltiples LLMs y no quieres reescribir definiciones de herramientas para cada proveedor
• Necesitas descubrimiento de herramientas -- el modelo puede consultar qué está disponible en lugar de que tú codifiques los esquemas de forma rígida
• Quieres recursos y prompts, no solo llamadas a herramientas
• Estás construyendo agentes de IA que coordinan de forma autónoma y necesitas una capa de integración estandarizada
• Tu equipo crece y diferentes ingenieros construyen diferentes herramientas -- MCP les permite trabajar independientemente

Veredicto: MCP gana cuando necesitas acceso estandarizado a herramientas con múltiples modelos. El function calling gana para casos de uso simples de un solo modelo. Las REST APIs siguen siendo la elección correcta para la comunicación tradicional servicio a servicio que no involucra un LLM.

El ecosistema MCP en 2026: Quién lo admite y qué está disponible

MCP pasó de ser un proyecto secundario de Anthropic a un estándar de la industria en menos de 18 meses. Así están las cosas.

¿Qué LLMs admiten MCP?

Servidores MCP populares que vale la pena conocer

El anuncio de la AAIF de la Linux Foundation citó 10.000+ servidores activos y 97 millones de descargas mensuales del SDK en el momento de la donación de MCP en diciembre de 2025. El ecosistema ya no es experimental -- está listo para producción.

MCP Apps es una nueva primitiva introducida en enero de 2026. Permite que los servidores proporcionen componentes de UI interactivos que se renderizan dentro de la aplicación host. Aún temprano, pero señala la evolución de MCP de un protocolo de datos a un framework completo de aplicación agéntica. Vale la pena seguirlo.

Gobernanza: De Anthropic a la Linux Foundation

MCP está gobernado por la Agentic AI Foundation (AAIF) bajo la Linux Foundation, co-fundada por Anthropic, Block y OpenAI. Esto importa para la adopción empresarial: MCP no está vinculado a la hoja de ruta de un solo proveedor. La hoja de ruta 2026 se centra en la evolución del transporte, comunicación agente a agente (una nueva primitiva "Tareas"), maduración de la gobernanza y preparación empresarial.

Para equipos que construyen sistemas de IA en producción, frameworks como un framework de agentes IA autónomos como OpenClaw ya se integran con servidores MCP para dar a los agentes capacidades del mundo real.

Seguridad MCP: OAuth 2.1, amenazas y una lista de verificación práctica

La seguridad es donde el ecosistema MCP tiene más terreno que cubrir. Y los números pintan un cuadro claro.

El problema del 88%: Por qué la mayoría de los servidores MCP son inseguros

Astrix Security analizó más de 5.200 implementaciones de servidores MCP de código abierto y descubrió que el 88% requiere algún tipo de credenciales -- pero el 53% se basa en secretos estáticos de larga duración no seguros como claves API y tokens de acceso personal codificados de forma rígida en archivos de configuración. Solo el 8,5% implementa OAuth.

Eso significa que la gran mayoría de los servidores MCP en la naturaleza usa el equivalente de autenticación de pegar tu llave de casa en la puerta principal.

OAuth 2.1 para servidores MCP

La especificación MCP requiere OAuth 2.1 para todos los servidores basados en HTTP desde la actualización de junio de 2025. El flujo funciona así: el cliente MCP inicia un flujo de autorización OAuth 2.1 con el servidor, obtiene un token de acceso con alcance limitado y lo incluye en cada solicitud posterior. PKCE (Proof Key for Code Exchange) es requerido para todos los clientes -- sin excepciones.

Si estás construyendo un servidor MCP que funciona sobre Streamable HTTP, OAuth 2.1 no es opcional. Está mandatado por la especificación.

Modelo de amenazas: Qué puede salir mal

Cuatro amenazas merecen atención en cualquier despliegue MCP:

• Inyección de prompt a través de herramientas -- Una fuente de datos maliciosa o comprometida devuelve contenido diseñado para manipular el modelo. Si una herramienta obtiene una página web y esa página contiene instrucciones ocultas, el modelo podría ejecutarlas.
• Ataque de deputy confundido -- El modelo invoca una herramienta con permisos más amplios de los que el usuario pretendía. Si el servidor MCP tiene acceso de administrador a una base de datos, el modelo podría teóricamente eliminar una tabla.
• Riesgo de concentración de tokens -- Un servidor MCP que mantiene claves API para GitHub, Slack y tu base de datos de producción es un objetivo único de alto valor. Compromete un servidor, compromete todo a lo que se conecta.
• Transporte inseguro -- Ejecutar un servidor MCP HTTP sin TLS expone cada solicitud, incluidos los tokens OAuth y datos sensibles, en texto plano.

Lista de verificación de seguridad para MCP en producción

1. Implementar OAuth 2.1 para cualquier servidor expuesto a través de HTTP. Sin claves API estáticas en archivos de configuración.
2. Aplicar alcance de mínimo privilegio. Si tu herramienta solo lee datos, las credenciales del servidor deben ser de solo lectura. No des acceso de escritura a una herramienta de informes.
3. Aislar credenciales. Cada servidor MCP debe tener sus propios tokens con alcance limitado. No compartas un único "token dios" entre servidores.
4. Aplicar TLS en todas partes. Streamable HTTP sin HTTPS es automáticamente no apto para producción.
5. Validar y sanitizar las salidas de las herramientas. Trata los datos devueltos por las herramientas de la misma manera que tratas la entrada del usuario -- no confíes en ellos ciegamente.
6. Limitar la velocidad de invocaciones de herramientas. Un bucle de agente descontrolado que llama a una herramienta miles de veces puede agotar las cuotas de API o causar efectos secundarios no deseados.
7. Auditar y registrar cada llamada a herramienta. Incluye IDs de solicitud, marcas de tiempo, el modelo que llama y los argumentos de la herramienta. Lo necesitas para depuración y para respuesta a incidentes de seguridad.

Depuración de MCP: Inspector, registro y errores comunes

Encontrarás errores. Todo desarrollador los encuentra. Así es como los corriges rápidamente.

MCP Inspector es la herramienta oficial de depuración y tu primera línea de defensa. Se conecta a cualquier servidor MCP, descubre sus herramientas/recursos/prompts y te deja invocarlos manualmente mientras muestra el tráfico JSON-RPC en bruto.

# Lanzar Inspector contra tu servidor Python
npx @modelcontextprotocol/inspector python weather_server.py

# O contra un servidor TypeScript
npx @modelcontextprotocol/inspector npx tsx weather-server.ts

El Inspector abre una UI basada en navegador con pestañas para Herramientas, Recursos, Prompts y un panel de notificaciones. Puedes llamar a cualquier herramienta con argumentos personalizados y ver exactamente qué JSON viaja por la red. Úsalo antes de conectarte a una aplicación host -- es mucho más fácil depurar el servidor de forma aislada.

Errores comunes y correcciones

• "Servidor no encontrado" en Claude Desktop -- Casi siempre un problema de ruta en claude_desktop_config.json. Verifica que command se resuelva en un binario real y que cwd apunte al directorio correcto. En macOS, usa rutas absolutas.
• Fallos de validación de esquema de herramienta -- Si el modelo envía argumentos que no coinciden con el inputSchema de la herramienta, el servidor rechaza la llamada. Verifica que tus tipos de esquema coincidan con lo que el modelo espera. Zod (TypeScript) y las anotaciones de tipo (Python) capturan la mayoría de estos en el momento de la definición.
• Caídas de conexión de transporte -- Para stdio, esto generalmente significa que el proceso del servidor colapsó. Verifica la salida de stderr. Para Streamable HTTP, verifica la configuración de tiempo de espera -- las herramientas de larga duración pueden superar los tiempos de espera HTTP predeterminados.
• Errores "Permission denied" o 401 -- Alcance OAuth demasiado estrecho. El servidor rechaza el token porque no tiene los permisos requeridos. Amplía el alcance, pero solo tanto como la herramienta realmente necesite.

Mejores prácticas de registro

Estructura tus registros con IDs de solicitud para poder rastrear una única solicitud de usuario a través del cliente MCP, el servidor y cualquier API downstream. Registra cada invocación tools/call con el nombre de la herramienta, los argumentos, el tiempo de respuesta y el estado del resultado. En producción, envía estos registros a una plataforma de observabilidad -- cuando algo salga mal a las 3 de la mañana, estarás contento de haberlo hecho.

Cómo Techsy construye con MCP

Hemos estado integrando MCP en proyectos de clientes desde principios de 2025, y el patrón que vemos con más frecuencia es este: un equipo tiene una función de IA que funciona con un modelo y un puñado de herramientas, pero planean escalar -- más modelos, más fuentes de datos, más capacidades agénticas. Ese es el punto de inflexión donde MCP comienza a dar sus frutos.

Nuestro enfoque sigue tres pasos:

1. Evaluar la idoneidad. No todo proyecto necesita MCP. Si estás llamando a dos herramientas desde un único modelo, el function calling es más simple y te lo diremos. MCP tiene sentido cuando conectas 3 o más fuentes de datos, admites múltiples modelos o construyes flujos de trabajo de agentes donde las herramientas necesitan ser descubribles.
2. Construir y probar servidores de forma aislada. Desarrollamos servidores MCP personalizados para cada fuente de datos -- bases de datos internas, APIs SaaS, servicios propietarios -- y los validamos con MCP Inspector antes de conectarlos a cualquier host.
3. Desplegar con Streamable HTTP y OAuth 2.1. Para producción, ejecutamos servidores MCP como servicios contenerizados detrás de TLS, con tokens OAuth con alcance limitado y registro estructurado desde el primer día. Sin secretos estáticos.

Las integraciones más comunes que construimos: conectar asistentes de IA a bases de datos Postgres internas, construir servidores MCP personalizados para plataformas SaaS de clientes, y migrar equipos de configuraciones de function calling dispersas a una arquitectura MCP estandarizada.

¿Construyes herramientas impulsadas por IA que necesitan conectarse a tu infraestructura? Ayudamos a los equipos a diseñar e implementar integraciones MCP. Obtener una consulta gratuita

Preguntas frecuentes sobre MCP

¿Qué es el Model Context Protocol (MCP)?

MCP es un estándar abierto, creado originalmente por Anthropic y ahora gobernado por la Linux Foundation, que define cómo los modelos de IA se conectan a herramientas externas, fuentes de datos y servicios. Estandariza la capa de integración para que un servidor MCP funcione con cualquier modelo compatible -- como un enchufe universal para IA.

¿Cómo funciona MCP?

MCP utiliza una arquitectura de tres partes: una aplicación host (como Claude Desktop o Cursor), un cliente MCP dentro del host que gestiona las conexiones, y servidores MCP que exponen herramientas y datos. Toda la comunicación usa mensajes JSON-RPC 2.0 sobre stdio (local) o Streamable HTTP (remoto).

¿Para qué se usa MCP?

Los casos de uso comunes incluyen conectar asistentes de IA a bases de datos (Postgres, MySQL), integrar con plataformas de código (GitHub, GitLab), acceder a herramientas SaaS (Slack, Notion, Google Drive) y construir agentes de IA autónomos que necesitan interactuar con servicios reales.

¿MCP es lo mismo que el function calling?

No. El function calling es específico del modelo (el formato de OpenAI difiere del de Anthropic) y por solicitud -- envías esquemas de herramientas con cada llamada API. MCP es un protocolo estandarizado que funciona entre modelos, admite el descubrimiento de herramientas e incluye recursos y prompts más allá de la simple ejecución de funciones.

¿Qué son los servidores MCP?

Los servidores MCP son programas que exponen herramientas, recursos y prompts a los modelos de IA a través del protocolo MCP. Envuelven APIs externas y fuentes de datos en una interfaz estandarizada. Los ejemplos incluyen el servidor MCP de GitHub (para gestión de PRs e issues) y el servidor MCP de Postgres (para consultas de bases de datos).

¿Cómo construyo un servidor MCP?

Usa Python con FastMCP (pip install fastmcp) o TypeScript con el SDK oficial (npm install @modelcontextprotocol/sdk). Define tus herramientas como funciones decoradas (Python) o manejadores registrados (TypeScript), luego ejecuta el servidor. Consulta la sección de tutorial anterior para ver el código funcional completo.

¿Es seguro MCP?

El propio protocolo admite OAuth 2.1 para autenticación y permisos con alcance limitado. Sin embargo, la investigación de Astrix Security encontró que el 88% de las implementaciones existentes de servidores MCP se basan en secretos estáticos en lugar de OAuth. El protocolo es seguro por diseño, pero la mayoría de los despliegues del mundo real aún no se han puesto al día.

¿Qué LLMs admiten MCP?

Claude tiene soporte MCP nativo desde su creación en noviembre de 2024. ChatGPT añadió soporte en marzo de 2025, y Gemini siguió en abril de 2025. Los modelos de código abierto pueden usar MCP a través de adaptadores en LangChain y LlamaIndex.

¿Cuál es la diferencia entre MCP y una REST API?

Las REST APIs están diseñadas para la comunicación general servicio a servicio. MCP está diseñado específicamente para la interacción con modelos de IA -- incluye descubrimiento de herramientas, negociación de esquemas, acceso a recursos y plantillas de prompts que REST no tiene. No reemplazarías tus REST APIs con MCP; sirven capas diferentes.

¿Quién mantiene MCP ahora?

La Agentic AI Foundation (AAIF) de la Linux Foundation, formada en diciembre de 2025, gobierna MCP. Fue co-fundada por Anthropic, Block y OpenAI. Esta gobernanza neutral para proveedores es una razón clave por la que las empresas están adoptando MCP.

¿Qué es Streamable HTTP en MCP?

Streamable HTTP es el mecanismo de transporte de producción añadido en la actualización de especificación MCP de 2025. Reemplaza el transporte HTTP+SSE más antiguo con un diseño más limpio: los clientes envían solicitudes HTTP POST y los servidores pueden responder de forma sincrónica o mediante streaming SSE. Funciona detrás de balanceadores de carga y admite autenticación HTTP estándar.

¿Cuántos servidores MCP existen?

La Linux Foundation citó 10.000+ servidores activos y 97 millones de descargas mensuales del SDK cuando MCP fue donado a la AAIF en diciembre de 2025. El ecosistema abarca bases de datos, herramientas de código, integraciones SaaS, motores de búsqueda y proveedores de infraestructura en la nube.

Conclusión

MCP ha pasado del experimento de código abierto de Anthropic al protocolo estándar de la industria para conectar modelos de IA con herramientas en poco más de un año. Esto es lo que importa:

• MCP resuelve el problema M x N -- un servidor funciona con cada modelo compatible, un cliente funciona con cada servidor
• Puedes construir un servidor MCP funcional en menos de 50 líneas de Python (FastMCP) o TypeScript
• Usa stdio para desarrollo, Streamable HTTP para producción -- la elección del transporte es sencilla
• Asegura tus servidores con OAuth 2.1 -- el 88% de las implementaciones actuales no lo hace, y eso es un riesgo real
• El ecosistema está listo para producción -- 10.000+ servidores, todos los grandes LLMs, gobernanza neutral bajo la Linux Foundation

Mirando hacia adelante, la hoja de ruta 2026 se centra en la comunicación agente a agente a través de una nueva primitiva Tareas, seguridad empresarial mejorada y MCP Apps para UI interactiva dirigida por el servidor. MCP ya no es solo un protocolo para acceso a herramientas -- se está convirtiendo en la capa de infraestructura para IA agéntica.

Comienza con el código del tutorial anterior, pruébalo en MCP Inspector y conéctalo a Claude Desktop. Tendrás una integración MCP funcionando en menos de una hora.

Fuentes

• Especificación MCP (2025-11-25)
• Especificación de autorización MCP
• Especificación de transportes MCP
• Documentación de MCP Inspector
• Presentación del Model Context Protocol -- Anthropic
• Donación de MCP a la Linux Foundation -- Anthropic
• Anuncio AAIF de la Linux Foundation
• Soporte MCP de Google Cloud
• FastMCP Python SDK
• MCP TypeScript SDK
• Astrix Security: Estado de la seguridad de servidores MCP 2025
• Hoja de ruta MCP 2026