Un servidor MCP de empresa profesional necesita seis cosas antes de que lo compartas: autenticación que cumpla la especificación vigente, una frontera de datos que puedas explicar en una frase, respuestas que citen sus fuentes, contenido tan fresco como el negocio, herramientas de las que puedas dar cuenta y un nombre que diga en nombre de quién habla. Todo lo que sigue es esa lista, desplegada en comprobaciones que de verdad puedes ejecutar.

1. Autenticación al día con la especificación

La autenticación MCP ha avanzado rápido, y los clientes siguen la especificación, no tu calendario de versiones. Al día significa OAuth 2.1: los usuarios inician sesión como ellos mismos, los tokens llevan un emisor que el servidor valida y el registro de clientes sigue el flujo CIMD, de modo que los clientes MCP nuevos pueden conectarse sin un ticket de configuración manual. Los servidores de SuperCognit lo implementan de serie; si construiste el tuyo a mano contra un borrador antiguo, arregla esto primero, porque es lo que falla en el momento de conectar — delante de la persona con la que lo compartiste.

  • Cada usuario se autentica individualmente — sin clave compartida en un archivo de configuración que sobrevive a la persona que la pegó.
  • La validación de emisor está activada. Un token del sitio equivocado es un no.
  • Conectarse funciona desde Claude y desde al menos otro cliente MCP. Pruébalo tú antes de que lo pruebe nadie más.

2. Una frontera que puedas explicar en una frase

La frase es: este servidor responde desde este workspace, y desde ningún otro sitio. El aislamiento por workspace hace que eso sea estructural y no aspiracional — el servidor no puede alcanzar conocimiento que no esté en su workspace. Tu trabajo es la parte deliberada: decidir qué entra, y si el servidor es privado o público. Un servidor privado es un cerebro interno de la empresa — procedimientos, políticas, datos de producto para tu propio equipo. Uno público habla en nombre de la empresa ante cualquiera que se conecte. Son productos distintos, y la elección debería llevar un nombre al lado, no ser un valor por defecto.

3. Respuestas que muestran sus fuentes

El MCP de una empresa acaba citado — en documentos, en decisiones y, tarde o temprano, en una reunión donde alguien pregunta de dónde ha salido eso. Las respuestas con citas convierten ese momento en algo aburrido en lugar de algo que frena carreras. Cuando la base de conocimiento se construye rastreando tu web, cada respuesta apunta a la página de la que salió; los documentos subidos se citan de la misma manera.

  • Haz las diez preguntas que tu equipo hace de verdad y sigue cada cita hasta su fuente.
  • La misma construcción produce un agente de chat — úsalo como prueba de humo. Si las respuestas del chat están mal, las respuestas del MCP están mal con pasos extra.
  • Nada en la base de conocimiento debería avergonzarte citado literalmente. Se citará literalmente.

4. Contenido tan fresco como el negocio

Las respuestas rancias son peores que la ausencia de respuestas, porque llegan con aplomo. El conocimiento se resincroniza según un calendario — hasta cada hora — y la cadencia es una decisión por fuente, no un interruptor global que se configura y se olvida. Las páginas de precios, disponibilidad y políticas se ganan un calendario rápido; la página de historia de la empresa puede esperar. Con los documentos subidos la sincronización no te salva: cada documento necesita un responsable que lo sustituya cuando la realidad cambie, o el servidor se convierte en un archivo histórico con mucha seguridad en sí mismo.

5. Herramientas de las que puedas dar cuenta

El conocimiento responde preguntas; las herramientas ejecutan acciones. Las herramientas HTTP que asocias se convierten en herramientas MCP invocables, lo que significa que cualquiera que esté conectado puede invocarlas — así que el listón es más estricto que con el contenido. Antes de compartir, deberías poder decir, de cada herramienta del servidor: qué puede tocar, qué hace la peor llamada plausible y por qué está asociada siquiera. Una lista corta de herramientas es una virtud, no una carencia. A un servidor se le juzga por lo que puede hacer, no solo por lo que sabe.

6. Un nombre que diga en nombre de quién habla

Hay soporte de dominios personalizados, y en un servidor de empresa no son cosmética. Un equipo que se conecta a tu propio hostname sabe de quién es este producto y quién responde por sus respuestas; una URL de plataforma dice lo contrario. Si el servidor va a hablar en nombre de la empresa, debería vivir en el nombre de la empresa.

Fíjate en el patrón de la lista: nada de esto es código, todo son decisiones — qué entra, quién se conecta, cómo de fresco, qué puede hacer, de quién es el nombre que lo firma. La construcción en sí es la parte rápida; una base de conocimiento rastreada y con citas existe unos dos minutos después de importar la web. Invierte el tiempo que has ahorrado en la checklist.