¿Qué es un servidor MCP? Guía sencilla sobre herramientas, recursos y prompts

El problema que resuelven los servidores MCP

Antes de MCP, conectar un asistente a un producto significaba escribir una integración por cada pareja: un plugin de ChatGPT para tu gestor de tareas, una extensión aparte para Cursor, un conjunto de funciones a medida para Claude, y así sucesivamente. Cada asistente tenía su propio formato y cada integración la mantenía quien tuviera suficiente interés.

MCP, publicado por Anthropic en noviembre de 2024 y gobernado hoy como especificación abierta, sustituye las parejas por un estándar. Un producto escribe un servidor. Cualquier asistente que hable MCP (Claude, ChatGPT, Cursor, Codex, VS Code y decenas más a octubre de 2026) puede conectarse a él. El asistente no necesita saber cómo funciona el producto por dentro, solo lo que el servidor dice que ofrece.

La analogía que mejor aguanta es la del puerto USB. Antes, cada dispositivo necesitaba su propio conector; después, cualquier dispositivo podía enchufarse a cualquier ordenador. MCP es ese conector para los asistentes de IA y los sistemas sobre los que actúan.

Las tres cosas que ofrece un servidor

La especificación (revisión actual 2025-11-25) define tres tipos de cosas que un servidor puede exponer. No tiene que ofrecer las tres; muchos solo ofrecen herramientas.

Herramientas

Una herramienta es una función con un nombre, una descripción y un JSON Schema que indica qué argumentos acepta. El modelo lee las descripciones, decide que una herramienta encaja con la petición, rellena los argumentos y la aplicación te pregunta antes de ejecutarla. Las herramientas son la parte de MCP que permite a un asistente actuar y no solo responder.

Nuestro propio servidor expone 85 herramientas. Algunas, para dar una idea: projects_list y project_status leen el estado de un producto; work_create_issue y work_set_issue_status cambian el backlog; crm_list_deals y crm_move_deal tocan el pipeline; calendar_find_time busca un hueco libre entre varias personas; people_find localiza a un compañero por su nombre. Cada una está marcada como lectura o escritura y nombra el ámbito de permiso que necesita.

Recursos

Un recurso es algo que el modelo puede leer como contexto: un documento, un registro, un archivo. La diferencia con una herramienta está en quién elige. Una herramienta la controla el modelo: es él quien decide llamarla. Un recurso lo controla la aplicación: la app o la persona lo adjunta a la conversación, como quien arrastra un archivo a un chat. Los buenos servidores exponen los documentos que la gente, de otro modo, pegaría a mano.

Prompts

Un prompt es una plantilla que el servidor ofrece para una tarea habitual, con huecos para argumentos. Aparece en el asistente como un comando o un elemento de menú, la persona lo elige y el servidor rellena el texto. Son los menos usados de los tres y los más útiles para convertir las herramientas de un servidor en un flujo que alguien puede repetir sin escribir la instrucción cada vez.

Cómo descubre un asistente a un servidor

El protocolo es JSON-RPC 2.0, el mismo formato de petición y respuesta que usan los servidores de lenguaje en los editores de código. Una conexión funciona así:

1. Inicializar. El cliente envía initialize con la versión del protocolo que admite y sus propias capacidades. El servidor responde con su versión y lo que ofrece (herramientas, recursos, prompts y si puede avisar al cliente cuando cambien).
2. Listar. El cliente llama a tools/list y, normalmente, a resources/list y prompts/list. El servidor devuelve el nombre, la descripción y el esquema de entrada de cada herramienta. El modelo ya sabe qué puede hacer.
3. Llamar. Cuando el modelo elige una herramienta, el cliente envía tools/call con el nombre y los argumentos. El servidor hace el trabajo y devuelve un resultado: una lista de elementos de contenido (texto, normalmente) y, opcionalmente, datos estructurados que siguen un esquema de salida.
4. Notificar. Si la lista de herramientas del servidor cambia, porque alguien aprobó un permiso nuevo, por ejemplo, puede enviar una notificación y el cliente vuelve a listar.

