¿Qué es un servidor MCP? Guía para fundadores de SaaS sobre si necesitas uno

¿Qué es un servidor MCP?

Un servidor MCP es un servicio que describe lo que tu producto puede hacer en un formato que los asistentes de IA entienden, para que un cliente con sesión iniciada pueda pedirle a Claude, ChatGPT o GitHub Copilot que trabaje con sus propios datos en tu producto. Habla el Model Context Protocol (MCP), un estándar abierto para conectar aplicaciones de IA con herramientas y datos externos. Tu API sigue haciendo el trabajo; el servidor se pone delante, inicia la sesión de las personas y le dice al asistente qué acciones existen.

En un producto de mesa de ayuda, eso significa que un cliente puede pedirle al asistente que ya paga que resuma los tickets escalados de esta semana, y la respuesta sale de tu producto, con los permisos de ese cliente.

Anthropic presentó MCP en noviembre de 2024 y en diciembre de 2025 lo donó a la Agentic AI Foundation, un fondo de la Linux Foundation cofundado con Block y OpenAI. En octubre de 2026 la revisión vigente es la 2026-07-28, la quinta revisión fechada del protocolo. Esta guía cubre la decisión previa a construir; nuestro servicio de desarrollo de servidores MCP cubre la construcción.

Cómo viaja una solicitud por un servidor MCP

Intervienen tres partes: el host es la aplicación de IA que usa tu cliente, un client dentro de ella mantiene una conexión con un servidor, y el servidor es el tuyo. Por diseño, un servidor no lee toda la conversación ni ve dentro de otros servidores: recibes las llamadas a tools y sus argumentos, no el chat que las rodea.

Desde el lado del cliente:

1. Agrega tu servidor a su asistente, por URL o desde un directorio, e inicia sesión con su cuenta en tu producto.
2. El asistente le pide a tu servidor sus tools y lee el nombre y la descripción de cada una.
3. Hace una pregunta, y el modelo elige una tool y sus argumentos.
4. Según el client y la tool, el asistente le pide que confirme la llamada.
5. Tu servidor verifica el token y el permiso de esa tool, llama a tu API y devuelve un resultado corto.
6. El modelo redacta la respuesta o llama a otra tool.

El paso 3 sorprende a la mayoría de los equipos de producto: el modelo elige las tools por sus nombres y descripciones, así que ese texto es copy de producto que lee un modelo. Revísalo como el texto de la interfaz y pruébalo con solicitudes reales.

Tools, resources y prompts

Un servidor MCP puede ofrecer tres tipos de cosas, y la especificación las separa según quién decide cuándo se usan:

Empieza por las tools: es lo que los clientes notan, y el soporte de resources y prompts varía según el client.

Dónde lo usarían tus clientes y cómo lo encontrarían

Los asistentes que tus clientes ya usan se conectan a servidores MCP remotos, alojados en internet en lugar de instalados por cada usuario; el anuncio de la fundación de Anthropic incluye a ChatGPT, Cursor, Gemini, Microsoft Copilot y Visual Studio Code entre los productos compatibles con MCP. Según su documentación de octubre de 2026, se diferencian en cómo un cliente agrega tu servidor y en lo que te piden para un listado público:

Dos reglas de revisión moldean el producto mismo. Los criterios de revisión de conectores de Anthropic rechazan una tool comodín que lee y escribe a la vez, como una tool api_request con un parámetro method, y el directorio de Claude no acepta conectores que muevan dinero. Los requisitos de revisión de OpenAI piden que las tools devuelvan solo lo que la solicitud necesita estrictamente. Si tu producto mueve dinero, planea un servidor al que los clientes se conecten por URL, con una confirmación antes de cada pago.

¿Tus clientes realmente quieren uno?

Un servidor al que nadie se conecta es mantenimiento sin retorno, así que verifícalo primero:

• Cuenta las peticiones. Busca en 90 días de tickets de soporte, notas de ventas y hilos de la comunidad las palabras ChatGPT, Claude, Copilot, Cursor y MCP. Una petición que nombra una tarea, como "¿puede Claude leer nuestros tickets?", te dice más que una que nombra el protocolo.
• Busca el nombre de tu producto en el registry. El MCP Registry lista servidores públicos bajo namespaces que sus publicadores verificaron. El 14 de octubre de 2026, una búsqueda por Zendesk devolvió seis servidores y por HubSpot siete, ninguno bajo un namespace que controlara alguna de las dos empresas; Stripe devolvió quince, incluido el propio com.stripe/mcp de Stripe. El registry no está completo, así que una entrada ausente no prueba nada, pero los servidores de terceros para tu API son demanda visible, y algunos clientes quizá ya le estén entregando sus API keys a un servidor del que no puedes responder.
• Revisa tu categoría en los directorios. Si tus competidores aparecen en el directorio de Claude o de ChatGPT y tú no, espera que salga en las llamadas de ventas.

