The Hilo MCP server enables AI agents to integrate with the Hilo WhatsApp messaging platform (by Cenzontle). It provides tools for diagnostics, webhook management, template handling, validation, usage tracking, and messaging.
Diagnostics: hilo_diagnose checks API credentials, balance, templates, and suggests next steps.
Webhooks: Generate signed samples (hilo_webhook_sample), verify signatures (hilo_verify_webhook_signature), and validate endpoint URLs (hilo_check_webhook_endpoint).
Templates: List approved templates (hilo_list_templates) and get template details with variables (hilo_get_template).
Validation (no cost): Validate single messages (hilo_validate_send) or broadcast payloads (hilo_validate_broadcast) against real templates without sending.
Account Usage: Check credit balance, billed messages, and estimated spend (hilo_get_usage).
Send Messages (costs credits): Send single messages to test/production numbers (hilo_send_message), check delivery (hilo_get_message), and list messages (hilo_list_messages).
Broadcasts (production only): Send bulk template messages (hilo_send_broadcast), get broadcast details (hilo_get_broadcast), and list broadcasts (hilo_list_broadcasts).
Guided Integration: A dedicated prompt (integrar_con_hilo) provides a full integration plan covering credentials, templates, design, and verification.
Provides integration with Hilo, a WhatsApp messaging platform, enabling message sending, template management, usage checking, and webhook verification for WhatsApp communications.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Hilo MCP Créame la integración con Hilo."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Servidor MCP para integrarse con Hilo, la plataforma de mensajería por WhatsApp de Cenzontle.
Su objetivo es acompañar a tu agente mientras construye la integración: le da el contrato real de la API, herramientas para verificar su propio trabajo y un plan a seguir. Le dices «créame la integración con Hilo» y se pone a construirlo.
Opera en sandbox por defecto. Con una key de pruebas (
hilo_sbx_…) los envíos no se cobran y solo llegan al número autorizado. Para operar en producción hace falta un opt-in explícito — ver Producción.
Claude Code:
claude mcp add hilo -e HILO_API_KEY=hilo_sbx_TU_KEY -- npx -y @cenzontle/hilo-mcpDespués reinicia Claude Code (los servidores MCP se cargan al arrancar) y pide:
Créame la integración con Hilo.
¿Aún no tienes la key? Instálalo igual, sin -e: el servidor arranca de todos modos, el agente puede leer el contrato de la API e ir escribiendo el código, y hilo_diagnose te dirá exactamente qué pedirle al operador de Hilo.
Related MCP server: lingtai-whatsapp
Node 20 o superior.
Una API key de sandbox (hilo_sbx_…). No hay registro en autoservicio: el operador de Hilo crea la cuenta y la entrega.
El servidor arranca sin key: el agente puede leer el contrato y avanzar en el código mientras la consigues, y te dirá exactamente qué pedir.
Si prefieres versionar la configuración con tu proyecto en vez de usar el comando de arriba. No necesitas instalar nada: npx descarga el paquete al vuelo.
Claude Code (.mcp.json del proyecto, o ~/.claude.json):
{
"mcpServers": {
"hilo": {
"command": "npx",
"args": ["-y", "@cenzontle/hilo-mcp"],
"env": { "HILO_API_KEY": "hilo_sbx_tu_key_aqui" }
}
}
}Claude Desktop (claude_desktop_config.json): mismo bloque.
Reinicia el cliente. Deberías ver las herramientas hilo_*, los recursos hilo:// y el prompt integrar_con_hilo.
Variable | Requerida | Default | Para qué |
| No (recomendada) | — | Tu API key. |
| Solo en producción |
| Debe ser |
| No |
| Solo para apuntar a otro entorno. Debe ser HTTPS (se acepta |
| No |
| Timeout por request. |
Le da al agente el contrato de la API, herramientas para verificar su propio trabajo y un plan. La idea es que puedas decir "créame la integración con Hilo" y no tener que supervisarlo.
El prompt integrar_con_hilo le da al agente el orden completo: credencial → plantillas reales → diseño → implementación → verificación → cierre. En Claude Code aparece como /hilo:integrar_con_hilo, o simplemente pídeselo en tus palabras.
Recurso | Contenido |
| Endpoints, cuerpos, respuestas, estados y errores |
| Firma HMAC, ejemplos en Node y Python, reglas de operación |
| Orden recomendado y los errores que se repiten |
Se leen sin API key: el agente puede avanzar en el código mientras consigues la credencial.
Herramienta | Para qué |
| Estado de la integración y siguiente paso concreto |
| Evento firmado real para probar tu handler sin exponer nada |
| Depura por qué tu handler rechaza eventos legítimos |
| Revisa si tu URL sirve (HTTPS, host público) |
Herramienta | Para qué | Costo |
| Qué plantillas existen y qué variables esperan | — |
| Valida el payload contra la plantilla real, sin enviar | — |
| Saldo y consumo | — |
| Estados de entrega | — |
| Avance de un envío masivo | — |
| Envío real de prueba | 1 crédito |
| Envío masivo (solo producción) | 1 por destinatario |
Los envíos van marcados como destructivos: tu cliente MCP debería pedirte confirmación.
Dar de alta plantillas no está incluido: se crean en la cuenta real de WhatsApp, las revisa Meta y no tienen ambiente de pruebas. Coordínalas con el operador.
Instálalo, ábrelo en tu proyecto y pide la integración:
«Créame la integración con Hilo.»
El agente lee el contrato, corre hilo_diagnose, y si no hay credencial te dice exactamente qué pedirle al operador. Con la key de sandbox puesta, implementa el cliente, el envío y el handler del webhook, y verifica su propio trabajo: valida payloads contra las plantillas reales, manda un mensaje de prueba al número autorizado y comprueba que tu handler acepta un evento firmado y rechaza uno falso.
También sirve suelto:
«¿Por qué mi webhook rechaza los eventos de Hilo?» «Valida este broadcast antes de que lo mande.» «¿Cómo va el broadcast de la boda de Ana?»
Es el modo por defecto. Con una key hilo_sbx_…:
Los envíos no se cobran.
Solo llegan al número de prueba que el operador autorizó.
Hay un tope de mensajes por cuenta.
hilo_send_broadcast está deshabilitado — usa hilo_send_message para probar.
Todo lo demás —consultar plantillas, estados, broadcasts y saldo— funciona igual que en producción.
Cuando el operador te entregue tu key productiva, cambia dos cosas en la configuración:
"env": {
"HILO_API_KEY": "hilo_tu_key_productiva",
"HILO_ALLOW_PRODUCTION": "true"
}Las herramientas son exactamente las mismas: lo que construiste y probaste en sandbox sigue funcionando sin tocar una línea. Lo que cambia es que los envíos son reales, se cobran, llegan a cualquier número y se habilita hilo_send_broadcast.
El opt-in existe a propósito: sin él, instalar este servidor nunca puede provocar un envío real por accidente.
pnpm install
pnpm test # 43 tests, sin red
pnpm typecheck
pnpm buildPara probar contra un Hilo local:
HILO_API_KEY=hilo_sbx_dev HILO_BASE_URL=http://localhost:3000 node dist/index.jssrc/
config.ts Lectura y validación del entorno
client.ts Cliente HTTP de la API v1 (único punto que hace fetch)
server.ts Registra recursos, prompt y herramientas
index.ts Entrypoint stdio
reference/ Contrato y guías que se sirven como recursos MCP
tools/ Una familia de herramientas por archivoLa lógica de herramientas no conoce el transporte, así que añadir un entrypoint HTTP remoto más adelante no obliga a tocarlas.
MIT
Comprueba que la URL de tu webhook cumple lo que Hilo exige antes de configurarla: HTTPS y host público. Hilo bloquea localhost y redes privadas por defensa anti-SSRF, así que para desarrollo hace falta un túnel. NO hace ninguna petición a la URL.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL candidata para recibir los eventos. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations show readOnlyHint=true, and the description adds that it makes no request to the URL. This transparency about safety (no SSRF risk) goes beyond annotations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main action, no unnecessary words. Efficiently communicates the core functionality and a key constraint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description could mention what the return value is (e.g., boolean or validation errors). However, for a simple check, the description is fairly complete and leaves little ambiguity for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with one parameter 'url' described as 'URL candidata'. The description adds that it checks for HTTPS and public host, providing meaning beyond the schema. However, it does not specify the format or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: check if a URL meets Hilo's webhook requirements (HTTPS and public host). It distinguishes itself from sibling tools by specifying it does not make any request to the URL, which is unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises to use this tool before configuring a webhook, and mentions that development requires a tunnel because Hilo blocks localhost. It does not explicitly state when not to use or list alternatives, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Revisa el estado de la conexión con Hilo y devuelve los siguientes pasos concretos. EJECÚTALA PRIMERO, antes de escribir código: te dice si hay credencial, si es de sandbox o productiva, si la API responde, si hay saldo y cuántas plantillas hay disponibles para enviar. Si falta la key, explica exactamente cómo pedirla.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond the readOnlyHint and openWorldHint annotations. It details exactly what the tool checks (credentials, environment, API response, balance, templates) and explains behavior when the key is missing (explains how to ask for it).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with no unnecessary words. It is front-loaded with the main purpose, then provides details and a directive. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description is fully complete. It explains what the tool does, what it checks, what it returns (next steps), and how it handles missing keys.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no need for parameter descriptions. The baseline score of 4 applies as the description sufficiently covers the input aspect.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reviews the Hilo connection status and returns concrete next steps. It specifies what it checks: credential, sandbox/prod, API response, balance, template count. This distinguishes it from sibling tools like hilo_get_template or hilo_send_message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to execute this tool first before writing any code, providing clear guidance on when to use. It doesn't explicitly mention when not to use or alternative tools, but the directive is strong enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Devuelve el detalle de un broadcast con el conteo por estado (status_summary): cuántos se entregaron, cuántos fallaron y cuántos siguen en cola.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Id del broadcast (ej. 'bcast_…'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and openWorldHint. Description adds value by specifying the return structure (status_summary with counts), though it does not disclose other potential fields or error conditions. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single descriptive sentence that is front-loaded and free of redundancy. Every word contributes to understanding the tool's purpose and output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple one-parameter tool with no output schema, the description adequately explains the key return data (status_summary). However, it does not enumerate other possible fields in the broadcast detail, leaving minor ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with the id parameter clearly described. The description does not add extra information beyond what the schema already provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool returns broadcast detail with status counts (entregados, fallados, cola). Uses specific verb 'Devuelve el detalle' and resource 'broadcast', differentiating it from siblings like hilo_get_message or hilo_list_broadcasts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Lacks explicit context, prerequisites, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Devuelve el estado de entrega de un mensaje por su ref. Estados: queued → sent → delivered → read, o failed con failureReason (insufficient_credits | opt_out | provider_rejected).
| Name | Required | Description | Default |
|---|---|---|---|
| ref | Yes | Referencia devuelta al enviar (ej. 'out_ab12…'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and open-world hints. The description adds context on delivery states (queued, sent, delivered, read, failed) and failure reasons, which goes beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the purpose. Every word earns its place, no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter, no output schema, and annotations covering safety, the description adequately covers behavior and possible states. It does not mention idempotency or error codes, but that is minimal for a simple lookup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description for ref. The description mentions ref and gives an example, but adds limited new meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the delivery status of a message by its ref. It lists possible states and failure reasons, distinguishing it from sibling tools like hilo_list_messages that list all messages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after sending a message to check its status but does not explicitly state when to use vs. alternatives like hilo_list_messages for bulk queries. No exclusions or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Devuelve el estado y la estructura (componentes y variables) de una plantilla por nombre.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Nombre de la plantilla. | |
| language | No | Código de idioma. | es_MX |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds specific return content (status, components, variables). No contradictions, and it provides enough context for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 10 words, front-loaded with the verb and resource. Every word adds value; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given only two parameters, one required, and no output schema, the description provides adequate information. It explains what is returned (state and structure) but could elaborate on the format of components/variables. Still sufficient for a low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters. The description mentions 'por nombre' aligning with the required name parameter but adds no new meaning beyond that. Language parameter is documented in schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the status and structure (components and variables) of a template by name. The verb 'Devuelve' is specific, and the resource 'plantilla' is well-defined. It distinguishes from sibling 'hilo_list_templates' which lists all templates without details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by specifying 'por nombre' but no explicit guidance when to use this over alternatives like 'hilo_list_templates'. No when-not-to-use or prerequisite conditions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Devuelve el saldo de créditos, los mensajes facturados del periodo y el gasto estimado. Un crédito equivale a un mensaje. Consúltalo antes de un envío masivo: sin saldo suficiente los envíos quedan en failed con insufficient_credits.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint: true) correctly indicate it's a read-only operation. The description adds the warning about consequences of insufficient credits, enhancing transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with high density: first states what it returns, second gives usage guidance. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given it's a simple read-only tool with no parameters and no output schema, the description fully explains its purpose and key behavior. Nothing missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100% (trivially). Description adds no parameter info, but baseline is 4 for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns balance, billed messages, and estimated spend. It distinguishes itself from sibling tools by focusing on usage/balance info, which no other sibling does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to query before mass sending to avoid failures due to insufficient credits. Provides a concrete use case but doesn't cover when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lista los broadcasts con su resumen por estado. Se puede filtrar por metadata propia.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Máximo de resultados. | |
| metadata | No | Filtra por metadata guardada al crear el broadcast. Ej: {"evento":"boda-ana"} |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds that the tool can filter by metadata, which is behavioral context beyond the annotations, but no side effects or further traits are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences: first states the core function, second adds optional filtering. No wasted words, front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so return values are only hinted ('resumen por estado'). Lacks details on pagination, sorting, or field descriptions. Adequate but incomplete for a listing tool with nested objects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description mentions filtering by metadata, reinforcing the schema, but adds no new meaning for the limit parameter. Overall, minimal added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists broadcasts with a summary by status and allows filtering by metadata. It distinguishes from siblings like hilo_get_broadcast (single broadcast) by indicating it returns multiple broadcasts, but does not explicitly contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing all broadcasts filtered by metadata, but does not specify when to use this over alternatives like hilo_get_broadcast or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lista los mensajes enviados, del más reciente al más antiguo. Se puede filtrar por broadcast, por estado y por metadata propia.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Máximo de resultados (default del servidor). | |
| status | No | Filtra por estado de entrega. | |
| metadata | No | Filtra por metadata guardada al enviar. Ej: {"evento":"boda-ana"} | |
| broadcast | No | Id del broadcast (ej. 'bcast_…') para ver solo sus mensajes. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint (safe) and openWorldHint (incomplete results). The description adds ordering (newest to oldest) and filtering options, which are useful behavioral details. No mention of pagination or rate limits, but annotations cover safety, so this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the main action and filters. It is front-loaded with 'Lista los mensajes enviados' and includes all key points without waste. Could be slightly improved by splitting into two sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with good annotations and no output schema, the description covers purpose, ordering, and filtering. It does not explain the return format or pagination behavior, but these are not critical given the tool's simplicity and the limit parameter hint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for all 4 parameters. The description only repeats the parameter names (broadcast, status, metadata) without adding new semantics beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists sent messages in reverse chronological order. It specifies the resource (messages) and the ordering, distinguishing it from siblings like hilo_get_message (single message) and hilo_list_broadcasts (broadcasts).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions filtering capabilities (by broadcast, status, metadata), indicating when to use this tool. However, it does not explicitly state when not to use it or mention alternatives like hilo_get_message for single messages. Still, context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lista las plantillas disponibles para esta cuenta con su estado en Meta (APPROVED, PENDING, REJECTED). Solo se pueden enviar las APPROVED. Consúltala antes de enviar para usar el nombre exacto y saber qué variables espera.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and open-world, and the description adds context about status values (APPROVED, PENDING, REJECTED) and the rule that only APPROVED are sendable, which is useful beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each earning its place: first states purpose, second adds usage guideline. No extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool without output schema, the description is fully complete: it explains what is returned (list with status), why to use it, and how to interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist in schema (0 params, coverage 100%), so baseline is 4. Description doesn't need to add parameter info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and resource 'templates', specifying the context of account-specific templates with Meta status. It differentiates from sibling tools like hilo_get_template by being a list operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use before sending to get exact template names and variables, and notes that only APPROVED templates are sendable, providing clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Envía una plantilla aprobada a MUCHOS destinatarios de una vez. CUESTA UN CRÉDITO POR DESTINATARIO y llega a personas reales: muestra la lista y el total a quien te lo pide, y espera su confirmación antes de llamarla. Usa idempotencyKey para que un reintento no duplique los envíos. No disponible en cuentas de sandbox.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Código de idioma de la plantilla. | es_MX |
| metadata | No | Metadata libre del broadcast (ej. id del evento). | |
| template | Yes | Nombre de la plantilla aprobada en Meta. | |
| recipients | Yes | Lista de destinatarios. | |
| idempotencyKey | No | Clave única del envío. Con la misma clave, un reintento devuelve el broadcast original en vez de duplicarlo. | |
| templateVariables | No | Variables compartidas por todos. Las del destinatario tienen prioridad. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond annotations: credit cost, confirmation flow, and sandbox restriction. It aligns with annotations (destructiveHint=true, idempotentHint=false) and provides specifics that help the agent understand side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with a few sentences, front-loading the main purpose. It's in Spanish and reads naturally. Could be slightly shorter, but no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 params, nested objects, no output schema), the description covers essential aspects: cost, user confirmation, sandbox restriction, idempotency. It's complete enough for an agent to understand when and how to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions. The description adds minor value by explaining idempotencyKey usage and variable precedence, but this is already implied by the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sends an approved template to many recipients at once. It uses specific verb 'Enviar' and resource 'plantilla aprobada', and distinguishes from siblings like hilo_send_message (single message) and hilo_validate_broadcast (validation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: costs one credit per recipient, shows list and total to user, waits for confirmation, and is not available in sandbox accounts. It mentions idempotencyKey for retries. It doesn't explicitly state when not to use, but implies mass sending.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Envía UNA plantilla de WhatsApp ya aprobada por Meta a un número. CUESTA UN CRÉDITO de la bolsa del cliente y le llega a una persona real: confirma el destinatario y el contenido antes de llamarla. Esta cuenta es de SANDBOX: solo puede enviar al número de prueba autorizado y no se cobra. Devuelve un ref para consultar el estado después con hilo_get_message.
| Name | Required | Description | Default |
|---|---|---|---|
| toPhone | Yes | Destinatario en formato E.164. | |
| language | No | Código de idioma de la plantilla. | es_MX |
| variables | No | Variables del cuerpo, numeradas desde "1" en el orden de la plantilla. Ej: {"1":"Ana","2":"25%"} | |
| templateName | Yes | Nombre exacto de la plantilla aprobada en Meta (ej. 'event_invite'). | |
| headerVariables | No | Variables del encabezado, con numeración propia desde "1". Omitir si la plantilla no tiene header variable. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal destructiveHint=true and readOnlyHint=false. The description adds critical behavioral details: it costs a credit (monetary cost), only works in sandbox with a test number, and returns a 'ref' for tracking. This goes beyond annotations by explaining the real-world impact and limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat verbose but packs important caveats (cost, sandbox, confirmation). It could be tightened without losing key information. The structure is front-loaded with action and cost, which is good, but the warnings add length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no output schema, and the complexity of sending WhatsApp messages, the description covers essential aspects: return value (ref), cost, sandbox limitation, and the need for prior template approval. It is comprehensive for a send tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema already describes all parameters fully. The description adds minimal extra meaning beyond reminding that templateName must be 'exact' and variables follow a numbered scheme. This meets the baseline but does not significantly enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sends an approved WhatsApp template to a phone number. It specifies a single message (UNA plantilla), distinguishing it from broadcast tools like hilo_send_broadcast. The verb 'Envía' and resource 'plantilla de WhatsApp' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context for use: it costs a credit, requires confirmation of recipient and content, and is sandbox-only (limited to test numbers). It mentions after-use verification via hilo_get_message. However, it does not explicitly state when to avoid this tool (e.g., for broadcasts) or provide direct alternatives beyond the return ref hint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Revisa un payload de POST /v1/broadcasts sin enviarlo: teléfonos duplicados o mal formados, variables faltantes por destinatario (considerando template_variables compartidas) y estado de la plantilla. Reporta también el costo en créditos. NO envía nada. Corre esto antes de cualquier envío masivo.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | es_MX | |
| template | Yes | ||
| recipients | Yes | ||
| idempotencyKey | No | Si lo omites se advierte: sin él, un reintento duplica el envío. | |
| templateVariables | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=true. The description reinforces safety by stating 'NO envía nada' and details validation side effects. It adds context beyond annotations: what is checked (phones, variables, template status) and cost reporting.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph with clear information, front-loading the main action. It could be slightly shorter, but every sentence adds value. No redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters with low schema coverage, nested objects, and no output schema. The description covers validation logic and cost reporting but does not explain the return structure or detail how the report is formatted. It is partially complete but lacking output details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only 20% of parameters have a description in the schema (idempotencyKey). The description does not explain the meaning of required parameters like template, recipients, language, or templateVariables. It mentions 'payload' but does not map to individual fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool validates a broadcast payload without sending, listing specific validations (duplicate/malformed phones, missing variables, template status) and cost reporting. It distinguishes from siblings like hilo_send_broadcast and hilo_validate_send by emphasizing 'NO envía nada'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises 'Corre esto antes de cualquier envío masivo', indicating when to use. Contrasts with actual sending by stating 'NO envía nada', implying the correct alternative is to use this for check and then the send tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Revisa un payload de POST /v1/messages contra la plantilla REAL del catálogo: formato del teléfono, existencia y estado de la plantilla, y que las variables del BODY y del HEADER sean exactamente las que espera. NO envía nada ni gasta créditos. Úsala con el payload que genera tu código antes de disparar un envío de verdad.
| Name | Required | Description | Default |
|---|---|---|---|
| toPhone | Yes | ||
| language | No | es_MX | |
| variables | No | ||
| templateName | Yes | ||
| headerVariables | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint: true and openWorldHint: true. The description adds behavioral context by specifying exactly what the validation checks (phone format, template existence, variable exactness) and confirms no sending occurs. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action and key constraints. Every sentence adds value: first explains what it validates, second clarifies it does not send. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a validation tool with 5 parameters and no output schema, the description covers the main checks and safety aspects. However, it does not describe the return format or what happens on success/failure. Given the tool's purpose, the missing output schema detail is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It mentions templateName and toPhone implicitly, and 'variables del BODY y del HEADER' correspond to the variables and headerVariables parameters. However, it does not specify formats or constraints for parameters beyond their role in validation. The description adds some value but not full parameter-level detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific verb 'Revisa' (validates) and resource 'payload de POST /v1/messages contra la plantilla REAL del catálogo'. It details what is checked (phone format, template existence, variables exactness) and explicitly says it does not send, distinguishing it from siblings like hilo_send_message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Úsala con el payload que genera tu código antes de disparar un envío de verdad', providing clear when-to-use guidance. It also states 'NO envía nada ni gasta créditos', implying it is a safe pre-send test. It does not explicitly mention when not to use or alternatives, but the purpose is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Comprueba si una firma corresponde a un cuerpo y un secreto, con la misma fórmula que usa Hilo. Úsala para depurar cuando tu handler rechaza eventos legítimos: casi siempre es porque se firmó el JSON re-serializado en vez del cuerpo crudo.
| Name | Required | Description | Default |
|---|---|---|---|
| secret | Yes | Tu statusWebhookSecret. | |
| rawBody | Yes | Cuerpo crudo recibido, exactamente como llegó. | |
| signature | Yes | Valor del header X-Hilo-Signature (incluye 'sha256='). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so the tool is safe. The description adds behavioral context by stating it uses the same formula as Hilo and points out the raw body requirement. This complements the annotation well without contradicting it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, concise and front-loaded. It efficiently communicates purpose, usage context, and a common mistake without extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a verification tool with no output schema, the description covers the main usage scenario and a typical error. However, it does not mention what the tool returns (e.g., true/false), which is a minor gap. Still, the context is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% parameter descriptions, so the baseline is 3. The description adds value by emphasizing that rawBody must be 'exactly as received,' clarifying a nuance beyond the schema's wording. This justifies a score of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool verifies webhook signatures using Hilo's formula. It distinguishes itself by explicitly mentioning its use for debugging rejected events, which sets it apart from sibling tools that handle different aspects of Hilo's API.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises when to use this tool: debugging when the handler rejects legitimate events. It also provides a common pitfall (re-serialized JSON instead of raw body), offering clear guidance on a typical mistake.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Devuelve un evento de estado idéntico a los que manda Hilo, junto con su header X-Hilo-Signature válido para el secreto que le pases. Sirve para probar TU handler sin exponer un endpoint público ni esperar un mensaje real: manda este cuerpo crudo y este header a tu servidor y comprueba que lo acepta. Prueba también con una firma alterada: tu handler DEBE responder 401.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | Referencia del mensaje. | out_ejemplo123 |
| secret | Yes | El statusWebhookSecret de tu cuenta (o uno de prueba). | |
| status | No | Estado a simular. | delivered |
| failureReason | No | Solo con status=failed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Aligns with annotations (readOnlyHint=true, openWorldHint=false) and adds context about generating a signed event for testing, including expected behavior of the handler.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence adds value: purpose first, then usage instructions, then testing advice. No superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description fully explains what the tool returns (event and header) and covers all necessary usage context for a testing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not significantly elaborate on parameters beyond the schema, but the overall use case is clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns an event identical to real Hilo webhooks with a valid X-Hilo-Signature header, distinguishing it from sibling tools like hilo_verify_webhook_signature and hilo_check_webhook_endpoint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes when to use (testing handler without exposing endpoint), how to use (send body and header to server), and provides testing edge case (altered signature should return 401).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.2.0hilo_check_webhook_endpointhilo_diagnosehilo_get_broadcasthilo_get_messagehilo_get_templatehilo_get_usagehilo_list_broadcastshilo_list_messageshilo_list_templateshilo_send_broadcasthilo_send_messagehilo_validate_broadcasthilo_validate_sendhilo_verify_webhook_signaturehilo_webhook_sampleEach tool has a clearly distinct purpose, from diagnostics to template management, validation, sending, and webhooks. No two tools overlap in functionality; descriptions are detailed and differentiate them.
All tool names follow a consistent 'hilo_verb_noun' pattern with lowercase underscores. Verbs are specific and indicative of the action (get, list, validate, send, etc.).
15 tools is well-scoped for the domain of WhatsApp messaging. It covers diagnostics, templates, validation, sending, broadcasts, webhooks, and usage monitoring without being excessive.
The surface covers the core workflows: connectivity check, template listing, payload validation, single/mass sending, status tracking, and webhook management. Missing are tools to update or delete templates, but the focus on sending and validation is comprehensive.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for Vonage API documentation, code snippets, tutorials, and troubleshooting.
MCP Server for agents to onboard, pay, and provision services autonomously with InFlow
WhatsApp (Web + Business API), SMS, contacts, and call records via 2Chat's MCP server.
MCP server for building and testing AI agents with multi-model experimentation and insights.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/cnzontle/hilo-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
