Puntos clave
- Un servidor MCP expone tus sistemas internos (CRM, ERP, base documental) a cualquier agente de IA compatible mediante un contrato estándar de herramientas, recursos y prompts. Se escribe una vez y sirve para Claude, GPT, Gemini o tu orquestador.
- El ecosistema ya no es experimental: el registro público supera los 10.000 servidores activos y los SDK oficiales rondan los 97 millones de descargas mensuales, según MCP Manager (2026).
- La decisión de diseño más importante no es el lenguaje: es qué herramientas expones y con qué permisos. Un servidor MCP mal acotado es una puerta trasera a tus datos.
- Con los SDK de Python o TypeScript, un primer servidor útil (3 o 4 herramientas sobre un sistema) se construye en días; llevarlo a producción con autenticación y auditoría es lo que ocupa las semanas.
Un servidor MCP es el componente del Model Context Protocol que publica capacidades de un sistema real (consultar un pedido en el ERP, crear un contacto en el CRM, buscar en la base documental) para que cualquier agente de IA las use de forma segura y uniforme. Si el protocolo MCP es el USB-C de la IA, el servidor es el adaptador que enchufa tu sistema concreto a ese estándar. En esta guía explicamos cómo construir uno para tu empresa, con foco en permisos y despliegue; si aún no tienes claro qué es el protocolo, empieza por nuestra guía ¿Qué es MCP y por qué importa en tu empresa?.
Qué es (exactamente) un servidor MCP y qué no es
En MCP hay tres piezas: el host (la aplicación con el modelo: Claude, un IDE, tu orquestador), el cliente (el conector que vive dentro del host) y el servidor (tu código, pegado a tus sistemas). El servidor declara tres tipos de capacidades:
- Tools: acciones que el modelo puede invocar ("crear_presupuesto", "buscar_cliente"). Son el 90% del valor en empresa.
- Resources: datos de solo lectura que el host puede cargar como contexto (un documento, una tabla).
- Prompts: plantillas reutilizables que el servidor ofrece al usuario.
Qué no es un servidor MCP: no es un agente (no decide nada), no es un RAG (aunque puede exponer tu RAG como herramienta) y no es una API pública. Es una capa de adaptación con contrato estándar entre tus sistemas y los modelos.
Local o remoto: la primera decisión de arquitectura
| Criterio | Servidor local (stdio) | Servidor remoto (HTTP) |
|---|---|---|
| Dónde corre | En la máquina del usuario | En tu infraestructura |
| Autenticación | Hereda la sesión local | OAuth 2.1 / tokens propios |
| Usuarios | Uno (el de la máquina) | Todo el equipo |
| Casos típicos | Herramientas de desarrollador | CRM, ERP, datos corporativos |
| Auditoría centralizada | No | Sí |
Para uso empresarial serio la respuesta es casi siempre remoto: un único servidor desplegado en tu nube, con autenticación por usuario y registro central de cada invocación. Los servidores locales quedan para herramientas personales de desarrollo.
Datos del mercado
- El registro oficial de MCP superaba los 9.600 servidores publicados a mediados de 2026, y los censos independientes cuentan más de 17.000 en total (MCP Manager, 2026).
- Las descargas mensuales de los SDK se multiplicaron por 970 en 18 meses hasta rondar los 97 millones (Digital Applied, 2026).
- El 41% de las organizaciones de software encuestadas ya tiene servidores MCP en producción limitada o amplia (informe Stacklok 2026, vía MCP Manager).
La lectura práctica: quien construye ahora su capa MCP no está apostando por un experimento, está adoptando el estándar que OpenAI, Google, Microsoft y Anthropic ya soportan.
Cómo crear tu servidor MCP: paso a paso
- Elige un sistema y un caso de uso, no "la empresa entera". El mejor primer servidor expone un sistema con API clara y dolor real: el CRM para el equipo comercial, o la base documental para soporte. Entregable: lista de 3 a 5 operaciones concretas.
- Define las tools como contratos estrechos. Cada herramienta con nombre explícito, parámetros tipados y descripción que un modelo entienda sin ambigüedad. Regla nuestra: si una tool necesita más de 5 parámetros, son dos tools.
- Escribe el servidor con el SDK oficial. Python o TypeScript según tu stack. El esqueleto (declarar tools y manejar llamadas) son decenas de líneas, no miles; la lógica de negocio ya existe en tus APIs internas.
- Pon la autenticación antes que la funcionalidad. Para servidores remotos: OAuth 2.1 o tokens por usuario, nunca una credencial compartida del sistema de fondo. El agente debe actuar con los permisos del usuario que lo usa, no con los de un superusuario.
- Aplica mínimo privilegio por herramienta. Lectura y escritura separadas, y las operaciones destructivas (borrar, enviar, pagar) o no se exponen o exigen confirmación humana en el host.
- Registra todo. Cada invocación con usuario, herramienta, parámetros y resultado. Sin este log no hay auditoría posible cuando alguien pregunte "¿por qué el agente hizo esto?".
- Prueba con el MCP Inspector y con un modelo de verdad. El Inspector valida el contrato; el modelo revela descripciones ambiguas (si el agente elige mal la herramienta, el problema suele ser tu descripción, no el modelo).
- Despliega detrás de tu perímetro. Contenedor en tu nube, TLS, y acceso restringido a los hosts autorizados. Publicarlo abierto a internet sin más es el error de seguridad más repetido del ecosistema.
Errores comunes (y cómo evitarlos)
- Error: exponer la API entera como herramientas. La realidad: 40 tools confunden al modelo y multiplican la superficie de ataque. Menos herramientas, mejor descritas, rinden más.
- Error: credencial compartida contra el sistema de fondo. La realidad: es el clásico "confused deputy". Sin identidad por usuario, cualquier prompt injection hereda permisos de administrador.
- Error: confiar en el contenido que devuelven las tools. La realidad: un documento o un correo devuelto por tu servidor puede contener instrucciones maliciosas para el modelo. Trata las salidas como datos no confiables y limita lo que el agente puede hacer después.
- Error: no versionar el contrato. La realidad: cambiar el nombre o los parámetros de una tool rompe silenciosamente a todos los agentes que la usan. Versiona como versionarías una API pública.
- Error: montar el servidor antes de arreglar la API interna. La realidad: MCP no arregla un ERP sin API ni datos sucios; los expone. A veces el proyecto real es la integración previa, como contamos en integrar LLMs con CRM, ERP y sistemas legacy.
Tiempos y esfuerzo realistas
- Prototipo funcional (3 o 4 tools, un sistema, sin auth): de 2 a 5 días con el SDK.
- Producción interna (remoto, OAuth, logging, mínimo privilegio): de 3 a 6 semanas según la madurez de tus APIs internas.
- Dónde el retorno llega antes: soporte y comercial, porque un mismo servidor sirve a la vez al agente de atención al cliente, al asistente interno del equipo y a cualquier automatización futura. Se paga una vez y lo usan todos los agentes.
- Qué medir desde el día 1: invocaciones por herramienta, tasa de error, tiempo ahorrado en los flujos que las usan y accesos denegados (señal de permisos bien puestos).
Preguntas frecuentes
¿Necesito un servidor MCP si ya uso function calling?
Si solo tienes un modelo y dos herramientas, no. El servidor MCP compensa cuando quieres que varias aplicaciones o modelos usen las mismas integraciones sin reescribirlas: es la diferencia entre un cargador por dispositivo y un estándar único.
¿En qué lenguaje se escribe un servidor MCP?
En el que quieras con SDK oficial: Python y TypeScript son los más maduros, y existen SDK para otros lenguajes. La elección correcta es el lenguaje de tu equipo, porque el mantenimiento pesa más que la escritura inicial.
¿Puedo usar servidores MCP públicos en lugar de crear el mío?
Para sistemas estándar (GitHub, Slack, bases de datos) sí, revisando quién los mantiene y qué permisos piden. Para tus sistemas propios (ERP, CRM configurado a medida, RAG interno) necesitas el tuyo: nadie ha publicado un servidor para tu negocio.
¿Un servidor MCP es seguro para datos sensibles?
Lo es si se diseña así: identidad por usuario, mínimo privilegio por herramienta, registro de invocaciones y despliegue dentro de tu perímetro. El protocolo no impone estas prácticas; el equipo que lo implanta, sí.
¿Qué modelos pueden usar mi servidor una vez creado?
Cualquiera cuyo host soporte MCP: Claude, los modelos de OpenAI y Google a través de sus integraciones compatibles, y los frameworks de agentes habituales (LangGraph, n8n y similares). Esa portabilidad es el motivo del estándar.
¿Cuánto se tarda en tener algo útil?
Un prototipo interno en menos de una semana; un despliegue en producción con seguridad y auditoría, entre 3 y 6 semanas. El plazo depende sobre todo de la calidad de las APIs internas que el servidor va a envolver.
¿Listo para conectar tus sistemas a la capa de agentes?
En Naxia diseñamos e implantamos servidores MCP con seguridad de mínimo privilegio para conectar CRM, ERP y bases de conocimiento a agentes de IA. Si quieres saber qué sistema de tu empresa debería ser el primero, habla con nosotros, sin compromiso.
O revisa primero nuestro proceso de implementación.