The vistoazul-mcp server enables AI agents (Claude, Cursor, etc.) to operate WhatsApp through the Visto Azul API. Key capabilities include:
Messaging: Send text, media (images, videos, documents), polls, and PIX payment requests to any WhatsApp number.
Enhanced Message Actions: Mark messages as read, send typing/recording presence indicators, react to, edit, or delete messages, and download/transcribe received media.
Number Verification: Check which phone numbers have active WhatsApp accounts before sending (anti-ban feature).
Campaign Management: Create and monitor mass messaging campaigns with spintax templates, variable substitution, delay controls, scheduling, and built-in anti-ban mechanisms.
Contact Management: List contacts (with optional tag filtering) and create or update contact records (name, tags, number).
Webhook Configuration: Set up webhooks on WhatsApp instances to receive incoming messages, enabling chatbot and automated response flows.
Instance Management: List all connected WhatsApp numbers and check their current status.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@vistoazul-mcp enviar mensagem de texto para o contato 'João' com 'Bom dia!'"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Servidor MCP (Model Context Protocol) da Visto Azul. Dê ao Claude, Claude Code, Cursor e a qualquer cliente MCP a capacidade de operar o WhatsApp: enviar texto, mídia e cobrança PIX, disparar campanhas, gerenciar contatos e configurar webhooks — tudo pela API REST do Visto Azul, sem taxa por mensagem da Meta e com anti-ban de fábrica.
O MCP é o padrão que conecta agentes de IA a ferramentas externas. Com este servidor, você pede em linguagem natural — "manda um PIX de R$97 pro cliente", "dispara a campanha pra essa lista" — e o agente executa pela sua conta do Visto Azul.
Related MCP server: WA MCP
Ferramenta | O que faz |
| Lista os números conectados e o status |
| Envia mensagem de texto |
| Envia imagem, vídeo ou documento |
| Envia cobrança PIX na conversa |
| Envia enquete |
| Verifica quem tem WhatsApp (anti-ban) |
| Cria campanha (disparo em massa) |
| Status de uma campanha |
| Lista contatos (filtra por tag) |
| Cria ou atualiza um contato |
| Configura webhook para receber mensagens |
| Baixa a mídia recebida (base64) e transcreve áudio |
| Marca mensagem como lida (tique azul) |
| Envia "digitando…" / "gravando áudio" |
| Reage a uma mensagem com emoji |
| Edita uma mensagem enviada |
| Apaga uma mensagem para todos |
Você precisa de uma API key do Visto Azul: crie a conta em dashboard.vistoazul.com.br, conecte seu número e copie a key em Instâncias.
claude mcp add vistoazul -e VISTOAZUL_API_KEY=SUA_API_KEY -- npx -y vistoazul-mcp{
"mcpServers": {
"vistoazul": {
"command": "npx",
"args": ["-y", "vistoazul-mcp"],
"env": { "VISTOAZUL_API_KEY": "SUA_API_KEY" }
}
}
}Variável | Obrigatória | Padrão |
| sim | — |
| não |
|
🌐 Site: https://vistoazul.com.br
📚 Documentação: https://vistoazul.com.br/docs
🧩 Node do n8n: https://www.npmjs.com/package/n8n-nodes-vistoazul
Consulta o status de uma campanha.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the core function but does not disclose side effects (none expected), error behavior for invalid IDs, or any rate limiting or access requirements.
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 short sentence, which is concise but arguably under-specifies. It conveys the core purpose without unnecessary verbosity, but could include more detail without being wordy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one parameter and no output schema, the description should explain what the returned status looks like (e.g., a string or object). It does not, leaving the agent to guess the response format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. However, the description does not mention the sole required parameter 'id' at all—its semantics, format, or how it identifies the campaign. This is a complete miss.
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 action ('Consulta' = consult/check) and the resource ('status de uma campanha' = status of a campaign). This is specific and distinct from sibling tools like create_campaign or send_text, which perform different actions.
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 no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, typical use cases, or exclusions (e.g., when the campaign ID might be invalid).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verifica quais numeros tem WhatsApp (use antes de disparar, anti-ban).
| Name | Required | Description | Default |
|---|---|---|---|
| numbers | Yes | Lista de numeros a verificar. | |
| instance | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions 'anti-ban' but does not disclose rate limits, error handling, or what happens with invalid numbers. Minimal behavioral insight.
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 sentence, front-loaded with purpose, no wasted words. Highly concise.
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?
With 2 parameters, no output schema, and no annotations, the description is bare minimum. It does not explain return format, whether it modifies state, or how to interpret results. Missing critical context 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 50%; the 'numbers' parameter description is duplicated from schema, and 'instance' lacks description. The tool description adds no extra meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Verifica' (check) and the resource 'numeros tem WhatsApp' (numbers have WhatsApp). It distinguishes well from sibling tools like send_text and send_media by implying this is a pre-send validation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises to 'use antes de disparar, anti-ban' (use before sending to avoid ban), providing clear context for when to use. It does not mention alternatives or when not to use, but the intent is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cria uma campanha (disparo em massa com anti-ban). template aceita spintax {a|b} e variaveis {{nome}}.
| Name | Required | Description | Default |
|---|---|---|---|
| template | Yes | ||
| instances | Yes | Nomes das instancias que vao disparar. | |
| maxDelayMs | No | ||
| minDelayMs | No | ||
| recipients | Yes | ||
| scheduledForMs | No | epoch ms; no futuro = agendada. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Mentions anti-ban safety but does not disclose scheduling behavior, instance requirements, or return value; annotations are absent so description carries the burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with front-loaded purpose, no wasted words, though could mention return value briefly.
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?
Lacks details on return value (presumably campaign ID), scheduling behavior, and instance prerequisites, which are important given the tool's complexity and no output schema.
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 for template (spintax and variables) but minDelayMs, maxDelayMs, and recipients structure are left ambiguous; schema coverage is low (33%).
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 a campaign for mass dispatch with anti-ban, distinguishing it from sibling single-send tools like send_text or send_media.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for bulk sending but lacks explicit guidance on when to use vs alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lista contatos da conta. Filtre por tag opcional.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states listing and optional filtering, but does not mention pagination, rate limits, or whether it lists all contacts or only a subset. This is insufficient for a tool with no safety 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 concise and front-loaded. It communicates the core function efficiently, though it could incorporate more details without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (1 param, no output schema), but the description lacks information about the return format, default behavior without a tag, or any limitations. It is minimally complete but leaves gaps for an agent to guess.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning beyond the schema. It mentions 'tag' as an optional filter but does not specify its format, constraints, or how it affects results. The schema only says type string with no description, so the description adds minimal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and the resource 'contacts da conta' (contacts of the account), and mentions the optional filter by tag. This distinguishes it from sibling tools like upsert_contact (create/update) and send_text (send messages), as it is a read operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions an optional tag filter but provides no guidance on when to use this tool versus alternatives like list_instances or when not to use it. No context about prerequisites or exclusions is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lista as instancias (numeros de WhatsApp) conectadas na conta, com status.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It indicates a read operation (listing) with status, but does not disclose potential limitations, performance, or error cases. Adequate but not detailed.
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 sentence of 15 words, front-loaded with the action and resource. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description mentions status, giving some expectation. For a simple list tool with no parameters, it is largely complete, though the output format could be hinted.
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?
There are 0 parameters, and schema coverage is 100%. The description does not add parameter info since none exist. Baseline 4 applies for 0-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list) and resource (instances/WhatsApp numbers) and specifies that status is included. It is distinct from sibling tools like list_contacts, which list contacts, not instances.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, when not to use it, or any prerequisites. The description simply states what it does without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Envia midia (imagem, video ou documento) por uma URL publica, com legenda opcional.
| Name | Required | Description | Default |
|---|---|---|---|
| file | Yes | URL publica do arquivo. | |
| text | No | Legenda (opcional). | |
| type | Yes | ||
| number | Yes | ||
| instance | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears full responsibility. It only states the action without disclosing behavioral traits such as result handling, error behavior, or side effects. The description is vague and insufficient.
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, short and to the point. However, its brevity leaves out important details, and the language (Portuguese) may reduce clarity for a broader audience. It could be more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters and no output schema, the description is too brief. It does not explain the purpose of fields like 'number' or 'instance', nor does it describe success/error behavior or return format. The context is incomplete for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 40% (2 of 5 parameters have descriptions). The tool description does not add meaning beyond the schema; it does not elaborate on parameters like 'number' or 'instance' or clarify format requirements. It fails to compensate for low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sends media (image, video, document) via a public URL with optional caption. The verb 'Envia' and resource 'midia' are specific, and it distinguishes from siblings like send_text or send_poll.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not mention when to use this tool versus alternatives, nor any prerequisites or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Envia uma cobranca PIX na conversa do WhatsApp.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | ||
| title | No | ||
| amount | Yes | Valor da cobranca. Ex: 97.00 | |
| number | Yes | ||
| pixKey | Yes | Sua chave PIX. | |
| pixType | Yes | ||
| instance | No | ||
| itemName | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavioral traits. It lacks any detail about side effects, required permissions, error handling, or state changes beyond the basic action.
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, which is concise, but at the expense of necessary detail. It is appropriately sized for a simple tool but insufficient for this parameter-rich tool.
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 8 parameters, no output schema, and no annotations, the description is far from complete. It fails to explain return values, error states, or usage examples.
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 only 25% (amount and pixKey have descriptions), and the tool description adds no additional meaning for the 8 parameters. Critical fields like number, text, instance are undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sends a PIX charge in a WhatsApp conversation, using a specific verb and resource. It distinguishes itself from sibling tools like send_text or send_media by focusing on payment charges.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, no prerequisites or exclusion criteria. The description merely states the action without contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Envia uma enquete (poll) no WhatsApp.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Pergunta da enquete. | |
| number | Yes | ||
| choices | Yes | Opcoes da enquete. | |
| instance | No | ||
| selectableCount | No | Quantas opcoes o contato pode marcar (padrao 1). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description does not disclose any behavioral traits (e.g., whether it requires authentication, what happens on failure, or if it's idempotent). The description is too brief.
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 short sentence, which is concise, but it sacrifices necessary detail. It could be longer to improve completeness without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no output schema, and no annotations, the description is incomplete. It fails to explain how to specify the recipient number or instance, or what the response looks like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning beyond the schema. It does not explain the role of 'number' or 'instance', which are undocumented in the schema. Schema coverage is 60%, but the description does not compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'sends' and the resource 'poll on WhatsApp', distinguishing it from siblings like send_text or send_media. It is specific but lacks some nuance (e.g., that it sends to a single number).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this vs. alternatives like send_text. There is no mention of prerequisites, limitations, or when not to use the tool.
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 texto no WhatsApp.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Texto da mensagem. | |
| number | Yes | Numero de destino com DDI e DDD, so digitos. Ex: 5511999999999 | |
| instance | No | Nome da instancia (omita se so houver um numero). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden but only states the basic function. It does not disclose error handling, validation, rate limits, or whether the instance parameter is required for multi-number setups. The minimal description leaves behavioral properties unknown.
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?
A single, short sentence conveys the core purpose without any extraneous information. It is appropriately sized for a simple tool.
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 simplicity and the presence of sibling tools, the description is adequate but minimal. It lacks details on return values or error scenarios, and does not explicitly state limitations (e.g., text-only). Could be improved with a note about unsupported media types.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no extra meaning beyond the schema's brief parameter descriptions (e.g., number format, instance optionality). It does not enhance understanding beyond what the schema already provides.
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 text message on WhatsApp, effectively distinguishing from sibling tools like send_media or send_poll. However, it does not explicitly differentiate from other message types, but the verb and resource are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., send_media for images, send_poll for polls). The description lacks context about prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Configura o webhook de uma instancia para receber mensagens no seu endpoint (para chatbots).
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL do seu endpoint. | |
| enabled | No | ||
| instance | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states 'configures' but does not clarify whether it creates, updates, or deletes, nor does it mention side effects like overwriting existing webhooks or authentication requirements.
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, front-loaded with the purpose. It is concise but lacks detail that could be structured into a slightly longer paragraph. Not overly verbose, but could be more informative without losing conciseness.
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 three parameters, no output schema, and no annotations, the description is insufficient. It does not explain the return value, behavior when disabled, or error conditions, leaving a knowledgeable agent with ambiguous usage.
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?
Out of three parameters, only 'url' has a description in the schema. The description adds no extra meaning beyond the schema, leaving 'enabled' and 'instance' undocumented. With 33% schema coverage, the description fails to compensate.
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 configures a webhook for an instance to receive messages for chatbots. It uses a specific verb ('configures') and resource ('webhook of an instance'), and the purpose is distinct from sibling tools which focus on campaigns, contacts, and sending messages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives or any prerequisites. The description implies it is for chatbot message reception, but lacks explicit context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cria ou atualiza um contato.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| tags | No | ||
| number | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the operation type. It does not disclose what happens when a contact with the same number exists (update) or not (create), or any side effects or permissions needed.
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 short (four words in Portuguese). While brief, it sacrifices necessary detail; it is under-specified rather than efficiently concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool performs an upsert but no output schema is present, and the description does not explain return values, error states, or behavior on duplicates. This is insufficient for correct 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?
Schema description coverage is 0%, yet the description adds no detail about the parameters (name, tags, number). For an upsert tool, explaining that 'number' is the identifier is critical but missing.
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 action (cria ou atualiza) and resource (contato), indicating an upsert operation. However, it does not differentiate from sibling tools like list_contacts, but the unique verb 'upsert' distinguishes it sufficiently.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., when to create vs update, or using other contact-related tools). The description lacks context for decision-making.
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.
v0.1.0campaign_statuscheck_numberscreate_campaignlist_contactslist_instancessend_mediasend_pixsend_pollsend_textset_webhookupsert_contactScored across 11 tools
Each tool has a clearly distinct purpose: campaign management, message sending, contact operations, instance configuration, and number validation. There is no ambiguity between them.
All tool names follow a consistent verb_noun pattern with underscores (e.g., send_text, create_campaign, list_contacts), making them predictable and easy to understand.
11 tools are well-scoped for a WhatsApp messaging and campaign management server, covering core operations without unnecessary bloat.
The tool set covers most essential operations: sending various message types, contact management, instance listing, webhook setup, and campaign creation/status. Minor gaps exist (e.g., no campaign update/delete or contact deletion), but agents can work around them.
Unified messaging MCP server: WhatsApp, Instagram, Telegram, SMS, Messenger & email support inbox
Drive WhatsApp from any MCP client: pair devices, send text and media, manage contacts and groups.
The Mercado Pago MCP Server implements the Model Context Protocol to provide AI agents and LLMs with access to Mercado Pago's APIs and tools within compatible development environments. It acts as an intermediary that translates Mercado Pago resources into executable functions (tools) that AI applications can invoke to perform actions and automate flows. The server simplifies integration, enables using documentation to implement or improve code, and optimizes operations through natural language interactions without manual implementations.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
