Give your AI agents a real WhatsApp number to send and receive messages.
Cancela uma entrega agendada pelo seu schedule_id (obtido em list_schedules ou schedule).
| Name | Required | Description | Default |
|---|---|---|---|
| owner_phone | No | Numero do dono (so digitos, como texto ou numero). Passe para reativar a conta se a sessao MCP for nova (clientes stateless). | |
| schedule_id | Yes | ID do schedule a cancelar. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint=true. Description adds that the tool cancels a scheduled delivery and hints at a side effect regarding owner_phone for reactivation, which is beyond annotation info.
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 straightforward sentence, no unnecessary words, front-loaded with key action and resource.
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 simple cancel operation with no output schema, the description provides sufficient context: what it does and where to get the ID. Could mention irreversibility but not essential.
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 descriptions cover 100% of parameters. Description only references schedule_id in context, adding no extra meaning beyond the 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?
Description clearly states the verb 'cancel' and the resource 'schedule' (scheduled delivery), and specifies how to obtain the ID from list_schedules or schedule, distinguishing it from sibling tools that create or list schedules.
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?
Description explicitly says when to use (with a schedule_id from list_schedules or schedule), but does not mention when not to use or provide alternatives beyond those sources.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lista o historico de mensagens do numero-ponte (recebidas e enviadas), mais recentes primeiro. Use para decidir a quem responder com reply.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximo de mensagens (1 a 100). | |
| since | No | Timestamp ISO 8601; retorna apenas mensagens posteriores. | |
| owner_phone | No | Numero do dono (so digitos, como texto ou numero). Passe para reativar a conta se a sessao MCP for nova (clientes stateless). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context about the source (numero-ponte) and ordering (most recent first) beyond what annotations (readOnlyHint, openWorldHint) provide. It does not contradict 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?
The description is a single sentence that is front-loaded with core functionality and no wasted words. It is maximally concise while conveying essential 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 simple list operation with readOnlyHint and openWorldHint annotations, the description adequately covers the purpose and usage context. It lacks explanation of 'numero-ponte' but is otherwise complete given the tool's simplicity.
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 the schema already documents all parameters. The description does not add any additional parameter meaning beyond the schema, aligning with the baseline of 3.
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 lists message history (both received and sent) from a bridge number, most recent first, and explicitly mentions its use in deciding who to reply to with `reply`. This distinguishes it from sibling tools like send, reply, and schedule.
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 says 'Use para decidir a quem responder com `reply`', providing clear guidance on when to use this tool. While it doesn't list when not to use or alternative tools, the context is sufficient for a list operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lista as entregas agendadas (recorrentes/unicas) desta conta, com proximo disparo.
| Name | Required | Description | Default |
|---|---|---|---|
| owner_phone | No | Numero do dono (so digitos, como texto ou numero). Passe para reativar a conta se a sessao MCP for nova (clientes stateless). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description adds modest context: it lists schedules 'of this account' and mentions including the next trigger. No additional behavioral traits like side effects or auth needs are disclosed, but the description aligns with annotations and provides minimal extra value.
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: one sentence that conveys the main purpose and key detail (next trigger). However, it could be better structured with separate lines for key aspects. It is front-loaded with the action verb and resource.
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 simple list tool with one optional parameter and no output schema, the description is adequate. It mentions that listings include the next trigger, which gives some return structure context. However, it lacks information on pagination, filtering, or output format. Annotations provide some behavioral context (read-only, open world).
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% and the schema already describes the only parameter (owner_phone) in detail. The tool description does not add any parameter-specific information beyond the schema. Baseline score of 3 is appropriate since the description offers no extra value for parameter semantics.
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 scheduled deliveries (recurring/unique) for the account and includes the next trigger. It uses a specific verb 'list' and resource 'schedules', distinguishing it from siblings like 'schedule' (create) and 'cancel_schedule' (delete).
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 does not provide explicit guidance on when to use this tool versus alternatives. It implies usage for listing schedules but lacks when-not-to-use or alternative tool suggestions. The context from sibling names provides some implicit differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ATIVA a conta Kontato do telefone informado — cria apenas se ainda nao existir; se ja existe, reutiliza a MESMA conta (e normal e esperado chamar com conta existente: funciona como login). IDEMPOTENTE POR TELEFONE: se ja existe conta para o owner_phone, devolve a MESMA conta — entao e seguro chamar de novo em qualquer sessao ou depois de um restart (o usuario nunca precisa lidar com api_key). Se a resposta vier com verification_required=false (numero ja verificado antes), NAO peca OTP: chame send direto. Informe owner_phone (formato internacional so digitos, ex: 5511999998888) para habilitar o caso seguro de self-notification: o agente entrega no WhatsApp do proprio dono. Retorna o whatsapp_bridge_number (numero generico do Kontato que envia, nunca o numero pessoal do dono).
| Name | Required | Description | Default |
|---|---|---|---|
| No | E-mail do dono (opcional). | ||
| owner_phone | No | Numero WhatsApp do dono, so digitos, como texto ou numero (ex: 5511999998888). Vira o destino default das self-notifications. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes idempotency, OTP handling, self-notification case, and return value (whatsapp_bridge_number). No contradiction with annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true).
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?
Multiple sentences but each adds unique value; no redundancy. Could be slightly more concise but appropriate for complexity.
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, description explains return value and OTP handling. Covers all key aspects for a creation/login tool with idempotency.
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%, but description adds valuable context: owner_phone format and self-notification purpose, email optional. Enhances understanding beyond 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 it creates or reuses a Kontato account, distinguishes from siblings like verify_number, and explains idempotent login behavior.
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 provides when to use (activation/reuse), when not to ask for OTP, when to call 'send', and format for owner_phone. No comparison to siblings but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Responde a um numero especifico que mandou mensagem para o numero-ponte. Igual a send, mas "to" e OBRIGATORIO. Responder a quem te escreveu (reply-ratio alto) e mais seguro que cold outbound.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Destino so com digitos, como texto ou numero (ex: 5511999998888). | |
| message | Yes | Texto da resposta. | |
| owner_phone | No | Numero do dono (so digitos, como texto ou numero). Passe para reativar a conta se a sessao MCP for nova (clientes stateless). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false; description adds context that replying is safer than cold outbound, but doesn't disclose potential failure modes (e.g., if the number hasn't messaged).
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, front-loaded sentences that efficiently convey purpose, usage, and risk comparison without 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?
The description covers the core purpose and comparisons but omits any mention of the optional `owner_phone` parameter and its role in re-activating accounts, leaving a small gap for new users.
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 covers all 3 parameters with descriptions (100% coverage), and the description only reiterates that 'to' is mandatory, adding minimal new meaning.
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 replies to a specific number that messaged the bridge, and distinguishes it from the sibling tool `send` by noting 'to' is mandatory.
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 recommends this tool over `send` for replies because it enforces the mandatory 'to' and is safer than cold outbound messaging.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Registra uma entrega recorrente ou unica no scheduler do Kontato. No horario, o Kontato roda o prompt como um agente completo (com web/Exa) e entrega no WhatsApp do dono. USE ISTO para "todo dia me manda X": voce nao precisa ficar online nem prometer trabalho futuro — o scheduler dispara sozinho. O prompt deve ser autossuficiente (ex: "Busque as principais noticias do mercado financeiro de hoje e entregue um resumo curto").
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | O que entregar quando disparar. Autossuficiente. | |
| owner_phone | No | Numero do dono (so digitos, como texto ou numero). Passe para reativar a conta se a sessao MCP for nova (clientes stateless). | |
| schedule_type | Yes | cron=recorrente em horarios; interval=a cada N ms; once=uma vez. | |
| schedule_value | Yes | cron: "0 8 * * *" (todo dia 8h, fuso BRT) | interval: ms como "3600000" | once: horario local "2026-06-20T15:30:00" (sem Z). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description explains the delivery mechanism (runs prompt as full agent with web/Exa, delivers via WhatsApp). Annotations indicate non-destructive and possibly world-changing, which aligns. No contradictions, but could mention error or conflict behavior.
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 action and usage guidance. Could be slightly more concise, but every sentence adds necessary context.
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's complexity (scheduling, agent execution) and no output schema, the description covers purpose, usage, and an example. Lacks error or cancellation info, but adequate for an AI 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 coverage is 100%. Description adds value by explaining the 'prompt' should be self-sufficient with an example, and clarifies that 'owner_phone' is for reactivation on new sessions. This goes beyond the base schema descriptions.
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 schedules a recurring or one-time delivery using a prompt, and runs an agent with web/Exa to deliver to WhatsApp. It distinguishes from siblings like 'send' by emphasizing recurrence and automation.
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 tells when to use it ('todo dia me manda X') and contrasts with needing to be online. It does not mention alternatives like 'send' for one-off messages, but the guidance is clear and practical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Envia uma mensagem de WhatsApp pelo numero-ponte do Kontato. CASO SEGURO: se OMITIR "to", entrega no WhatsApp do PROPRIO DONO (self-notification). JANELA DE 24H: e resolvida AUTOMATICAMENTE pelo servidor — mande so "message"; se a janela do WhatsApp estiver fechada, o Kontato embrulha o texto num template aprovado e entrega mesmo assim (a resposta volta com via="template"). NAO pergunte ao dono sobre janela nem sobre template; nunca peca para ele "mandar oi" antes. REGRA TURN-BASED: voce nao executa trabalho no futuro; se pedirem algo recorrente ("todo dia me manda X"), faca a entrega de HOJE agora e oriente a registrar um schedule, nunca prometa entrega futura.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Destino so com digitos, como texto ou numero. OMITA para enviar ao proprio dono (recomendado). | |
| message | No | Texto da mensagem (obrigatorio quando NAO usar template). | |
| owner_phone | No | Numero do DONO da conta (so digitos, como texto ou numero). Passe SEMPRE que souber: reativa a conta automaticamente quando a sessao MCP e nova (clientes stateless como o conector do claude.ai). | |
| template_name | No | AVANCADO, normalmente DESNECESSARIO: a janela de 24h ja e tratada sozinha pelo servidor. Use apenas para escolher um template especifico. Templates disponiveis (nome, variaveis em ordem): kontato_aviso (1 variável: texto da notificação) — Notificação genérica do agente para o dono. É o template usado AUTOMATICAMENTE pela API quando a janela de 24h está fechada.; kontato_lembrete (1 variável: texto do lembrete) — Lembrete que o dono programou com o agente.; kontato_ativacao (2 variáveis: nome do destinatário, nome do agente ou da empresa) — Primeiro contato com um destinatário NOVO (traz botões "Ativar recebimento" / "Não quero receber").. | |
| template_variables | No | Variaveis posicionais do template ({{1}}, {{2}}...), em ordem. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses substantial server-side behavior beyond the annotations: automatic template wrapping when the 24h window is closed, the via='template' response marker, self-notification delivery behavior, and the turn-based constraint that no future work will be executed. These traits are not derivable from readOnlyHint=false, openWorldHint=true, or destructiveHint=false, and there is no contradiction with any annotation.
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 carries operational weight: purpose, safe case, 24h window, guardrails, and turn-based rule, with the most failure-prone rules front-loaded. The ALL-CAPS emphasis and single dense paragraph is stylistically heavy, but the length is justified by the number of critical behaviors that must be conveyed.
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 5-parameter, zero-required, no-output-schema tool, the description plus schema covers purpose, parameter semantics, window handling, self-notification, and the turn-based policy. The only gap is the standard response format — only the via='template' return marker is described — but this is a minor omission for a send operation.
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%, with each of the 5 parameters already richly documented (e.g., 'to' covers digit-only format and owner-omission behavior; template_name enumerates all templates with variable orders). The main description reinforces the usage context of 'to' and 'message' but adds no meaning beyond what the schema provides, so the baseline 3 applies.
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 opens with a specific verb+resource: 'Sends a WhatsApp message via the Kontato bridge number.' It goes beyond the title by specifying the bridge mechanism and immediately distinguishing a key variant (self-notification when 'to' is omitted), which separates it from siblings like reply and schedule.
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 gives explicit when/when-not guidance: omit 'to' for self-notification, send just 'message' and let the server resolve the 24h window, never ask the owner to send a greeting first, and for recurring requests deliver today and direct the owner to register a schedule. It explicitly names the schedule sibling as the alternative for future/recurring work.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mostra o estado da conta Kontato: ativa ou nao, numero-ponte, e os schedules (rotinas) ja registrados. Use para honrar a regra turn-based: antes de dizer que algo sera entregue "todo dia", confirme aqui se existe um schedule ativo.
| Name | Required | Description | Default |
|---|---|---|---|
| owner_phone | No | Numero do dono (so digitos, como texto ou numero). Passe para reativar a conta se a sessao MCP for nova (clientes stateless). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and openWorldHint. The description adds context about what is returned (account status, bridge number, schedules), which is useful. No behavioral contradictions detected.
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 extremely concise: two sentences without any wasted words. The first sentence states the purpose, and the second provides a direct usage guideline. Excellent front-loading.
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?
While the description covers the key information, it lacks details on the return structure (no output schema). Also, there is potential overlap with list_schedules that is not clarified. For a simple tool, it is adequate but not fully complete.
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%, and the parameter description already explains the purpose and usage of owner_phone (reactivation for stateless clients). The tool description does not add further parameter semantics beyond the 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 it shows account status, bridge number, and schedules. It uses a specific verb 'mostra' and names the resources. It distinguishes from siblings like list_schedules by including schedules as part of a broader status check, but could more explicitly differentiate when to use this vs list_schedules alone.
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 an explicit rule: 'Use para honrar a regra turn-based: antes de dizer que algo sera entregue todo dia, confirme aqui se existe um schedule ativo.' This tells the agent exactly when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Confirma o numero do dono com o codigo OTP de 6 digitos que chegou no WhatsApp dele apos o provision. OBRIGATORIO antes de enviar/agendar: ate verificar, send/reply/schedule retornam 403 owner_not_verified. Se o codigo expirou ou errou demais, chame de novo apos pedir um novo (resend) ao operador.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Codigo de 6 digitos recebido no WhatsApp do dono (texto ou numero). | |
| owner_phone | No | Numero do dono (so digitos, como texto ou numero). Passe para reativar a conta se a sessao MCP for nova (clientes stateless). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses important behavioral traits: OTP validity, error codes, prerequisite nature. Adds context beyond annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false) without 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?
Description is concise, each sentence adds value. Front-loaded with action and prerequisite warnings. 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?
Covers purpose, parameters, usage guidelines, and error handling. No output schema needed for verification tool; description is fully sufficient for agent decision and invocation.
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?
Adds meaning to both parameters: 'code' is described as a 6-digit string from WhatsApp after provision; 'owner_phone' is for reactivation in stateless sessions. Schema coverage is 100%, but description enriches 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?
Clearly states it verifies the owner's number with a 6-digit OTP received on WhatsApp after 'provision'. Distinguishes itself from sibling tools like send, reply, schedule by highlighting it is a prerequisite.
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 says it is mandatory before send/reply/schedule, and warns of 403 error if not done. Also advises to request a new code via 'resend' if the code expires or too many errors.
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.
send1 field changedInput schema / properties / template_name / descriptionPrevious value: -"Nome de template APROVADO da Meta (ex: kontato_ativacao). Use APENAS para partida fria pontual ou janela de 24h fechada — o padrao do produto e o destinatario iniciar a conversa. Template atravessa a janela."New value: +"AVANCADO, normalmente DESNECESSARIO: a janela de 24h ja e tratada sozinha pelo servidor. Use apenas para escolher um template especifico. Templates disponiveis (nome, variaveis em ordem): kontato_aviso (1 variável: texto da notificação) — Notificação genérica do agente para o dono. É o template usado AUTOMATICAMENTE pela API quando a janela de 24h está fechada.; kontato_lembrete (1 variável: texto do lembrete) — Lembrete que o dono programou com o agente.; kontato_ativacao (2 variáveis: nome do destinatário, nome do agente ou da empresa) — Primeiro contato com um destinatário NOVO (traz botões \"Ativar recebimento\" / \"Não quero receber\").."cancel_schedule1 field changedInput schema / properties / owner_phone / descriptionPrevious value: -"Numero do dono (so digitos). Passe para reativar a conta se a sessao MCP for nova (clientes stateless)."New value: +"Numero do dono (so digitos, como texto ou numero). Passe para reativar a conta se a sessao MCP for nova (clientes stateless)."list_messages1 field changedInput schema / properties / owner_phone / descriptionPrevious value: -"Numero do dono (so digitos). Passe para reativar a conta se a sessao MCP for nova (clientes stateless)."New value: +"Numero do dono (so digitos, como texto ou numero). Passe para reativar a conta se a sessao MCP for nova (clientes stateless)."list_schedules1 field changedInput schema / properties / owner_phone / descriptionPrevious value: -"Numero do dono (so digitos). Passe para reativar a conta se a sessao MCP for nova (clientes stateless)."New value: +"Numero do dono (so digitos, como texto ou numero). Passe para reativar a conta se a sessao MCP for nova (clientes stateless)."provision1 field changedInput schema / properties / owner_phone / descriptionPrevious value: -"Numero WhatsApp do dono, so digitos (ex: 5511999998888). Vira o destino default das self-notifications."New value: +"Numero WhatsApp do dono, so digitos, como texto ou numero (ex: 5511999998888). Vira o destino default das self-notifications."reply2 fields changedInput schema / properties / owner_phone / descriptionPrevious value: -"Numero do dono (so digitos). Passe para reativar a conta se a sessao MCP for nova (clientes stateless)."New value: +"Numero do dono (so digitos, como texto ou numero). Passe para reativar a conta se a sessao MCP for nova (clientes stateless)."Input schema / properties / to / descriptionPrevious value: -"Destino so com digitos (ex: 5511999998888)."New value: +"Destino so com digitos, como texto ou numero (ex: 5511999998888)."schedule1 field changedInput schema / properties / owner_phone / descriptionPrevious value: -"Numero do dono (so digitos). Passe para reativar a conta se a sessao MCP for nova (clientes stateless)."New value: +"Numero do dono (so digitos, como texto ou numero). Passe para reativar a conta se a sessao MCP for nova (clientes stateless)."send6 fields changedInput schema / properties / message / descriptionPrevious value: -"Texto da mensagem."New value: +"Texto da mensagem (obrigatorio quando NAO usar template)."Input schema / properties / owner_phone / descriptionPrevious value: -"Numero do DONO da conta (so digitos). Passe SEMPRE que souber: reativa a conta automaticamente quando a sessao MCP e nova (clientes stateless como o conector do claude.ai)."New value: +"Numero do DONO da conta (so digitos, como texto ou numero). Passe SEMPRE que souber: reativa a conta automaticamente quando a sessao MCP e nova (clientes stateless como o conector do claude.ai)."Input schema / properties / template_nameAdded value: +{
+ "description": "Nome de template APROVADO da Meta (ex: kontato_ativacao). Use APENAS para partida fria pontual ou janela de 24h fechada — o padrao do produto e o destinatario iniciar a conversa. Template atravessa a janela.",
+ "type": "string"
+}Input schema / properties / template_variablesAdded value: +{
+ "description": "Variaveis posicionais do template ({{1}}, {{2}}...), em ordem.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Input schema / properties / to / descriptionPrevious value: -"Destino so com digitos. OMITA para enviar ao proprio dono (recomendado)."New value: +"Destino so com digitos, como texto ou numero. OMITA para enviar ao proprio dono (recomendado)."Input schema / requiredRemoved value: -[
- "message"
-]status1 field changedInput schema / properties / owner_phone / descriptionPrevious value: -"Numero do dono (so digitos). Passe para reativar a conta se a sessao MCP for nova (clientes stateless)."New value: +"Numero do dono (so digitos, como texto ou numero). Passe para reativar a conta se a sessao MCP for nova (clientes stateless)."verify_number2 fields changedInput schema / properties / code / descriptionPrevious value: -"Codigo de 6 digitos recebido no WhatsApp do dono."New value: +"Codigo de 6 digitos recebido no WhatsApp do dono (texto ou numero)."Input schema / properties / owner_phone / descriptionPrevious value: -"Numero do dono (so digitos). Passe para reativar a conta se a sessao MCP for nova (clientes stateless)."New value: +"Numero do dono (so digitos, como texto ou numero). Passe para reativar a conta se a sessao MCP for nova (clientes stateless)."cancel_schedule1 field changedInput schema / properties / owner_phoneAdded value: +{
+ "description": "Numero do dono (so digitos). Passe para reativar a conta se a sessao MCP for nova (clientes stateless).",
+ "type": "string"
+}list_messages1 field changedInput schema / properties / owner_phoneAdded value: +{
+ "description": "Numero do dono (so digitos). Passe para reativar a conta se a sessao MCP for nova (clientes stateless).",
+ "type": "string"
+}list_schedules1 field changedInput schema / properties / owner_phoneAdded value: +{
+ "description": "Numero do dono (so digitos). Passe para reativar a conta se a sessao MCP for nova (clientes stateless).",
+ "type": "string"
+}reply1 field changedInput schema / properties / owner_phoneAdded value: +{
+ "description": "Numero do dono (so digitos). Passe para reativar a conta se a sessao MCP for nova (clientes stateless).",
+ "type": "string"
+}schedule1 field changedInput schema / properties / owner_phoneAdded value: +{
+ "description": "Numero do dono (so digitos). Passe para reativar a conta se a sessao MCP for nova (clientes stateless).",
+ "type": "string"
+}send1 field changedInput schema / properties / owner_phoneAdded value: +{
+ "description": "Numero do DONO da conta (so digitos). Passe SEMPRE que souber: reativa a conta automaticamente quando a sessao MCP e nova (clientes stateless como o conector do claude.ai).",
+ "type": "string"
+}status1 field changedInput schema / properties / owner_phoneAdded value: +{
+ "description": "Numero do dono (so digitos). Passe para reativar a conta se a sessao MCP for nova (clientes stateless).",
+ "type": "string"
+}verify_number1 field changedInput schema / properties / owner_phoneAdded value: +{
+ "description": "Numero do dono (so digitos). Passe para reativar a conta se a sessao MCP for nova (clientes stateless).",
+ "type": "string"
+}cancel_schedulelist_schedulesscheduleverify_numberlist_messagesprovisionreplysendstatusClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Run WhatsApp Business campaigns from any AI assistant: contacts, segments, and broadcasts.
Virtual phone numbers for AI agents — rent numbers in 200+ countries, receive SMS.
WhatsApp CRM for AI agents: search contacts, read chats, manage the sales pipeline, send messages.
WhatsApp for your app or AI agent over OAuth2 — the same connections WASync runs inside your CRM.
Add one secure layer between your agents and this server.
Each tool has a clearly distinct purpose: provisioning, verification, sending, replying, scheduling, cancellation, listing schedules, viewing status, and browsing messages. There is no ambiguity between them.
Most names follow a verb_noun pattern in snake_case (e.g., cancel_schedule, list_messages). A few are single verbs (provision, reply, schedule, send) or a noun (status), creating minor inconsistency but still understandable.
9 tools is well-scoped for a WhatsApp messaging/scheduling service. Each tool addresses a distinct operation without being excessive or sparse.
The surface covers the full lifecycle: account setup (provision, verify), messaging (send, reply), scheduling (schedule, list, cancel), status checking, and message history. No obvious gaps for the stated domain.
