Cómo construir tu primer MCP server (guía 2026)

En qué es el Model Context Protocol y por qué se impuso explicamos el estándar que hoy conecta agentes de IA con el mundo. Este es el complemento práctico: cómo construir tu primer servidor MCP. Si aquel era el mapa, este es el terreno.

La buena noticia es que construir un servidor MCP básico es más accesible de lo que su reputación de “infraestructura crítica” sugiere. La estructura del protocolo hace la mayor parte del trabajo pesado; tu tarea es definir qué capacidades expones y qué hacen. Este artículo recorre los conceptos y la estructura de un servidor funcional, para que entiendas no solo cómo escribirlo sino por qué se estructura así.

Qué vamos a construir y qué necesitas#

Vamos a construir el servidor MCP más útil para empezar: uno que exponga un par de herramientas propias a cualquier agente compatible. El ejemplo conceptual será un servidor que da acceso a una fuente de datos sencilla, porque ilustra los tres conceptos centrales —herramientas, recursos y el ciclo de conexión— sin ahogarse en detalles de dominio.

Necesitas familiaridad con Python o TypeScript, los dos lenguajes con SDK oficiales más maduros y que suman el grueso de las descargas del ecosistema. Usaremos Python en las explicaciones por ser el más extendido para este tipo de tarea, pero los conceptos se trasladan directamente a TypeScript. Necesitas también un entorno donde ejecutar el servidor y un cliente MCP con el que probarlo; muchos asistentes de código modernos actúan como cliente y sirven perfectamente para desarrollo. Comparamos los principales en Claude Code, Cursor y Copilot.

Los tres bloques de un servidor MCP#

Antes de escribir nada, conviene tener claros los tres tipos de capacidad que un servidor MCP puede exponer, porque toda la estructura gira en torno a ellos.

Las herramientas son acciones que el agente puede solicitar ejecutar. Son el equivalente a funciones: reciben parámetros, hacen algo y devuelven un resultado. Consultar una base de datos, enviar un mensaje, calcular algo. Las herramientas son lo que da al agente capacidad de actuar.

Los recursos son datos que el agente puede leer. A diferencia de las herramientas, no ejecutan una acción con efectos; exponen información. Un archivo, el contenido de una tabla, el estado de un sistema. Los recursos son lo que da al agente contexto sobre el que razonar.

Los prompts son plantillas reutilizables que el servidor ofrece al host. Permiten empaquetar instrucciones bien diseñadas para tareas concretas, de modo que el agente pueda invocarlas de forma consistente. Son el componente menos usado de los tres al empezar, así que nos centraremos en herramientas y recursos.

Un servidor mínimo útil expone al menos una herramienta. Empezaremos por ahí.

La estructura básica#

Un servidor MCP en Python, usando el SDK oficial, parte de una estructura reconocible. Se instancia el servidor, se declaran las herramientas y recursos que expone, y se arranca escuchando en un transporte. En esbozo:

from mcp.server import Server
from mcp.server.stdio import stdio_server

app = Server("mi-primer-servidor")

@app.list_tools()
async def list_tools():
    return [
        {
            "name": "buscar_producto",
            "description": "Busca un producto por nombre y devuelve su precio y stock.",
            "inputSchema": {
                "type": "object",
                "properties": {
                    "nombre": {"type": "string"}
                },
                "required": ["nombre"]
            }
        }
    ]

@app.call_tool()
async def call_tool(name, arguments):
    if name == "buscar_producto":
        resultado = consultar_catalogo(arguments["nombre"])
        return [{"type": "text", "text": resultado}]
    raise ValueError(f"Herramienta desconocida: {name}")

async def main():
    async with stdio_server() as (read, write):
        await app.run(read, write, app.create_initialization_options())

Vale la pena leer esta estructura con atención, porque revela cómo funciona el protocolo. Hay dos piezas clave. La primera, list_tools, es cómo el servidor le dice al cliente qué herramientas ofrece y qué parámetros espera cada una. El inputSchema es fundamental: define el contrato de la herramienta con un esquema JSON. El agente usa esta descripción para saber qué puede pedir y cómo.

La segunda pieza, call_tool, es lo que se ejecuta cuando el agente solicita usar una herramienta. Recibe el nombre de la herramienta y los argumentos, hace el trabajo real —aquí, consultar un catálogo— y devuelve el resultado en un formato que el protocolo entiende.

