The WhatsApp Web MCP server allows agents to interact with WhatsApp Web programmatically via browser automation, enabling reading, searching, exporting, and sending messages. Key capabilities include:
Session Management: Open/close browser sessions in headless or headed mode, capture QR codes for login, and configure browser policies (whatsapp_browser_open, whatsapp_browser_close, whatsapp_browser_policy).
Chat & Contact Discovery: List and search contacts/chats directly from the WhatsApp Web DOM — no SQLite or IndexedDB access required (whatsapp_find_contacts, whatsapp_select_context).
Message Reading & Search: Retrieve recent messages, browse history, and search by text, message type, and date/time range. View chat structure grouped by day or hour (whatsapp_search_messages, whatsapp_chat_structure).
Export: Export full conversations to JSON, including media and transcriptions (whatsapp_export_conversation).
Media Capture & Transcription: Capture images, stickers, GIFs, audio, video, and documents from messages. Transcribe audio/video using WhisperX with optional speaker diarization, supporting WAV, MP3, M4A, OGG, OPUS, FLAC, WebM, MP4, MOV, MKV, and AVI formats (whatsapp_transcribe_file).
Sending Messages (Two-Step Confirmation): Prepare a text message or document (returns a token/preview without sending), then explicitly confirm to dispatch. Probe media attachment or reply-to mode without actually sending (whatsapp_prepare_send_message, whatsapp_confirm_send_message, whatsapp_probe_send_media, whatsapp_probe_reply_to_message).
Status & Capabilities: Check server capabilities, supported formats, and browser runtime status (whatsapp_capabilities, whatsapp_browser_runtime_status).
Key design principles: All reads and exports never send messages. Sending always requires a two-step prepare → confirm flow. The server operates entirely via the rendered DOM with no direct database access, and supports auto-recovery with persistent profiles.
Allows agents to search, structure, and export authorized WhatsApp Web conversations, including media transcription and message sending with confirmation.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@WhatsApp Web MCP search for 'invoice' in my chat with John"
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 de domínio para agentes consultarem e exportarem conversas autorizadas do WhatsApp Web. O cliente pede chats, mensagens, mídia, transcrições ou ações; sessão, busca, seleção, scroll e recuperação ficam encapsulados no servidor.
Projeto independente e não oficial. Não é afiliado ao WhatsApp ou à Meta. Use somente em contas e conversas que você tem autorização para acessar.
Perfil persistente default, headless por padrão.
observe=true para mostrar somente a operação atual.
Busca e leitura pelo DOM renderizado, sem SQLite ou IndexedDB local.
Mensagens recentes sempre reposicionadas no fim da conversa.
Histórico e pesquisa paginados por cursor opaco.
Texto, direção, participante, reply, forwarded e tipo de mídia em JSON.
Captura de mídia pelo message_id; associações incertas ficam separadas.
Transcrição de áudio e vídeo exclusivamente com WhisperX.
Export persistente com mensagens, replies, mídia e transcrições.
Autorrecuperação com uma única reinicialização no mesmo perfil.
Envios protegidos por intenção explícita, preview e confirmação literal.
Related MCP server: WhatsApp MCP Server
O servidor publica somente estas ferramentas:
whatsapp_status
whatsapp_list_chats
whatsapp_get_messages
whatsapp_get_media
whatsapp_export_chat
whatsapp_transcribe_file
whatsapp_prepare_action
whatsapp_confirm_action
whatsapp_action_status
Todas recebem um objeto request. Parâmetros de navegador, sessão, seletores,
scroll e Playwright não fazem parte da API.
{
"request": {
"selector": "Troco Solidário - Anotações",
"mode": "recent",
"limit": 50
}
}selector aceita string ou objeto com title, query, phone e jid.
Depois de whatsapp_list_chats, prefira o chat_id retornado.
{
"request": {
"chat_id": "chat_...",
"mode": "search",
"query": "contrato",
"message_types": ["text", "document", "audio"],
"date_from": "2026-06-01",
"date_to": "2026-06-13",
"limit": 100,
"cursor": "cur_..."
}
}Modos disponíveis: recent, history e search. A resposta inclui
latest_boundary_verified, métricas de paginação e next_cursor.
{
"request": {
"chat_id": "chat_...",
"message_id": "3EB0...",
"transcribe": true,
"diarize": false
}
}Áudio e vídeo podem ser transcritos com WhisperX. Imagens, stickers, GIFs e documentos retornam o caminho do arquivo capturado.
{
"request": {
"chat_id": "chat_...",
"mode": "recent",
"limit": 10,
"observe": true
}
}O override vale somente para essa chamada. A sessão volta ao modo headless ao terminar.
Recurso | Estado |
Listar e localizar chats | Suportado |
Ler recente, histórico e pesquisa | Suportado |
Exportar JSON | Suportado |
Capturar imagem, sticker e mídia renderizada | Suportado |
Capturar/transcrever áudio e vídeo | Suportado quando a mídia e o WhisperX estão disponíveis |
Enviar texto | Verificado, sempre com confirmação |
Enviar documento, incluindo | Verificado, sempre com confirmação |
Enviar outras mídias, reply ou encaminhamento | Bloqueado até smoke confirmado específico |
SQLite/IndexedDB local | Não utilizado |
Requisitos: Python 3.11 ou 3.12, Chrome/Chromium e FFmpeg.
git clone https://github.com/KingDonRush/whatsapp-web-mcp.git
cd whatsapp-web-mcp
python3 -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip
python -m pip install -e .
python -m playwright install chromiumO servidor usa transporte MCP stdio:
whatsapp-web-mcp{
"mcpServers": {
"whatsapp-web": {
"command": "/absolute/path/whatsapp-web-mcp/.venv/bin/whatsapp-web-mcp",
"args": [],
"env": {
"WHATSAPP_MCP_DATA_DIR": "/absolute/persistent/path/whatsapp-web-mcp"
}
}
}
}Exemplo para Codex:
[mcp_servers.whatsapp-web]
command = "/absolute/path/whatsapp-web-mcp/.venv/bin/whatsapp-web-mcp"
enabled = true
startup_timeout_sec = 30.0
[mcp_servers.whatsapp-web.env]
WHATSAPP_MCP_DATA_DIR = "/absolute/persistent/path/whatsapp-web-mcp"Comece com whatsapp_status. Se a conta não estiver autenticada, a resposta
será login_required com um qr_artifact. Depois do login, o perfil
persistente default será reutilizado.
O envio é sempre uma operação em duas etapas:
whatsapp_prepare_action exige ordem explícita do usuário e retorna preview,
action_id e a frase exata de confirmação.
whatsapp_confirm_action só despacha com
CONFIRMO ENVIAR <action_id> e user_confirmed=true.
Exemplo:
{
"request": {
"type": "send_document",
"chat_id": "chat_...",
"file_path": "/absolute/arquivo.zip",
"caption": "Entrega",
"user_order_text": "Envie este arquivo para o grupo"
}
}Leituras e exports nunca enviam mensagens. A confirmação é consumida atomicamente após sucesso para impedir replay.
python -m pip install -e '.[transcription]'Ou configure uma venv separada:
python3.11 -m venv .venv-whisperx
.venv-whisperx/bin/pip install whisperx
export WHISPERX_PYTHON="$PWD/.venv-whisperx/bin/python"Formatos aceitos incluem os formatos de áudio definidos pelo FFmpeg/WhisperX
como WAV, MP3, M4A, OGG, OPUS, FLAC e WebM, além de vídeos como MP4, MOV, MKV,
AVI e WebM. Vídeos têm o áudio extraído antes da transcrição. Diarização usa
diarize=true e pode receber min_speakers e max_speakers.
docker build -t whatsapp-web-mcp .
mkdir -p runtime
sudo chown -R 10001:10001 runtime
docker run --rm -i -v "$PWD/runtime:/data" whatsapp-web-mcpEm VPS, execute o servidor atrás de um harness autenticado ou por SSH stdio.
Não exponha o processo diretamente à internet. O volume persistente deve
proteger o perfil autenticado, exports e ações pendentes.
WHATSAPP_MCP_DATA_DIR/
├── state/
│ ├── browser-profiles/default/
│ └── domain/
└── exports/Nunca publique state/, exports/, QR codes, transcrições, tokens ou arquivos
de mídia. O .gitignore também exclui node_modules/, ambientes locais e
arquivos .env.
Variáveis principais:
Variável | Uso |
| Raiz de estado e exports |
| Override do estado |
| Override dos exports |
| Chrome/Chromium específico |
| Executável FFmpeg |
| Python com WhisperX |
| Cache dos modelos |
| Token opcional para diarização |
python -m unittest discover -s tests -v
python -m compileall server.py whatsapp_web_mcp testsLicença MIT. Consulte SECURITY.md antes de hospedar uma instância autenticada.
Planeja busca automatizada por DOM/acessibilidade em WhatsApp Web.
| Name | Required | Description | Default |
|---|---|---|---|
| contact_query | No | ||
| message_query | No | ||
| source_ids | No | ||
| date_from | No | ||
| date_to | No | ||
| message_types | No | ||
| browser_mode | No | ||
| login_mode | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It only mentions planning a search but does not describe side effects, required permissions, or what the tool actually does beyond planning.
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) but lacks substance. It is not effectively informative; brevity does not compensate for vagueness.
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 eight parameters, no schema descriptions, no annotations, and an output schema existing, the description fails to provide necessary context about inputs, outputs, or behavior, leaving significant gaps.
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%, and the description adds no information about parameters. The eight parameters remain unexplained, leaving the agent to rely solely on names, which may be insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it plans automated search by DOM/accessibility in WhatsApp Web, which gives a verb and resource. However, it is vague and does not clearly differentiate from the sibling tool 'whatsapp_search_messages', leaving ambiguity about what 'plan' entails.
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 like 'whatsapp_search_messages' or others. There is no explanation of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fecha uma sessao Playwright aberta pelo MCP.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | No | default |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states 'closes'. It does not disclose side effects, whether operations are safe to repeat, or if any state is saved. For a destructive action, this is 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 extremely concise (one short sentence), but this is under-specification rather than efficiency. It does not earn its place as it omits critical 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?
Given the tool's simplicity and presence of an output schema, the description could be slightly more complete. It lacks clarity on return values or success indication, and no output schema details are shown to compensate.
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%, and the description does not explain the session_id parameter, its default value, or behavior. The agent cannot determine how to use the parameter without additional context.
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 'Closes a Playwright session opened by the MCP' clearly states the action (closes) and resource (Playwright session), distinguishing it from siblings like whatsapp_browser_open. However, it is in Portuguese, which may cause slight ambiguity, and lacks explicit mention of the session type.
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 guidance is provided. The description does not indicate when to use this tool (e.g., after using whatsapp_browser_open) or when not to, and offers no alternatives or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Abre WhatsApp Web via Playwright em modo headless/headed e retorna screenshot/QR quando solicitado.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | login | |
| process | No | web_login | |
| browser_mode | No | ||
| login_mode | No | ||
| session_id | No | default | |
| capture_qr | No | ||
| force_restart | No | ||
| timeout_ms | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses headless/headed mode and return of screenshot/QR. However, it omits side effects, session management, and destructive potential (e.g., force_restart). Some behavior is implied but not explicit.
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-loads the main action. However, it lacks structure to accommodate parameter details or additional 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 complexity of 8 unannotated parameters and existence of an output schema, the description only covers high-level opening and output. It does not explain how parameters shape behavior or how the tool fits into the broader WhatsApp browser workflow.
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?
Parameter coverage in schema is 0% and the description adds no parameter explanations. The agent must infer from names alone (e.g., capture_qr, force_restart). The mention of 'QR' loosely maps to capture_qr but is insufficient.
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 opens WhatsApp Web via Playwright in headless/headed mode and returns screenshot/QR. It identifies the verb and resource, but does not differentiate from siblings like whatsapp_browser_set_policy or other browser tools.
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. Missing prerequisites, context, or exclusions despite 8 parameters and sibling tools that imply a workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve politica headless/headed para uma operacao sem persistir overrides.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | ||
| process | No | ||
| browser_mode | No | ||
| login_mode | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions 'without persisting overrides', a key behavioral trait, but fails to disclose whether it is read-only, authentication requirements, rate limits, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise but lacking structure. It does not follow a clear verb-object pattern and is under-specified for the tool's 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 the tool has 4 undocumented parameters, no annotations, and an output schema with no description, the one-sentence description is severely incomplete. It fails to explain what the tool returns or how to use the parameters effectively.
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%, and the description adds no meaning to the four parameters (category, process, browser_mode, login_mode). The description vaguely references browser_mode but ignores the others.
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 resolves headless/headed policy for an operation without persisting overrides, distinguishing it from sibling 'whatsapp_set_browser_policy' which likely sets policies. However, 'resolve' is ambiguous (determine? retrieve?) and lacks specificity.
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 like 'whatsapp_set_browser_policy'. The description does not indicate prerequisites, context, or excluded scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mostra disponibilidade de Playwright/Chrome e sessoes de browser abertas.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose all behavioral traits. It correctly identifies the tool as a read-only status check but does not mention any potential side effects, authentication needs, or operational constraints.
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, efficient sentence that conveys the tool's purpose without any fluff. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists (though not shown), the description is sufficient to convey its basic function. However, it lacks context on typical usage scenarios or expected output structure beyond what the schema provides.
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?
Tool has zero parameters, so baseline is 4. Description does not need to add parameter information beyond the schema, which is already complete (100% 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 shows availability of Playwright/Chrome and open browser sessions, using a specific verb ('mostra') and resource ('disponibilidade... e sessoes de browser abertas'). It is clearly distinguishable from sibling tools that open, close, or set policies.
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 explicit guidance on when to use this vs. alternatives (e.g., before opening or closing a browser). The usage is implied but not stated, leaving the agent without clear decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mostra caminhos, formatos e backends suportados por este MCP.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It indicates a read-only query ('Mostra'), but does not explicitly state that it has no side effects, requires no permissions, or is safe. The implied behavior is clear, but not fully transparent.
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, brief sentence that perfectly captures the tool's function without any wasted words. It is front-loaded and efficient.
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 an output schema to document return values and no parameters, the description is complete enough. It succinctly explains what capabilities are shown, which is appropriate for a discovery 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?
There are zero parameters, so baseline 4 is appropriate. Schema coverage is 100% (empty), and the description does not need to add parameter semantics since none exist.
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 that the tool shows supported paths, formats, and backends, using a specific verb ('Mostra') and resource ('caminhos, formatos e backends'). It distinguishes from siblings like search, send, or export tools by focusing on capabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for discovering supported features before using other tools, but it lacks explicit when-to-use or when-not-to-use guidance, and no alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mostra estrutura do chat por dia/hora usando mensagens renderizadas no WhatsApp Web.
| Name | Required | Description | Default |
|---|---|---|---|
| contact_name | No | ||
| phone | No | ||
| jid | No | ||
| query | No | ||
| message_types | No | ||
| date_from | No | ||
| date_to | No | ||
| hour_from | No | ||
| hour_to | No | ||
| group_by | No | day | |
| limit | No | ||
| scroll_pages | No | ||
| max_scroll_pages | No | ||
| browser_mode | No | ||
| login_mode | No | reuse_session | |
| session_id | No | default |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions rendered messages, implying a live browser, but does not disclose that scrolling may occur, that the tool modifies page state, or what the output structure is. The output schema exists but is not described.
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 with no extra text, which is concise. However, it is too brief to be helpful, sacrificing necessary details for brevity. The Portuguese language may also be a minor barrier for English-centric agents.
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 tool with 16 optional parameters and no schema descriptions, the description is severely incomplete. It does not cover how filtering, grouping, or output works, and the output schema alone cannot compensate for the lack of behavioral and usage context.
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%. The description adds no meaning to any of the 16 parameters. Important fields like contact_name, date ranges, and scrolling options are not explained, leaving the agent to rely solely on parameter names and defaults.
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 uses a specific verb ('Mostra' = shows) and resource ('estrutura do chat'), and the mention of grouping by day/hour provides clear purpose. It distinguishes from siblings like search_messages or export_conversation, though 'estrutura' is somewhat vague.
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 guidance is provided. The description does not state when to use this tool instead of alternatives (e.g., search_messages), nor does it mention prerequisites like an open browser session, which is implied by 'renderizadas no WhatsApp Web'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Confirma uma mensagem preparada. Nao despacha sem backend Web/UI verificado.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | ||
| confirmation_text | Yes | ||
| user_already_confirmed | No | ||
| dispatch | No | ||
| browser_mode | No | ||
| login_mode | No | ||
| dispatch_timeout_seconds | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses one behavioral trait: it does not dispatch without verified Web/UI backend. However, it does not explain other behaviors such as error handling, side effects, or permission requirements. Since no annotations are provided, this partial disclosure is mediocre.
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 at two sentences, but it is overly brief, sacrificing necessary detail. It could structure the information better by separating purpose from constraints.
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 (7 parameters, no schema descriptions, no annotations, output schema exists but undocumented), the description is insufficient. It provides only a basic purpose and one constraint, leaving many aspects (parameter semantics, return value, prerequisites) unexplained.
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 input schema. With 0% schema description coverage, the description should explain key parameters like 'token', 'confirmation_text', and 'dispatch'. It fails to do so, leaving the agent to guess their roles.
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's action: 'confirma uma mensagem preparada' (confirms a prepared message). It distinguishes the tool from siblings like 'whatsapp_prepare_send_message' by specifying the confirmation step. The second sentence adds a constraint but does not detract from purpose 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 no guidance on when to use this tool versus alternatives like 'whatsapp_prepare_send_message' or 'whatsapp_probe_reply_to_message'. The warning about not dispatching without verified backend is a condition, not a usage comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Exporta conversa renderizada do WhatsApp Web para JSON, com midia/transcricao quando possivel.
| Name | Required | Description | Default |
|---|---|---|---|
| contact_name | No | ||
| phone | No | ||
| jid | No | ||
| query | No | ||
| message_types | No | ||
| date_from | No | ||
| date_to | No | ||
| hour_from | No | ||
| hour_to | No | ||
| limit | No | ||
| scroll_pages | No | ||
| max_scroll_pages | No | ||
| out_dir | No | ||
| download_media | No | ||
| transcribe | No | ||
| diarize | No | ||
| min_speakers | No | ||
| max_speakers | No | ||
| transcription_language | No | portuguese | |
| whisperx_device | No | auto | |
| whisperx_compute_type | No | auto | |
| browser_mode | No | ||
| login_mode | No | reuse_session | |
| session_id | No | default |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behaviors. It mentions 'rendered conversation' and 'when possible' for media/transcription, but fails to describe side effects, required permissions, scrolling behavior, or error handling. This is insufficient for a complex tool.
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. However, it omits crucial details that would justify its brevity; for a tool with 24 parameters, more structure and explanation is needed.
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 (24 parameters, no annotations, no parameter descriptions), the one-sentence description is severely incomplete. It does not explain output schema, usage constraints, or parameter interactions, leaving the agent underinformed.
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 information about any of the 24 parameters. All parameters remain undocumented, forcing the agent to rely solely on parameter names, which is inadequate for correct invocation.
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 exports a WhatsApp Web conversation to JSON format with optional media/transcription. It uses a specific verb ('exporta') and resource ('conversa renderizada'), distinguishing it from other sibling tools like search or send.
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 explicit guidance on when to use this tool vs alternatives is provided. The description implies usage for exporting conversations, but lacks prerequisites or exclusion criteria, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lista ou procura contatos/chats pelo WhatsApp Web DOM, sem SQLite.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | ||
| name | No | ||
| phone | No | ||
| jid | No | ||
| include_all | No | ||
| limit | No | ||
| browser_mode | No | ||
| login_mode | No | reuse_session | |
| session_id | No | default |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'via WhatsApp Web DOM, sem SQLite,' indicating a read operation via DOM, but does not disclose if the tool is read-only, requires authentication, or has side effects. The behavioral context is 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, which is concise, but it is in Portuguese and lacks structure. It front-loads the purpose but cannot cover the tool's complexity. Every word earns its place, but the content is insufficient.
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 9 parameters, no annotations, 0% schema description coverage, and an output schema not shown, the description is extremely incomplete. It provides no context about parameter relationships, expected behavior, or error scenarios.
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%, and the description adds no information about the 9 parameters. The AI agent must guess meanings from parameter names, some of which are non-obvious (e.g., browser_mode, login_mode, session_id). No default values are explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Lista ou procura' (lists or searches) and the resource 'contatos/chats' (contacts/chats). It is clear about the action and resource, but the use of Portuguese may confuse an English-language AI. It does not distinguish from siblings like 'whatsapp_search_messages', but the resource (contacts vs messages) provides some differentiation.
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. There is no mention of preconditions, such as needing an active WhatsApp Web session, or when to use other tools like 'whatsapp_search_messages' or 'whatsapp_browser_open'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prepara envio de texto/midia, mas nao envia. Retorna token que exige confirmacao explicita.
| Name | Required | Description | Default |
|---|---|---|---|
| recipient_name | No | ||
| recipient_phone | No | ||
| recipient_jid | No | ||
| message_text | No | ||
| send_items | No | ||
| user_order_text | No | ||
| browser_mode | No | ||
| login_mode | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it does not send and returns a token, indicating non-destructive behavior. However, it does not disclose any side effects, prerequisites, or authorization needs.
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 very concise with two sentences that front-load the key behavior. It could be slightly expanded to cover parameter usage 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 8 parameters and no schema description, the description is insufficient. It does not explain the two-step workflow, how to use the returned token, or how to choose between the many optional parameters. The output schema might cover the token, but the input side is neglected.
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 provides no explanation of any of the 8 parameters. It only mentions 'text/media' which loosely maps to message_text and send_items, but no details on how to specify recipients or other fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool prepares sending text/media but does not send, and returns a token requiring confirmation. This distinguishes it from the sibling 'whatsapp_confirm_send_message', which is the subsequent step.
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 it is a preparation step before confirmation, but does not explicitly state when to use it versus other siblings like 'whatsapp_probe_send_media' or 'whatsapp_probe_reply_to_message'. The two-step workflow is clear though.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Entra no modo resposta nativo do WhatsApp Web e cancela sem enviar.
| Name | Required | Description | Default |
|---|---|---|---|
| recipient_name | No | ||
| recipient_phone | No | ||
| recipient_jid | No | ||
| reply_to | No | ||
| browser_mode | No | ||
| login_mode | No | reuse_session | |
| session_id | No | default | |
| timeout_ms | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the core behavior: entering reply mode and canceling without sending. However, without annotations, it does not detail potential side effects, error handling, or output. The behavioral transparency is minimal.
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, making it concise. However, it is too brief to be informative; conciseness is achieved at the expense of completeness.
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 8 parameters and no output schema shown in the definition, the description is incomplete. It does not clarify how parameters affect behavior or what the probe returns.
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 does not explain any of the 8 parameters (e.g., recipient_name, reply_to, browser_mode). With 0% schema description coverage, the description fails to add meaning to the input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool enters the native reply mode of WhatsApp Web and cancels without sending. It identifies a specific verb ('enter') and resource ('reply mode'), but does not differentiate from sibling tools like whatsapp_probe_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?
No guidance is provided on when to use this tool versus alternatives such as whatsapp_prepare_send_message or whatsapp_confirm_send_message. The description lacks context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Anexa uma midia ate o preview e fecha sem enviar. Usado para validar Web UI por tipo.
| Name | Required | Description | Default |
|---|---|---|---|
| recipient_name | No | ||
| recipient_phone | No | ||
| recipient_jid | No | ||
| send_item | No | ||
| browser_mode | No | ||
| login_mode | No | reuse_session | |
| session_id | No | default | |
| timeout_ms | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behavioral traits: attaches media, previews, then closes without sending. No annotations exist, so description carries full burden. It does not mention authentication needs or rate limits, but for a probe tool, the core behavior is transparent.
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?
Extremely concise single sentence with no wasted words. However, the structure could be improved with explicit separation of purpose and usage. Portuguese language may hinder some agents.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description does not mention return values or behavior. With 8 parameters and no annotations, the description is insufficient for an agent to correctly invoke the tool without additional context.
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%. The description provides no explanation of the 8 parameters, their defaults, or how they affect behavior. This leaves the agent with no additional meaning beyond the bare 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 attaches media, shows preview, and closes without sending, and is used for Web UI validation. It distinguishes from sending tools like whatsapp_confirm_send_message. However, the Portuguese phrasing may reduce clarity for non-Portuguese agents.
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?
Implied usage for validation of Web UI by type, but no explicit guidance on when to use vs alternatives or when not to use. No exclusions or alternative tools mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Busca mensagens renderizadas no WhatsApp Web por contato, texto, tipo e intervalo.
| Name | Required | Description | Default |
|---|---|---|---|
| contact_name | No | ||
| phone | No | ||
| jid | No | ||
| query | No | ||
| message_types | No | ||
| date_from | No | ||
| date_to | No | ||
| hour_from | No | ||
| hour_to | No | ||
| limit | No | ||
| scroll_pages | No | ||
| max_scroll_pages | No | ||
| browser_mode | No | ||
| login_mode | No | reuse_session | |
| session_id | No | default |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions it searches 'rendered messages' but does not disclose behavioral traits like the need for an active browser session, login mode, or that scrolling is involved. Since no annotations are provided, the description carries full burden and fails to explain side effects or operational constraints.
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 with no wasted words. However, given the tool's complexity, it could be expanded 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?
Despite having an output schema, the description is incomplete for a tool with 15 parameters and no schema descriptions. It fails to explain the search workflow, pagination, session handling, or how parameters interact, leaving significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should explain parameter meanings. It only lists filter dimensions (contact, text, type, range) but does not clarify individual parameters such as 'jid', 'scroll_pages', 'browser_mode', or 'login_mode', leaving their usage ambiguous.
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 searches rendered WhatsApp Web messages by contact, text, type, and time range. It uses a specific verb ('Busca') and resource ('mensagens renderizadas no WhatsApp Web'), and distinguishes it from sibling tools like 'whatsapp_automated_search_plan'.
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. The description only states what it does, without indicating prerequisites or context where other tools might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Seleciona contato/conversa pelo WhatsApp Web DOM.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | ||
| name | No | ||
| phone | No | ||
| jid | No | ||
| message_query | No | ||
| limit | No | ||
| browser_mode | No | ||
| login_mode | No | reuse_session | |
| session_id | No | default |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only mentions DOM interaction, leaving out important traits such as destructiveness, authentication needs, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one sentence), but it is under-specified and fails to convey essential information. Conciseness is not valuable when it sacrifices completeness.
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 (9 parameters, no schema descriptions, existing output schema), the description is grossly incomplete. It does not explain return values, parameter semantics, or usage patterns.
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%, and the description provides no details about the 9 parameters (query, name, phone, jid, etc.). The agent cannot infer how to use these parameters correctly from the description alone.
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 selects a contact or conversation via the WhatsApp Web DOM, which is a specific verb and resource. However, it does not differentiate from sibling tools like find_contacts or search_messages, which may have overlapping functionality.
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 given on when to use this tool versus alternatives. The description lacks context for an AI agent to decide between this and other messaging-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Persiste default headless/headed global, por categoria, ou por processo dentro da categoria.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | ||
| process | No | ||
| browser_mode | No | ||
| login_mode | No | ||
| reset | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only mentions 'persists default' without disclosing if the operation is destructive, requires permissions, or has side effects. It does not describe what happens to existing policies on reset.
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 very short (one sentence) and front-loaded with key action, but it is cryptic and in Portuguese, which may hinder understanding. It could be better structured with parameter details.
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 annotations, 5 parameters with no schema descriptions, and an output schema that is not referenced, the description is grossly incomplete. It fails to cover return values, parameter details, or behavioral traits.
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 0%, so the description must compensate. It hints at parameters (global, category, process) but does not clarify valid values for 'browser_mode' or 'login_mode', nor does it explain the 'reset' parameter beyond its name.
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 that the tool persists a default browser mode (headless/headed) at global, category, or process level. However, it does not differentiate from the sibling tool 'whatsapp_browser_policy', which likely reads the policy.
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 like 'whatsapp_browser_policy' (likely a read operation). There are no when-to-use or when-not-to-use cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mostra fontes disponiveis. Apenas WhatsApp Web e anunciado.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description only states the basic operation without disclosing potential side effects, data access patterns, or error conditions.
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 with one sentence. However, it lacks structure (e.g., bullet points or sections) and could benefit from more detail without being 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?
Despite having an output schema, the description does not explain what the tool returns (e.g., list of sources, format). It only mentions that only WhatsApp Web is announced, which is incomplete for an agent to understand the output.
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 no parameters, so the description does not need to add parameter information. The schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it shows available sources, but does not define what 'sources' means in this context, and does not distinguish from sibling tools like whatsapp_capabilities or whatsapp_chat_structure.
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, no context on expected outcomes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Transcreve arquivo manualmente com WhisperX, incluindo video via audio extraido.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | ||
| out_dir | No | ||
| backend | No | whisperx | |
| language | No | portuguese | |
| diarize | No | ||
| min_speakers | No | ||
| max_speakers | No | ||
| prepare | No | ||
| force_prepare | No | ||
| whisperx_model | No | large-v3 | |
| whisperx_device | No | auto | |
| whisperx_compute_type | No | auto | |
| timeout_seconds | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 indicates that transcription is 'manual' and that video is handled via audio extraction, but does not mention whether the tool modifies files, its destructive potential, permission requirements, or failure modes. Many important behaviors are left unspecified.
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 with no extraneous words, making it concise. However, it lacks any structure (e.g., sections, lists) and is so minimal that it sacrifices clarity for brevity. It earns its place but does not add much value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 13 parameters, 0% schema description coverage, and no annotations, the description is severely incomplete. It does not explain what the tool returns (despite an output schema existing), how parameters interact, or any important constraints like timeouts. The description provides insufficient context for an AI agent to use the tool effectively.
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% for 13 parameters, yet the description adds zero explanation about any parameter. It does not clarify what 'prepare', 'diarize', 'backend', or other parameters mean or affect. The description completely fails to compensate for the lack of 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 transcribes files manually using WhisperX, and specifically mentions handling video via extracted audio. This provides a good verb-resource pairing and distinguishes from sibling tools that are about browser operations or message sending. However, it does not explicitly differentiate from potential other transcription tools.
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. The description does not mention prerequisites, typical use cases, or when not to use it. Sibling tools are listed but no comparisons are made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a distinct purpose, from browser management to message preparation and confirmation. The 'probe' tools simulate actions without sending, clearly differentiating from actual send operations. There is no ambiguity between tools.
All tools share the 'whatsapp_' prefix, and most follow a verb_noun pattern (e.g., export_conversation, find_contacts). A few tools use noun phrases (e.g., whatsapp_automated_search_plan, whatsapp_capabilities) but the overall pattern is predictable and readable.
With 18 tools, the server covers a broad but scoped domain of WhatsApp Web automation. Each tool has a clear role, from browser lifecycle to message handling and media probing. The number is reasonable and not excessive.
The tool set covers core workflows: browser control, contact/chat selection, message sending (with prepare and confirm), search, structure, and media transcription. Minor gaps like direct read without search are acceptable given the automated interaction focus.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Drive WhatsApp from any MCP client: pair devices, send text and media, manage contacts and groups.
Unified inbox MCP for WhatsApp, Telegram, Email, voice — read/send messages, search, AI agents.
Managed LinkedIn MCP server for AI agents: search, connect, message and enrich on accounts you own.
WhatsApp (Web + Business API), SMS, contacts, and call records via 2Chat's MCP server.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/KingDonRush/whatsapp-web-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
