Cómo crear un servidor MCP propio para tu empresa [2026]: tutorial paso a paso

TL;DR — Resumen ejecutivo

• Un servidor MCP propio convierte cualquier sistema interno de empresa (CRM, gestor documental, ERP a medida, base de proyectos) en una capa que cualquier modelo de IA compatible (Claude, ChatGPT, Gemini, Cursor) puede consultar y modificar de forma estándar. Si tu sistema vive en una herramienta con servidor oficial (Notion, Drive, GitHub, Linear, Slack), instala el oficial y no construyas nada.
• Tiempo de implementación: 2-4 semanas calendario para un primer servidor con 3-5 resources + 2-3 tools. Una persona con experiencia Python o TypeScript lo monta en 30-60 horas efectivas.
• Coste: 4.000-9.000 € si externalizas a freelance senior (4-6 semanas). 0 € si tienes el perfil técnico in-house.
• Stack: SDK oficial MCP en Python o TypeScript (feature parity entre ambas). Anthropic los mantiene con la misma prioridad. La decisión depende de qué conoce tu equipo.
• Cinco pasos del tutorial: (1) decidir qué exponer, (2) setup proyecto y SDK, (3) implementar resources, (4) implementar tools, (5) autenticación y deploy.
• Modo de despliegue: stdio (subproceso local) para uso individual, SSE/HTTP (servidor remoto) para producción empresarial con varios usuarios u hosts compartiendo el servidor.
• El riesgo más caro es exponer más datos de los previstos. Mitigación: alcance mínimo inicial, validación estricta de parámetros en cada tool, log auditable, ampliar despacio según uso real.
• Veredicto operativo: empieza con un servidor de 3 resources + 2 tools que cubra el caso de uso más doloroso, valida con 2-3 personas durante 2 semanas, y solo después amplía. El error típico es construir un servidor que expone “todo” antes de validar “algo”.

Qué vas a conseguir con este tutorial

Al final del tutorial vas a tener un servidor MCP propio funcionando en producción que conecta Claude (o cualquier host compatible) con un sistema interno de tu empresa, expone resources y tools concretos y registra cada acción de forma auditable. El servidor lo usan todos los modelos compatibles sin desarrollos adicionales, lo que elimina el coste de mantener integraciones a medida por modelo.

Para entender qué es MCP por debajo antes de empezar, aquí está la definición y la mecánica del protocolo.

Requisitos previos:

Tiempo total: 2-4 semanas calendario, 30-60 horas efectivas.

Paso 1 — Decidir qué exponer (1-2 días)

Antes de escribir una línea de código, decide exactamente qué resources, tools y prompts va a exponer tu servidor. Sin esta decisión, el servidor crece sin criterio y termina exponiendo todo, lo que es peligroso y poco útil.

Resources: datos legibles que el modelo puede consultar. Ejemplos:

• Lista de clientes activos del CRM (sin datos sensibles personales).
• Documentos del gestor documental por carpeta o tag.
• Proyectos cerrados del último año con sus métricas.

Tools: acciones que el modelo puede ejecutar. Ejemplos:

• Crear un nuevo lead en el CRM.
• Buscar documentos por palabra clave.
• Actualizar el estado de una factura.

Prompts: plantillas reutilizables que el modelo puede invocar. Ejemplos:

• “Reporte mensual del cliente X”.
• “Análisis competitivo del sector Y”.

Regla crítica: para cada elemento, escribe en una sola frase qué hace, qué argumentos recibe y qué devuelve. Si no puedes explicarlo en una frase, no está bien definido. Empieza por 3 resources + 2 tools máximo. Ampliar después es trivial; rediseñar es caro.

Paso 2 — Setup del proyecto y SDK (medio día)

El segundo paso es crear el repositorio con la estructura mínima y el SDK oficial instalado. Anthropic mantiene SDKs oficiales en Python y TypeScript con feature parity total. Elige el lenguaje que tu equipo conoce mejor.

Setup en Python (recomendado si tu equipo es backend o data):

mkdir mi-empresa-mcp && cd mi-empresa-mcp
python -m venv .venv && source .venv/bin/activate
pip install mcp anthropic