Una herramienta que falla de una forma que el modelo debería conocer, como una escritura rechazada o un argumento incorrecto, devuelve un resultado normal con isError: true y un mensaje. El modelo lee el mensaje y puede intentar otra cosa, en vez de que se rompa toda la conexión.

Hay un principio de seguridad incorporado aquí: la especificación indica a las aplicaciones que traten las descripciones de herramientas de un servidor en el que no confían plenamente como no fiables, y que mantengan a una persona en el circuito en las llamadas. Una descripción de herramienta es solo texto escrito por el servidor; un servidor malicioso podría escribir una engañosa.

Servidores locales y remotos

Los servidores tienen dos formas, y la diferencia importa al elegir o construir uno.

Un servidor local corre en tu propia máquina. El asistente lo lanza como subproceso y habla con él por la entrada y salida estándar (el transporte stdio). Suele leer las credenciales de variables de entorno. Así funcionaban la mayoría de los primeros servidores MCP: uno de sistema de archivos, uno de Git, uno de base de datos que apuntas a tu propio Postgres. Bien para un desarrollador; incómodo para un equipo, porque cada portátil necesita el servidor instalado, actualizado y con una clave.

Un servidor remoto corre en internet en un único endpoint HTTPS, con el transporte Streamable HTTP, y lo comparten muchos usuarios. Lo añades al asistente por URL, inicias sesión con OAuth en el navegador y el servidor mantiene separados los datos de cada usuario. Así debería ofrecer MCP un producto alojado, porque nadie quiere instalar nada ni pegar una clave de API en un archivo de configuración. El servidor de Atrix es solo remoto, en https://atrix.dev/api/mcp, por esa razón: un espacio de trabajo es compartido, así que la conexión tiene que ser por persona y revocable.

La entrada del glosario sobre servidores MCP profundiza en los transportes; la versión corta es que stdio es para tu máquina y Streamable HTTP para todo lo compartido.

Una llamada real a una herramienta, de principio a fin

Esto es lo que pasa cuando alguien conectado a nuestro servidor desde Claude Code escribe "registra un bug: el botón de exportar de la página de facturas no hace nada en Safari".

El modelo lee las descripciones que recibió en tools/list y elige work_create_issue. La entrada del glosario sobre herramientas MCP describe la forma general; la llamada concreta es así:

{
  "method": "tools/call",
  "params": {
    "name": "work_create_issue",
    "arguments": {
      "projectId": "Billing",
      "title": "El botón de exportar no hace nada en Safari (página de facturas)",
      "priority": "HIGH"
    }
  }
}

Antes de escribir nada ocurren tres cosas. Claude Code muestra la llamada y pide a la persona que la apruebe. El servidor comprueba que el token presentado tiene el ámbito work.write. Después comprueba que la persona detrás del token puede crear incidencias en ese proyecto; un token nunca puede hacer más que quien lo creó. Si alguna comprobación falla, el resultado vuelve con isError: true y un mensaje que nombra el ámbito que falta, y el modelo le dice a la persona qué añadir.

Si las tres pasan, la incidencia se crea y el resultado lleva su identificador:

{
  "content": [{ "type": "text", "text": "Creada BIL-142: El botón de exportar no hace nada en Safari (página de facturas)" }],
  "structuredContent": { "issueId": "BIL-142", "href": "/dashboard/projects/billing?issue=BIL-142" }
}

La llamada también queda auditada: qué herramienta, qué resultado, qué registro, nunca el contenido. Ese registro de auditoría es la diferencia entre un asistente que puedes dar a un equipo y uno que solo puedes darte a ti.

Fíjate en que "Billing" se pasó como nombre, no como identificador. Un servidor escrito para asistentes debería aceptar nombres siempre que pueda, porque el modelo suele tener el nombre y no el id, y debería rechazar con claridad, listando los candidatos, cuando un nombre es ambiguo.

Servidor MCP vs API vs plugin

Es razonable preguntar para qué hace falta un servidor si el producto ya tiene una API REST. Las tres cosas resuelven problemas distintos.

