Give your AI agents a real WhatsApp number to send and receive messages.
Scored across 9 tools
Tools are mostly distinct, but 'send' and 'reply' overlap (both send messages) and 'status' includes schedule listing alongside 'list_schedules'. However, descriptions clarify boundaries, and all other tools target different actions.
Naming mixes verb_noun patterns (cancel_schedule, list_messages, list_schedules) with bare verbs (provision, reply, schedule, send) and a noun (status). Inconsistent but still readable and predictable enough.
9 tools is well-suited for a WhatsApp automation server, covering provisioning, verification, messaging, scheduling, and history without redundancy or bloat.
The surface covers core lifecycle: provision/verify, send/reply, schedule/list/cancel, message history, and status. Missing an update_schedule operation, but agents can work around with cancel+schedule.
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.
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_messagesprovisionreplysendstatusRun 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.