Estructura básica del proyecto:

mi-empresa-mcp/
├── server.py              # punto de entrada
├── resources/
│   ├── __init__.py
│   ├── clientes.py
│   └── proyectos.py
├── tools/
│   ├── __init__.py
│   └── crear_lead.py
├── config.py              # variables de entorno y config
├── auth.py                # autenticación con el sistema interno
└── requirements.txt

Setup en TypeScript (recomendado si tu equipo es full-stack moderno):

mkdir mi-empresa-mcp && cd mi-empresa-mcp
npm init -y
npm install @modelcontextprotocol/sdk typescript tsx
npx tsc --init

Estructura equivalente con archivos .ts y package.json.

Variables de entorno (en .env, nunca en código):

INTERNAL_API_URL=https://mi-crm-interno.empresa.com/api
INTERNAL_API_TOKEN=tu_token_de_servicio
LOG_LEVEL=info

Paso 3 — Implementar resources (3-5 días)

Los resources son la parte más fácil de empezar porque solo leen datos, no los modifican. Implementa los 3 resources definidos en el paso 1.

Ejemplo en Python — resource “clientes_activos”:

from mcp.server import Server
from mcp.types import Resource

server = Server("mi-empresa-mcp")

@server.list_resources()
async def list_resources() -> list[Resource]:
    return [
        Resource(
            uri="empresa://clientes/activos",
            name="Clientes activos",
            description="Lista de clientes activos del CRM con tag, sector y MRR",
            mimeType="application/json",
        ),
    ]

@server.read_resource()
async def read_resource(uri: str) -> str:
    if uri == "empresa://clientes/activos":
        clientes = await fetch_clientes_activos()
        return json.dumps(clientes, ensure_ascii=False)
    raise ValueError(f"Resource desconocido: {uri}")

Reglas operativas para resources:

• URI semánticas: empresa://clientes/activos, no resource_1. El modelo entiende mejor lo que significan.
• Descripciones precisas: el modelo decide cuándo usar el resource leyendo la descripción. Si dice “lista de clientes” sin más, no sabrá si incluye los inactivos.
• Filtrado en el servidor, no en el modelo: si solo quieres exponer clientes activos, filtra ahí. NO devuelvas la base entera para que el modelo elija.
• Tamaño razonable: si un resource devuelve 50.000 filas, el modelo se atasca. Paginar o resumir.

Paso 4 — Implementar tools (3-5 días)

Los tools son acciones que modifican estado — más delicados que los resources porque pueden romper cosas en producción. Validación estricta de parámetros, autenticación correcta y registro de cada llamada.

Ejemplo en Python — tool “crear_lead”:

from mcp.types import Tool, TextContent

@server.list_tools()
async def list_tools() -> list[Tool]:
    return [
        Tool(
            name="crear_lead",
            description="Crea un nuevo lead en el CRM. Devuelve el ID del lead creado.",
            inputSchema={
                "type": "object",
                "properties": {
                    "nombre": {"type": "string", "description": "Nombre completo"},
                    "email": {"type": "string", "format": "email"},
                    "empresa": {"type": "string"},
                    "origen": {
                        "type": "string",
                        "enum": ["web", "evento", "referido", "outbound"],
                    },
                },
                "required": ["nombre", "email", "empresa"],
            },
        ),
    ]

@server.call_tool()
async def call_tool(name: str, arguments: dict) -> list[TextContent]:
    if name == "crear_lead":
        # Validación adicional
        if not arguments["email"].count("@") == 1:
            raise ValueError("Email inválido")
        # Acción
        lead_id = await crear_lead_en_crm(arguments)
        # Log auditable
        log_action("crear_lead", arguments, lead_id)
        return [TextContent(type="text", text=f"Lead {lead_id} creado")]
    raise ValueError(f"Tool desconocido: {name}")

Reglas operativas para tools:

• JSON Schema estricto: cada parámetro tipado, con descripción, valores enum si aplican. El modelo respeta el schema.
• Validación adicional en el código: el schema cubre el formato, no la lógica de negocio. Email único, MRR positivo, fecha futura, etc.
• Confirmación humana en tools destructivos: tools que borran o modifican mucho deben requerir un segundo paso de confirmación explícito.
• Log de cada llamada: timestamp, usuario (vía host), tool, argumentos, resultado. Esto es lo que permite auditoría posterior.