Una API es para programas. Un plugin es para un asistente. Un servidor MCP es una capa fina sobre la API, con la forma adecuada para que cualquier modelo la lea: nombres y descripciones de herramientas entre las que un modelo puede elegir, esquemas que puede rellenar y resultados que puede entender. En la práctica, nuestro servidor llama a las mismas funciones que nuestra API REST; solo las describe de otra manera.

El límite honesto: un modelo que elige entre 85 herramientas elige a partir de descripciones, y las descripciones mal escritas llevan a llamadas equivocadas. Construir un servidor tiene menos que ver con el protocolo, que cualquier SDK resuelve, y más con nombrar y describir las herramientas para que el modelo elija la correcta.

Cuándo debería usar uno un equipo pequeño

No necesitas construir un servidor MCP para beneficiarte de uno. El caso habitual en un equipo de cinco a quince personas es conectar un asistente que ya pagas a las herramientas que ya usas.

Recurre a un servidor cuando te descubras copiando contexto en una ventana de chat: pegando las tres últimas incidencias, la etapa del trato con un cliente, la página de requisitos. Un asistente conectado lee todo eso por sí mismo. También tiene sentido cuando quieres actuar desde el asistente, registrar incidencias o reservar tiempo, sin cambiar de aplicación.

Espera cuando el servidor es solo local y tendrías que instalarlo en cada portátil, o cuando pide una clave de API pegada sin ámbitos; una clave que lo puede todo, guardada en un archivo de configuración en cinco máquinas, es un riesgo. Y recuerda que el asistente sigue haciendo solo lo que sus herramientas permiten. Nuestro servidor, por ejemplo, no tiene ninguna herramienta que lea un salario, por diseño.

La página de la función MCP indica qué asistentes se conectan hoy a Atrix, y la visión general para desarrolladores tiene la configuración de cada uno.

FAQ

¿Qué significa MCP?

Model Context Protocol. Es una especificación abierta, publicada por Anthropic en noviembre de 2024, que define cómo se conectan las aplicaciones de IA a sistemas externos mediante servidores que exponen herramientas, recursos y prompts. La revisión actual es la 2025-11-25.

¿Un servidor MCP es lo mismo que una API?

No. Una API es una interfaz para programas, documentada para desarrolladores. Un servidor MCP es una capa encima que se describe a sí misma a un modelo de lenguaje en un formato estándar, de modo que el modelo descubre herramientas con tools/list y las llama con tools/call sin que nadie escriba código de unión a medida. La mayoría de los servidores llama a una API por debajo.

¿Necesito programar para usar un servidor MCP?

Para usarlo, no. Los servidores remotos se añaden a un asistente por URL y se autorizan en el navegador; los locales suelen instalarse con un comando. Construir tu propio servidor sí requiere código, aunque los SDK oficiales (TypeScript, Python y otros) se encargan del protocolo.

¿Es seguro conectar un asistente a los datos de mi empresa por MCP?

Depende del servidor. Busca inicio de sesión por persona con ámbitos que tú eliges, permisos resueltos en cada llamada para que el asistente nunca pueda hacer más que tú, un registro de auditoría y la posibilidad de revocar el acceso. Evita los servidores que quieren una única clave todopoderosa pegada en un archivo.

¿Cuál es la diferencia entre una herramienta y un recurso?

Una herramienta es una función que el modelo decide llamar, con el consentimiento del usuario, y puede cambiar datos. Un recurso son datos que la aplicación o el usuario adjuntan para que el modelo los lea, y no puede cambiar nada.

¿Qué asistentes pueden conectarse a servidores MCP?

A octubre de 2026: Claude (web, escritorio y Claude Code), ChatGPT, Cursor, OpenAI Codex, VS Code con GitHub Copilot y muchos otros. La compatibilidad con servidores remotos con OAuth varía según el asistente; revisa los ajustes de conectores de cada uno.

Siguiente paso

Si quieres ver un servidor por dentro, la visión general para desarrolladores explica cómo conectar Claude Code, ChatGPT o Cursor al servidor de Atrix, con el comando exacto para cada uno y una lista de todas las herramientas con su ámbito. La página de la función MCP es la versión no técnica. Para el vocabulario, el glosario tiene entradas sobre servidores MCP y herramientas MCP.