Cómo pensar la construcción de un servidor MCP
Un servidor MCP es la pieza de software que permite a un asistente de IA llegar a tu sistema. Construir uno tiene menos que ver con el código que con las decisiones: qué exponer, cómo nombrarlo, qué proteger. Esta guía recorre esas decisiones en términos sencillos, de modo que, tanto si escribes el servidor tú mismo como si se lo pides a alguien, sepas cómo es uno bueno.
Empieza por las preguntas, no por el sistema
La tentación es exponer todo lo que tu base de datos puede hacer. Resístela. Un modelo de IA que lee tu servidor ve una lista de nombres de herramientas y descripciones, y elige de esa lista para responder a la pregunta de un usuario. Una lista larga de operaciones de bajo nivel le hace adivinar. Una lista corta de herramientas claras y con un propósito le hace acertar.
Así que empieza por las preguntas que la gente formula de verdad. Para un hotel: ¿está abierto el restaurante esta noche?, ¿tenéis mesa para cuatro?, ¿puedo reservarla?, ¿la piscina es apta para niños?, ¿a qué hora es la salida? Cada una se convierte en una herramienta o un recurso candidato. Todo lo demás espera.
Herramientas, recursos e instrucciones
MCP te da tres clases de cosas que publicar.
Las herramientas son acciones. Reciben entradas y hacen algo o calculan algo: comprobar la disponibilidad para una fecha y un número de comensales, reservar una mesa, consultar el horario de un local concreto. Las herramientas son lo que permite actuar a un agente.
Los recursos son datos para leer. Una lista de locales con sus descripciones, la carta actual, la política de mascotas. El modelo los lee como contexto sin invocar una acción.
Las instrucciones son indicaciones reutilizables. Una instrucción de "planifica una cena en esta propiedad" que le dice al modelo qué herramientas usar y en qué orden. Opcionales, pero útiles para tareas habituales de varios pasos.
Un buen primer servidor suele tener de tres a seis herramientas y unos pocos recursos. Es suficiente para resultar genuinamente útil y lo bastante pequeño para que el modelo lo use correctamente.
Describe cada herramienta como si instruyeras a un nuevo empleado
El modelo elige las herramientas leyendo sus descripciones. Una herramienta llamada "consulta" con la descripción "ejecuta una consulta" será ignorada o mal utilizada. Una herramienta llamada "check_table_availability", descrita como "devuelve si hay mesa disponible en un restaurante concreto para una fecha, hora y número de comensales dados", se invocará correctamente al primer intento.
Nombra las entradas con claridad y di qué formato toman. Una fecha es una fecha en una forma concreta. Un número de comensales es un número entero. Cuanto más precisas sean las entradas, menos solicitudes mal formadas recibirás.
Devuelve resultados estructurados
El resultado que una herramienta envía de vuelta va directo al contexto del modelo. Devuelve campos claros, no un volcado. "disponible: sí, horas: 19:00, 19:30, 20:00" es mejor que una página de HTML. Mantén los resultados compactos; el contexto del modelo es limitado, y una respuesta recargada desplaza a todo lo demás.
Decide qué puede hacer el modelo, y hazlo cumplir
El modelo propone, tu servidor dispone. Trata cada solicitud entrante como no fiable. Valida las entradas. Comprueba los permisos. Para cualquier cosa irreversible o costosa, como una reserva o una cancelación, plantéate que la herramienta pida un paso de confirmación, o que cree una reserva pendiente que una persona apruebe. El modelo nunca debería ser lo único que se interpone entre una solicitud y su consecuencia.
Registra cada llamada. Querrás saber qué pidieron los agentes, qué recibieron y dónde se confundieron.
Mantén los hechos en un solo lugar
Si tu servidor lee de la misma fuente de verdad que tu sitio web y tus datos estructurados, todos los canales coinciden. Si el servidor tiene su propia copia de los horarios, se desviará. Lo ideal es un único almacén de hechos, idealmente un grafo de conocimiento, del que lean el sitio web, el marcado y el servidor MCP por igual.
La conclusión
Un buen servidor MCP es pequeño, está claramente descrito, se valida con rigor y se alimenta de los mismos hechos que todo lo demás que publicas. Parte de las preguntas que la gente formula, expón solo lo que las responde y haz que las descripciones de las herramientas sean lo bastante buenas como para que un modelo las acierte sin prueba y error.
Haz que tu negocio sea recomendable para la IA
Esta es la mecánica que hay detrás de la visibilidad en IA. Si quieres ayuda para convertirla en una estructura que funcione para tu negocio, hablemos.
Habla con nosotros →