Paso 5 — Autenticación y permisos (2-3 días)

Tres capas obligatorias de seguridad en un servidor MCP empresarial.

Para producción empresarial, añadir una cuarta capa: OAuth o SSO contra el sistema de autenticación corporativo (Okta, Microsoft Entra ID, Google Workspace). Esto permite que cuando una persona se va de la empresa, su acceso al servidor MCP se revoca automáticamente con su SSO.

A evitar como única estrategia: token hardcodeado en el código del servidor. Nunca. Las variables de entorno son el mínimo, OAuth o SSO el estándar empresarial.

Paso 6 — Conectar al host y testear (1-2 días)

Hay dos formas de testear el servidor: con MCP Inspector (más rápido, sin abrir un host) o con Claude Desktop directamente (más fiel a producción).

MCP Inspector (recomendado para el ciclo de desarrollo iterativo):

npx @modelcontextprotocol/inspector python server.py

Esto abre una interfaz web local donde puedes:

• Ver la lista de resources y tools que expone el servidor.
• Invocar un tool con argumentos arbitrarios y ver la respuesta cruda.
• Leer un resource y ver el JSON exacto que devuelve.
• Inspeccionar mensajes JSON-RPC entrantes y salientes.

Claude Desktop (validación de extremo a extremo):

Editar ~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "mi-empresa": {
      "command": "python",
      "args": ["/ruta/absoluta/a/server.py"],
      "env": {
        "INTERNAL_API_TOKEN": "tu_token"
      }
    }
  }
}

Reiniciar Claude Desktop. El servidor aparece en la lista de integraciones activas. Cualquier conversación puede ya invocar los resources y tools.

Ciclo de desarrollo recomendado: implementar → testear en MCP Inspector → cuando funciona, validar en Claude Desktop con un caso de uso real → repetir.

Despliegue: stdio vs SSE/HTTP

Para producción empresarial, la pregunta no es si desplegar — es cómo. Dos modos compatibles:

Para empresa de 10+ personas con varios hosts, SSE/HTTP es el modo correcto. El SDK oficial soporta ambos modos con muy poco código adicional.

Despliegue serverless (Vercel / Fly.io / AWS Lambda) es la opción más eficiente para servidores con poco tráfico: pagas por invocación, escala automáticamente y no mantienes infraestructura.

Errores comunes y cómo evitarlos

Métricas reales antes/después

Datos típicos en una empresa de servicios de 10-30 personas que construye su primer servidor MCP propio para conectar Claude con un CRM o gestor documental interno.

Si quieres entender el cluster completo donde encaja este tutorial, aquí está la guía completa de implementación de IA en empresa de servicios pequeña.

Preguntas frecuentes

¿Cuándo tiene sentido construir un servidor MCP propio en vez de usar uno oficial?

Cuando los servidores oficiales (Notion, Drive, GitHub, Linear, Slack, PostgreSQL) no cubren tu fuente de datos. Casos típicos: CRM propio, gestor documental interno, sistema legacy de facturación, ERP a medida, base de proyectos pasados que no vive en una herramienta estándar. Si lo tuyo está en una herramienta con servidor oficial, NO lo construyas — instálalo y termina.

¿Cuánto tarda un equipo técnico en montar el primer servidor MCP?

Entre 2 y 4 semanas calendario para un servidor con 3-5 resources y 2-3 tools básicos. Una persona con experiencia en Python o TypeScript lo monta en 30-60 horas de trabajo efectivo. Si no tenéis perfil técnico, contratar 4-6 semanas externas a un freelance senior cuesta entre 4.000 € y 9.000 €.

¿Qué lenguaje de programación uso, Python o TypeScript?

Python si tu equipo técnico es data o backend tradicional, TypeScript si es full-stack moderno. Las dos SDKs oficiales tienen feature parity, comunidad activa y la misma curva de adopción. La decisión real es “qué conoce mi equipo mejor”, no “cuál es técnicamente superior”. Anthropic mantiene ambas con la misma prioridad.