El principio de seguridad que no debes olvidar#

Fíjate en algo importante en esa estructura: el agente no ejecuta consultar_catalogo directamente. Solicita la herramienta buscar_producto, y es tu código —el servidor— quien decide qué hacer con esa solicitud. Esta indirección no es casual. Es el principio de seguridad que atraviesa todo el ecosistema de agentes: el modelo propone, el harness dispone.

Esto significa que tu servidor MCP es un punto natural donde imponer validación y control. Antes de ejecutar la acción real, puedes validar los argumentos, comprobar permisos, aplicar límites de tasa, registrar la solicitud para auditoría. Un servidor MCP bien construido no es solo un conector; es una capa de gobernanza. Cuando expongas herramientas con efectos reales —escribir en una base de datos, gastar dinero, borrar algo—, este es el lugar donde pones las salvaguardas.

Los estándares del protocolo han ido incorporando primitivas para esto. Una de las más relevantes de 2026 es la posibilidad de que un servidor pause la ejecución y espere una confirmación humana antes de proceder con acciones de alto riesgo. Si tu herramienta hace algo irreversible o costoso, incorporar un punto de aprobación humana es una práctica que el protocolo facilita y que deberías considerar desde el principio. Esa pausa es, vista desde el otro lado, una de las condiciones de parada de el bucle Plan-Execute-Verify de un agente.

Exponer recursos#

Además de herramientas, tu servidor puede exponer recursos: datos que el agente lee. La estructura es análoga a la de las herramientas, pero en lugar de ejecutar una acción, se devuelve contenido:

@app.list_resources()
async def list_resources():
    return [
        {
            "uri": "catalogo://productos",
            "name": "Catálogo de productos",
            "description": "Lista completa de productos disponibles.",
            "mimeType": "application/json"
        }
    ]

@app.read_resource()
async def read_resource(uri):
    if uri == "catalogo://productos":
        return obtener_catalogo_completo()
    raise ValueError(f"Recurso desconocido: {uri}")

La diferencia conceptual con una herramienta importa. Un recurso es información que el agente puede consultar para construir su contexto; una herramienta es una acción que el agente ejecuta para cambiar algo o obtener un resultado calculado. Elegir bien entre exponer algo como recurso o como herramienta es parte del buen diseño de un servidor: los datos que el agente necesita leer para razonar van mejor como recursos; las acciones con parámetros van como herramientas.

Probarlo y conectarlo#

Una vez escrito el servidor, el ciclo de desarrollo consiste en conectarlo a un cliente y probar que las herramientas funcionan. Durante el desarrollo, el transporte por stdio es ideal: el cliente arranca tu servidor como un subproceso local y se comunica con él. Muchos asistentes de código permiten registrar un servidor MCP local apuntando al comando que lo arranca, y a partir de ahí el agente puede descubrir y usar tus herramientas.

La primera vez que veas a un agente descubrir tu herramienta, entender su esquema y usarla correctamente para resolver una petición, entenderás por qué MCP ha tenido el impacto que ha tenido. Escribiste una capacidad una vez, con una estructura estándar, y cualquier agente compatible puede usarla sin que tú sepas nada de ese agente. Esa es la promesa del protocolo hecha realidad en tu propia máquina.

De aquí en adelante#

Este servidor básico es el punto de partida. Desde aquí, los caminos de crecimiento son claros. Puedes desplegarlo en remoto sobre transporte HTTP para que sea accesible desde la nube. Puedes añadir autenticación y control de acceso para exponerlo de forma segura. Puedes empaquetarlo y publicarlo para que otros lo usen, contribuyendo al ecosistema de servidores públicos que ya supera los diez mil.

Pero la base es la que acabas de ver: un servidor declara herramientas y recursos con esquemas claros, media cada solicitud del agente, e impone las salvaguardas donde hacen falta. Todo lo demás son capas sobre este núcleo. Si entiendes esta estructura —y por qué está diseñada así— tienes lo que necesitas para construir piezas reutilizables dentro de la disciplina del harness engineering, que funcionan con cualquier agente del ecosistema. Que es, al final, una de las formas más apalancadas de crear valor con IA en 2026: no un agente que solo sirve para tu caso, sino una capacidad que cualquiera puede componer en el suyo.