Give your AI agents a real WhatsApp number to send and receive messages.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.3/5 across 9 of 9 tools scored. Lowest: 3.6/5.
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.
cancel_scheduleCancel a scheduleACancela 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.
list_messagesList message historyALista 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.
list_schedulesList schedulesALista 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.
provisionActivate Kontato account (create or reuse)AInspectATIVA 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.
replyReply to a WhatsApp contactAInspectResponde 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.
scheduleSchedule a recurring deliveryAInspectRegistra 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.
sendSend WhatsApp messageAInspectEnvia uma mensagem de WhatsApp pelo numero-ponte do Kontato. CASO SEGURO: se OMITIR "to", entrega no WhatsApp do PROPRIO DONO (self-notification). 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 | 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. | |
| template_variables | No | Variaveis posicionais do template ({{1}}, {{2}}...), em ordem. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=false, openWorldHint=true) indicate a write operation with side effects. The description adds specific behavioral details: self-notification when 'to' is omitted, and the turn-based constraint. These go beyond annotations and are valuable for the agent.
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 and uses capitalization for key rules, making it scannable. It could be more structured, but it effectively communicates the essential points without 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 the complexity (5 parameters, no output schema), the description covers key behaviors: self-notification, turn-based rule, and owner_phone re-activation. It does not describe return value or error handling, but the agent can infer success. Overall sufficient for correct use.
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 baseline is 3. The description adds extra context: advising to omit 'to' for self-notification, emphasizing to always pass owner_phone, and restricting template usage to cold starts. These improve parameter 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 it sends a WhatsApp message via a specific bridge, with explicit cases like self-notification when 'to' is omitted. It distinguishes from siblings implicitly but does not explicitly differentiate from 'reply' or 'schedule', which limits clarity.
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 a clear turn-based rule: only do immediate delivery, never promise future delivery. However, it does not guide when to use this tool over alternatives like 'reply' or 'schedule', leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
statusAccount status & schedulesAMostra 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.
verify_numberVerify owner number (OTP)AInspectConfirma 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.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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!