A un servidor MCP se le dan herramientas reales describiendo endpoints HTTP que ya tienes — la URL, los parámetros, dónde van las credenciales — y adjuntándolos al servidor. En SuperCognit, cualquier herramienta HTTP que crees para un agente se convierte en una herramienta MCP invocable en el momento en que publicas: sin SDK, sin código de protocolo, sin despliegue aparte. Si tu CRM y tu calendario tienen API — y la tienen — pueden ser herramientas.

El conocimiento responde; las herramientas actúan

Una base de conocimiento hace al asistente bueno con las preguntas: cuál es la política de reembolsos, qué incluye el plan premium. Las herramientas lo hacen útil para lo que viene después de la pregunta — busca la cuenta de este cliente, comprueba la disponibilidad del jueves, registra la solicitud. Casi todos los flujos reales necesitan las dos mitades, y casi todos los servidores MCP entregan solo la primera, porque la segunda exigía históricamente escribir y alojar un servidor.

La idea poco glamurosa de las herramientas HTTP es que la segunda mitad, en su mayor parte, ya existe. Tu CRM tiene una API. Tu calendario tiene una API. El servicio interno que alguien montó en 2019 tiene una API, sin documentar pero funcional. Una herramienta es un envoltorio descrito alrededor de un endpoint de uno de ellos.

La descripción es la interfaz

El modelo nunca ve tu código. Ve el nombre de la herramienta, su descripción y sus parámetros, y solo con eso decide cuándo llamarla y con qué. «Busca un cliente por dirección de correo; devuelve su plan, su fecha de renovación y sus tickets abiertos» se llamará correctamente. «Integración con el CRM» se llamará mal, o constantemente, o las dos cosas. Escribir descripciones de herramientas es lo más parecido a programar que tiene este flujo de trabajo, y se hace en prosa.

01

Elige un endpoint por herramienta

Una herramienta debe hacer un solo trabajo. Buscar un contacto por correo. Listar los huecos libres de una semana concreta. Crear un borrador de factura. Las herramientas acotadas se llaman bien; una herramienta «para todo» obliga al modelo a adivinar a cuál de sus estados de ánimo te referías.

02

Descríbelo para alguien que no puede ver el código

Di qué hace la herramienta, qué significa cada parámetro y qué devuelve. Nombra los formatos y las unidades. Si un parámetro es una dirección de correo, dilo — la descripción es la única documentación que recibe el modelo.

03

Adjunta, publica y listo

Adjunta la herramienta al proyecto y publica. Queda expuesta como herramienta MCP con un esquema tipado que entiende cualquier cliente — y el agente de chat del mismo proyecto también puede llamarla. Las credenciales se quedan en el lado del servidor, en la configuración de la herramienta; nunca viajan al cliente.

04

Prueba donde vive tu equipo

Conecta el servidor en Claude o en cualquier cliente MCP, pregunta algo que exija la herramienta y observa la llamada. Una descripción vaga se delata en tres preguntas. Arregla la prosa, no el endpoint.

Reglas de diseño que te salvarán más adelante

  • Mínimo privilegio: si la herramienta solo lee, pon detrás una clave de API de solo lectura. Una herramienta no puede exceder la credencial que lleva.
  • Devuelve lo necesario, no el registro entero — una búsqueda de cliente no necesita enviar todos los campos que guarda tu CRM.
  • Mantén las escrituras pequeñas y deliberadas: una herramienta que crea una reserva provisional en el calendario es más segura que una que también puede borrar eventos.
  • Prefiere varias herramientas acotadas antes que una muy lista; el modelo las compone mejor de lo que descifra flags.

Qué no exponer

Una prueba útil: ¿le darías esta capacidad a un recién contratado el primer día, sin supervisión? El acceso al servidor pasa por OAuth 2.1 con identidad por puesto, y cada espacio de trabajo está aislado, así que el radio de impacto está contenido — pero el mecanismo de seguridad más barato es no adjuntar el endpoint peligroso, para empezar. El borrado, la exportación masiva y todo lo irreversible pueden esperar a que las herramientas de solo lectura se hayan ganado el sueldo.

Empieza con dos herramientas de solo lectura: una búsqueda en el CRM y la disponibilidad del calendario. Ese par convierte un servidor de conocimiento en algo que responde a «¿podemos vernos el jueves, y este cliente está en el plan premium?» en un solo intercambio — y se entrega en una tarde.