Luego haz la prueba real más barata: un servidor de solo lectura con tres o cuatro tools, ofrecido a unos pocos design partners. Durante un mes, mira cuántos lo conectan y cuántos vuelven después del primer intento. Si nadie vuelve, lo aprendiste antes de construir escrituras, listados y soporte.

Para que los asistentes de IA recomienden tu empresa, un servidor no ayuda: ningún asistente documenta que encuentre por su cuenta las tools de un sitio, como registran nuestras notas sobre sitios web preparados para agentes, y nuestra guía para aparecer en las respuestas de IA cubre lo que sí ayuda. Si lo que buscas es IA que ejecute un proceso dentro de tu propia empresa, mira la automatización con IA.

Qué exponer primero

Elige de tres a cinco tareas que tus clientes ya hacen en tu producto y que le delegarían a un asistente, y dale a cada una su propia tool, primero las lecturas y después las escrituras. Para un producto hipotético de mesa de ayuda:

Tres reglas hacen que la tabla funcione:

• Devuelve menos que tu API. Los hilos completos, las notas internas y todos los campos personalizados llenan el contexto del modelo con datos que la pregunta no necesitaba. Devuelve resúmenes e IDs; deja que get_ticket traiga el resto.
• Etiqueta cada tool con honestidad. Las tool annotations le dicen a los clients si una tool solo lee o puede destruir algo. Por defecto en el protocolo, una tool sin etiqueta se asume destructiva, y los criterios de revisión de Claude indican que las tools de solo lectura pueden ejecutarse sin preguntar cada vez, mientras que las destructivas siempre piden confirmación. Etiquetas precisas significan menos interrupciones en las lecturas.
• Haz del borrador la escritura por defecto. Un borrador que el cliente aprueba en tu producto le da al asistente trabajo útil sin darle la última palabra.

El inicio de sesión es una decisión de producto

Con OAuth, cada persona inicia sesión con su propia cuenta y el asistente recibe solo lo que ella aprueba. Las reglas de autorización de MCP resuelven la mecánica; las preguntas de producto son tuyas:

• A qué workspace llega una conexión. Muchos usuarios de SaaS pertenecen a varios. Decide si una conexión cubre un workspace o todos, y di cuál en la pantalla de consentimiento.
• Cómo se llaman los scopes. Un administrador puede aprobar tickets:read y drafts:write; una solicitud de acceso total se rechaza. Las buenas prácticas de seguridad de MCP citan los scopes comodín y anunciar todos los scopes posibles entre los errores comunes.
• Cómo lo ve y lo revoca un administrador. Lista los asistentes conectados en tu configuración junto a las API keys, con la fecha de último uso y un botón para revocar.
• Cómo lo comparten los equipos. En los planes Team y Enterprise de Claude, un propietario agrega el conector y cada miembro se conecta con su propia cuenta; una credencial compartida le da a cada miembro su acceso. Las claves compartidas sirven para herramientas internas, no para datos de clientes.

Los riesgos de seguridad que vienen con él

Al modelo que llama a tus tools se le puede convencer de cosas. OWASP clasifica la inyección de prompts como el primer riesgo de las aplicaciones con LLM, incluida la indirecta, en la que las instrucciones llegan dentro del contenido que el modelo lee: un ticket de soporte, un documento compartido, una página web. Los datos de tus propios clientes pueden llevarla. La página de ayuda sobre conectores personalizados de Anthropic también advierte que los servidores maliciosos pueden esconder instrucciones, y que el modo Research de Claude puede llamar a las tools de un conector sin aprobación adicional.

La lethal trifecta de Simon Willison es la prueba más útil que conocemos: datos privados, contenido no confiable y una forma de enviar datos hacia afuera. Un asistente con las tres cosas puede ser manipulado para filtrar datos, y él sostiene que ninguna barrera lo evita de forma confiable. Un servidor de mesa de ayuda tiene las dos primeras por naturaleza, porque los tickets son privados y los escriben personas externas. Por eso, pregúntate de cada tool de escritura si agrega la tercera: ¿podría send_reply enviar por correo los datos de un cliente a una dirección plantada en otro ticket?

