Un servidor MCP es un pequeño programa que expone tus herramientas, datos y prompts a un modelo de IA a través del Model Context Protocol, el estándar abierto que Anthropic presentó en noviembre de 2024 y que hoy es compatible con Claude, ChatGPT, Cursor y la mayoría de los frameworks de agentes. Si sabes cómo crear un servidor MCP, puedes conectar cualquier API, base de datos o script interno a un agente de IA en bastante menos de una hora. Esta guía recorre todo el camino: elegir un SDK, definir una tool, escoger un transport, probar en local y conectarlo a un cliente real, además de los errores de seguridad que hacen que se comprometan los servidores.
Construimos TechRiseUps con Claude Code, y esta misma investigación llega a DataForSEO a través de un servidor MCP, así que el flujo de trabajo que sigue es el que realmente ejecutamos, no un esquema de pizarra.
¿Qué es un servidor MCP y necesitas crear uno?
Un servidor MCP es un proceso que habla un único protocolo JSON-RPC con cualquier cliente compatible con MCP (el «host», como Claude Code o Claude Desktop). Anuncia tres tipos de capacidad: tools (funciones que el modelo puede invocar, con aprobación del usuario), resources (datos de solo lectura que el modelo puede incorporar como contexto) y prompts (plantillas reutilizables). El cliente los descubre a través de la conexión, de modo que un mismo servidor funciona en todos los hosts sin código de pegamento a medida.
Antes de escribir una sola línea de código, comprueba si realmente necesitas un servidor propio. Existen miles de servidores publicados para GitHub, Postgres, Slack, sistemas de archivos y mucho más; si ya hay uno para tu sistema, instálalo en lugar de reinventarlo. Crea el tuyo cuando estés envolviendo una API privada, una herramienta interna o lógica de negocio específica que ningún servidor público cubra. Ese es el caso honesto del 80 %, y es el que aborda esta guía.
Qué necesitas antes de empezar
Los requisitos son mínimos, y por eso MCP se extendió tan rápido. Necesitas un runtime para el SDK que elijas, un cliente compatible con MCP para hacer pruebas y el paquete oficial del SDK. Nada tiene que ser público ni estar alojado para el desarrollo local.
- Un runtime: Python 3.10+ (se recomienda
uv) o Node.js 18+ para TypeScript. - Un cliente: Claude Desktop, Claude Code, Cursor o el MCP Inspector independiente sirven perfectamente.
- El SDK:
mcp[cli]para Python o@modelcontextprotocol/sdkpara TypeScript, ambos mantenidos por el equipo del protocolo. - Una API o fuente de datos que exponer. Un servidor stdio local no necesita dominio, ni TLS, ni un puerto abierto; el alojamiento solo importa cuando pasas a remoto (se trata más abajo).
Elige tu SDK: Python (FastMCP) frente a TypeScript
Ambos SDK oficiales alcanzan paridad de funciones, así que decide según dónde vive ya tu integración. La capa FastMCP de Python es el camino más rápido de la idea al servidor en marcha; TypeScript es la elección natural si tu herramienta ya está en Node.
| Python | TypeScript | |
|---|---|---|
| Paquete | mcp[cli] (python-sdk) | @modelcontextprotocol/sdk (typescript-sdk) |
| Clase del servidor | FastMCP | McpServer |
| Definir una tool | decorador @mcp.tool | server.registerTool() / server.tool() |
| Validación | anotaciones de tipos | esquema Zod |
| Ideal para | stacks de datos/ML, arranque más rápido | bases de código JS/TS, aplicaciones web |
Si no tienes un stack existente con el que encajar, empieza con Python y FastMCP. Una tool no es más que una función decorada, así que si sabes escribir una función de Python, sabes publicar un servidor.
Crea un servidor mínimo: define una tool
El trabajo central consiste en registrar una tool: un nombre, un esquema de entrada y una función asíncrona que haga algo y devuelva texto. Aquí tienes un servidor completo en Python que expone una única tool get_weather.
from mcp.server.fastmcp import FastMCP
mcp = FastMCP("weather")
@mcp.tool()
async def get_weather(city: str) -> str:
"""Return the current weather for a city."""
# call your real API here
return f"It's 21C and clear in {city}."
if __name__ == "__main__":
mcp.run(transport="stdio")
La forma en TypeScript es la misma idea, con un esquema Zod para la entrada, una instancia de McpServer y server.registerTool() devolviendo un array content de { type: "text", text }. En ambos SDK, el docstring o descripción es lo que lee el modelo para decidir cuándo invocar la tool, así que escríbelo como un prompt, no como un comentario de código. Las descripciones vagas son la razón número uno por la que una tool que funciona nunca llega a invocarse.
Elige un transport: stdio frente a Streamable HTTP
MCP define dos transports, y la elección determina dónde puede ejecutarse tu servidor. Acierta pronto, porque condiciona el despliegue.
- stdio lanza el servidor como un subproceso local y se comunica por stdin/stdout. Es el valor por defecto, no necesita red y es lo adecuado para cualquier cosa que toque archivos locales, bases de datos locales o la propia máquina del desarrollador. Todas las guías rápidas lo usan.
- Streamable HTTP (que reemplazó al antiguo transport HTTP+SSE en la revisión de la especificación de 2025) ejecuta el servidor como un servicio web accesible desde otras máquinas. Úsalo para un servidor de equipo compartido o una integración alojada. Este es el único caso en el que se aplican los «requisitos de alojamiento»: una URL pública, TLS y autenticación.
Regla general: construye y prueba sobre stdio, y pasa a Streamable HTTP solo cuando más de una persona o máquina necesite el servidor.
Prueba con MCP Inspector antes de conectar un cliente
No depures un servidor nuevo a través de una ventana de chat. El MCP Inspector es una herramienta de navegador que se conecta directamente a tu servidor, lista sus tools y resources, y te permite invocar cada uno con entradas arbitrarias, de modo que ves la respuesta en bruto en lugar de la paráfrasis de un modelo.
npx @modelcontextprotocol/inspector
# opens a local UI (default http://localhost:6274)
Apúntalo a tu comando (para un servidor stdio, eso es el intérprete más tu script), confirma que cada tool aparece con el esquema que esperas e invócala. Si una tool da error aquí, también dará error dentro de Claude, solo que con menos claridad. Este único hábito elimina la mayor parte de la frustración del «mi servidor no funciona».
Conéctalo a Claude Code, Claude Desktop o Cursor
Una vez que el Inspector está contento, registra el servidor en un cliente mediante una pequeña configuración JSON. Cada host lee su propio archivo, pero la forma es idéntica: un comando, sus argumentos y cualquier secreto como variables de entorno.
{
"mcpServers": {
"weather": {
"command": "uv",
"args": ["run", "python", "/full/path/to/server.py"],
"env": { "WEATHER_API_KEY": "..." }
}
}
}
Claude Code lee .mcp.json en tu proyecto (o claude mcp add), Claude Desktop lee claude_desktop_config.json, y Cursor utiliza su panel Tools & Integrations. Reinicia el host y la tool aparece lista para invocarse. Si eres nuevo en todo este modelo, nuestra guía en lenguaje llano sobre los servidores MCP cubre los conceptos que este tutorial da por sabidos.
Despliega un servidor MCP remoto en un VPS
Para compartir un servidor con un equipo o conectarlo a un agente en la nube, ejecútalo como un servicio Streamable HTTP en un VPS pequeño. El código del servidor apenas cambia; sustituyes el transport stdio por HTTP y lo colocas detrás de un proxy inverso. Lo que cambia es la lista de comprobación operativa: un dominio, un certificado TLS, un gestor de procesos para que se reinicie al arrancar y, sobre todo, autenticación, ya que un endpoint MCP público es una puerta pública a todo lo que envuelve.
Una instancia de 4-5 €/mes es más que suficiente para la mayoría de los servidores internos; nosotros ejecutamos nuestra propia infraestructura en WaseerHost precisamente para este tipo de servicio secundario siempre activo. La mecánica de la máquina, el firewall y TLS es la misma que la de cualquier despliegue pequeño, y nuestra configuración de VPS con seguridad en la primera hora recorre esa parte de principio a fin. No expongas un servidor remoto sin una capa de autenticación delante.
Seguridad: los errores que hacen que se comprometan los servidores MCP
MCP le da a un modelo de lenguaje la capacidad de ejecutar tu código, así que trata cada tool como una superficie de ataque. Los fallos son aburridamente consistentes:
- Sin validación de entrada. Los esquemas Zod y las anotaciones de tipos de Python no son adorno. Una tool que pasa la salida del modelo directamente a un comando de shell o a una cadena SQL es una vía directa de inyección de prompts a RCE.
- Tools demasiado amplias. Una única tool
run_commandes cómoda y peligrosa. Expón capacidades concretas y acotadas, no una escotilla de escape general. - Secretos en la configuración. Guarda las claves de API en variables de entorno, nunca escritas a fuego en el código, y limítalas al mínimo que la tool necesite.
- Servidores remotos sin autenticar. Un endpoint Streamable HTTP público sin autenticación es una puerta abierta; exige un token y aplica límites de tasa.
La inyección de prompts agudiza esto más que en una API normal: el «usuario» que invoca tu tool puede ser un modelo manipulado por contenido no fiable. Tratamos esa amenaza en profundidad en Seguridad de agentes de IA y la crisis de la inyección de prompts. Asume que las entradas de las tools son hostiles y evitarás lo peor.
Preguntas frecuentes
¿Puedo crear mi propio servidor MCP?
Sí, y es deliberadamente fácil. Con el SDK oficial de Python o TypeScript, un servidor funcional que expone una tool son unas pocas decenas de líneas y se ejecuta en local sin alojamiento. Crea uno siempre que necesites exponer una API privada o una herramienta interna que ningún servidor público cubra ya.
¿Cuáles son los requisitos para alojar un servidor MCP?
Para uso local (transport stdio) no hay ninguno más allá del runtime; el servidor nunca sale de tu máquina. El alojamiento solo importa para un servidor Streamable HTTP remoto, que necesita una URL pública, un certificado TLS, un gestor de procesos y autenticación. Un VPS pequeño lo maneja con holgura.
¿Cuál es el tipo de servidor MCP más popular?
Los servidores stdio locales dominan el uso diario de los desarrolladores porque son el valor por defecto y no necesitan infraestructura. Las tools son con diferencia la capacidad más usada, por delante de los resources y los prompts, ya que permitir que el modelo actúe es el principal atractivo.
¿Cuánto tiempo lleva crear uno?
Un servidor mínimo de una sola tool es cuestión de 15-30 minutos con cualquiera de los dos SDK. La mayor parte del tiempo real se va en la integración subyacente (la API o la base de datos que estás envolviendo) y en escribir descripciones de tools claras, no en MCP en sí.
Sources
- Model Context Protocol — Build an MCP server (official tutorial): conceptos básicos, la guía rápida del servidor de meteorología y las opciones de transport.
- modelcontextprotocol/python-sdk (GitHub): el SDK oficial de Python y la API de FastMCP.
- modelcontextprotocol/typescript-sdk (GitHub): el SDK oficial de TypeScript,
McpServery el registro de tools. - freeCodeCamp — How to build a custom MCP server with TypeScript: un recorrido completo en TypeScript con validación Zod y configuración del cliente.
- The Pragmatic Engineer — Building MCP servers in the real world: lecciones prácticas y compromisos del trabajo con MCP en producción.
- MCP Inspector (GitHub): la herramienta de navegador para probar servidores antes de conectar un cliente.
Waqas Ahmed Waseer
Waqas Ahmed Waseer es desarrollador y creador de automatizaciones con más de 8 años construyendo sistemas en producción que usan más de 100.000 personas. Crea SaaS multiinquilino a medida, automatización con IA (n8n, flujos LLM, bots de WhatsApp) e infraestructura de hosting (WHM/cPanel, CloudLinux), y es el creador de WaSphere, FlowMaticX y la marca de hosting WaseerHost. Más de 100 proyectos entregados para pymes, agencias y startups financiadas.