¿Cómo manejo la autenticación si el servidor accede a datos sensibles?

Tres capas obligatorias: variable de entorno con token de servicio (nunca hardcodear), validación del usuario que está usando el host MCP (Claude Desktop, Cursor), y registro auditable de cada acción que toca datos. Para producción empresarial, añadir OAuth o SSO contra el sistema de autenticación corporativo (Okta, Microsoft Entra ID, Google Workspace).

¿El servidor MCP corre en local o en un servidor remoto?

Las dos opciones son válidas. Stdio (subproceso local) es el modo más simple y rápido para uso individual o por equipos pequeños — el servidor arranca cuando lo necesita el host y muere al cerrar. SSE/HTTP (servidor remoto) es el modo correcto cuando varias personas o varios hosts (Claude Desktop, Cursor, ChatGPT) tienen que compartir el mismo servidor. Para empresa, casi siempre SSE/HTTP en producción.

¿Puedo testear el servidor sin abrir Claude Desktop cada vez?

Sí. La herramienta oficial MCP Inspector (mcp-inspector) levanta el servidor en local y te deja interactuar con él vía interfaz web, sin necesidad de un host real. Es el primer paso del ciclo de desarrollo: implementar resource o tool → testear en MCP Inspector → cuando funciona, conectar a Claude Desktop para validación de extremo a extremo. Ahorra horas vs probar todo en Claude directamente.

¿Hay riesgo de que el servidor exponga más datos de los que debería?

Sí, y es el riesgo más caro. El servidor MCP es un proxy con permisos elevados — si está mal hecho, el modelo de IA puede acceder a más de lo previsto. Mitigación: el servidor expone solo los resources y tools que tú declaras (no toda la base de datos), cada tool tiene validación de parámetros estricta, y el log de acciones permite auditoría posterior. Empezar con el menor alcance posible y ampliar despacio.

En resumen

• Un servidor MCP propio convierte cualquier sistema interno de empresa en una capa accesible para cualquier modelo de IA compatible (Claude, ChatGPT, Gemini, Cursor) sin necesidad de integraciones a medida por modelo.
• 2-4 semanas calendario, 30-60 horas efectivas para un primer servidor con 3-5 resources y 2-3 tools. 4.000-9.000 € externalizado si no tienes perfil técnico in-house.
• Cinco pasos: decidir qué exponer, setup proyecto y SDK, implementar resources, implementar tools con validación estricta, autenticación y despliegue.
• Stdio para uso individual, SSE/HTTP para producción empresarial con varios usuarios u hosts. SSE/HTTP en despliegue serverless (Vercel, Fly.io, AWS Lambda) es la opción más eficiente.
• Tres capas obligatorias de seguridad: token de servicio en variable de entorno, identificación del usuario del host, log auditable de cada acción. OAuth o SSO en producción empresarial.
• Errores más caros: exponer “todo” antes de validar “algo”, descripciones vagas en resources y tools, sin validación de parámetros, sin log de acciones, devolver datasets enormes.
• Veredicto operativo: empezar con un servidor de 3 resources + 2 tools que cubra el caso de uso más doloroso, validar con 2-3 personas durante 2 semanas, y solo después ampliar. Un servidor pequeño que funciona es mejor que un servidor grande que no se usa.

Fuentes y referencias

• Anthropic — Model Context Protocol official site.
• modelcontextprotocol — SDKs oficiales (Python y TypeScript).
• modelcontextprotocol — MCP Inspector.
• modelcontextprotocol — Servidores oficiales de referencia.
• Anthropic — Introducing the Model Context Protocol (noviembre 2024).

Próximo paso

Si llevas una empresa de servicios con un sistema interno (CRM, gestor documental, ERP a medida, base de proyectos) y reconoces la situación —el equipo copia-pega entre Claude y el sistema, las integraciones a medida cuestan caro y se rompen con cada cambio de modelo, sabéis que MCP es el camino pero no por dónde empezar—, el siguiente paso es una conversación de 30 minutos para diseñar el primer servidor MCP concreto para tu empresa. Sin preparación previa, sin compromiso.

Agendar reunión →