Tres preguntas para cada tool antes de lanzarla:

1. ¿Puede el texto que devuelve haberlo escrito alguien distinto del usuario con sesión iniciada?
2. ¿Puede enviar datos fuera de la cuenta o consultar una dirección que se le entrega?
3. Si un modelo manipulado la llamara con los peores argumentos válidos, ¿qué podría pasar dentro de su permiso?

Donde tools que responden que sí a las dos primeras puedan coincidir en una misma conversación, separa sus scopes, exige confirmación o elimina una. Dos reglas de la especificación de MCP no son opcionales: acepta solo tokens emitidos para tu servidor y nunca pases el token de un cliente a otra API. El criterio del modelo nunca es tu control de acceso.

Cuánto cuesta construirlo y mantenerlo

El servidor en sí rara vez es el mayor costo; la estimación crece con todo lo que rodea a la confianza:

• Una API que no está lista: faltan endpoints, no hay permisos por usuario ni límites de tasa. Sin eso, el primer proyecto es el desarrollo de aplicaciones web.
• OAuth, si tu producto aún no tiene inicio de sesión con pantallas de consentimiento y scopes.
• Cada tool de escritura, con su scope, su confirmación y su registro de auditoría.
• Cada client y directorio que prometas, con cuentas de prueba, actualizaciones de la política de privacidad y rondas de revisión.
• Vistas interactivas dentro del chat (MCP Apps), si el texto no alcanza.

Luego viene el mantenimiento. Cinco revisiones fechadas en menos de dos años muestran que el protocolo se mueve; la última eliminó el handshake inicial en el que se apoyan los servidores anteriores. Las funciones obsoletas normalmente permanecen al menos doce meses antes de retirarse, lo que hace que las actualizaciones sean planificables, no opcionales. Trata el servidor como cualquier API pública, con una política de versiones, monitoreo y un responsable con nombre. En nuestra página de precios explicamos cómo presupuestamos este trabajo.

Lo que nos enseñó operar nuestro CMS con MCP

El CMS detrás de dardo.studio, EmDash, tiene un servidor MCP integrado que acepta OAuth o tokens de acceso personal. Nuestros agentes trabajan a través de él: crean borradores de artículos, suben imágenes, enlazan cada artículo con sus servicios y releen cada borrador antes de que algo salga en vivo. Este artículo llegó al CMS así. Cuatro cosas que llevaríamos a un servidor para clientes:

• Una lista larga de tools sirve a tus propios agentes, no a tus clientes. Un servidor interno puede exponer decenas de tools; para clientes, lanza un conjunto pequeño, porque opciones casi idénticas hacen menos confiable la elección del modelo.
• Etiqueta cada tool. Las tools sin indicación de solo lectura o destructiva se tratan como posiblemente destructivas, lo cual es seguro pero implica más confirmaciones, y las revisiones de directorio piden una indicación en cada una.
• Espera diferencias de versión. Servidores y clients pasan a nuevas revisiones del protocolo a distintas velocidades; prueba con las revisiones que usan los clients de tus clientes.
• Pide por defecto el mínimo de scopes. Una página de consentimiento que deja a la persona desmarcar scopes funciona para un equipo pequeño; un producto con miles de clientes debería pedir menos desde el principio.

Dos lecciones salieron del uso. La importación de Markdown del CMS aplana las tablas en líneas de texto plano, así que nuestros agentes envían las tablas en su formato estructurado y verifican el resultado con una tool de lectura: dale a tus agentes una forma de comprobar su propio trabajo. Y las reglas que importan viven en el servidor: el CMS se niega a publicar un artículo sin extracto, sin imagen de portada con texto alternativo y sin texto alternativo en cada imagen, sin importar lo que se le haya dicho a un agente. Nuestro servidor público en dardo.studio, con dos tools de solo lectura y sin inicio de sesión, se describe en nuestras notas sobre sitios web preparados para agentes.

¿Deberías construir uno ahora?

Construye ahora un servidor pequeño de solo lectura si tus clientes piden usar tu producto desde un asistente, tu API ya aplica permisos por usuario y el registry o los directorios confirman la demanda. Si tu API no está lista o nadie lo ha pedido, arregla primero la API y haz la prueba con design partners cuando alguien lo pida.

Cuando estés listo, nuestro servicio de desarrollo de servidores MCP parte de tu API y de las tareas que piden tus clientes. Envíanos ambas y te diremos si todavía vale la pena construir un servidor.