This server provides a local MCP interface for interacting with WhatsApp Web through Playwright, including reading chats, searching messages, exporting conversations, preparing/confirming sends, managing browser sessions, and transcribing media.
Browser/session management: open/close WhatsApp Web via Playwright, check runtime status, and set or resolve headless/headed browser policies.
Discovery and search: find contacts/chats by name, phone, JID, or query; search rendered messages by text, type, contact, date/time range, and scrolling limits.
Conversation inspection: view chat structure grouped by day/hour, inspect message details, and export rendered conversations to JSON with optional media download, transcription, and diarization.
Media processing: transcribe audio/video files manually with WhisperX, with language, model, device, and compute-type options.
Sending workflow: prepare outgoing text/media messages for a preview and token, then explicitly confirm dispatch; probe media attachment or reply-to mode without actually sending.
Capability discovery: list supported sources, paths, formats, and backends via whatsapp_capabilities and whatsapp_sources.
Allows agents to search, structure, and export authorized WhatsApp Web conversations, including media transcription and message sending with confirmation.
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., "@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.
A local MCP server for reading authorized WhatsApp conversations, retrieving media, exporting bounded history and preparing confirmation-gated messages. Its 13 typed tools expose chats and messages rather than browser controls. OpenWA owns the WhatsApp Web connection; optional local processors handle audio, images and documents.
For a known conversation, call whatsapp_get_messages directly. Use
whatsapp_find to discover a contact or search within a specified conversation.
History exports include coverage information: a partial result is identified as
partial, with its stopping condition, rather than presented as a complete archive.
Sending is a separate stateful operation. whatsapp_send_message prepares a
preview, target and action ID. Confirmation requires the literal phrase returned
by that preview and the user's explicit instruction. An action is claimed once.
After dispatch, the server reloads the message before reporting sent: true.
An ambiguous result consumes the action and returns delivery_unconfirmed;
it is not retried automatically. Reloading proves that the backend can retrieve
the outgoing message, not that its recipient has read it.
Related MCP server: WhatsApp MCP Server
Purpose | Tools |
Connection and discovery |
|
Identity and context |
|
Conversation content |
|
Media |
|
State and actions |
|
Each tool accepts a typed request object. Public identifiers hide backend JIDs
and session configuration. See request models
and tool registration for the current contract.
Requires Python 3.11+, Node.js/npm and a Chrome/Chromium installation for OpenWA.
FFmpeg and the transcription extra support audio/video; Tesseract, Poppler and
LibreOffice support applicable OCR/document formats.
git clone https://github.com/KingDonRush/whatsapp-web-mcp.git
cd whatsapp-web-mcp
python3 -m venv .venv
. .venv/bin/activate
python -m pip install -e .
whatsapp-web-mcp doctor
whatsapp-web-mcp auth --profile default
whatsapp-web-mcp serveAuthentication installs exactly @open-wa/wa-automate@4.76.0 in the private data
directory and applies the compatibility patches in
openwa_runtime.py. Authentication displays
a local QR page; the MCP does not return the QR. Subsequent operations are headless.
Use auth --no-open when the browser must be opened separately in a secure local
or tunneled environment. Keep the OpenWA HTTP service on loopback.
Configure an MCP client to run the virtual environment's whatsapp-web-mcp executable
with args: ["serve"]. Set WHATSAPP_MCP_DATA_DIR to an absolute persistent
private directory and WHATSAPP_MCP_PROFILE to the intended profile before starting.
The default data directory is ~/.local/share/whatsapp-web-mcp.
Read the newest audio or voice note from a known chat:
{"request":{"chat_id":"c_12345678","types":["audio"],"period":"últimos 7 dias","limit":1}}Pass its returned message_id to whatsapp_understand to fetch the original media
and process it. Date expressions accept ISO dates and supported Brazilian Portuguese
periods; see date parsing. Tool prompts and natural
period parsing currently favor Portuguese, while the transport and schemas are language independent.
Export an explicitly selected conversation:
{"request":{"selector":"Example project group","period":"março de 2026"}}The stdio entry point delegates to domain services. OpenWA access, history loading, media processing, artifact generation, ID registration and action persistence have separate modules. JSON records use private atomic writes; action claims use atomic renames to prevent duplicate dispatch. Path-bearing action/job identifiers are validated before accessing local files.
This is an unofficial WhatsApp Web integration. Upstream browser/API changes can break compatibility; the pinned runtime and its patches need maintenance.
Runtime profiles separate browser authentication. Run separate MCP processes with distinct data directories for separate users; domain artifacts are local process data.
Job listing/cancellation and repeat records exist; there is no general background worker consuming the repeat queue. A queued record is not completed work.
History completeness depends on what WhatsApp exposes. OCR/transcription quality depends on installed tools, models and source media.
Local data includes conversation content, media, credentials and diagnostics. It stays outside source control. See SECURITY.md.
python -m unittest discover -s tests -v
python -m compileall server.py whatsapp_web_mcp testsThe offline suite covers tool schemas, date ranges, history boundaries, media, action confirmation/replay, backend verification, private persistence and path traversal. Live read/send smoke tests are opt-in and skipped by default. They need an authenticated session and an explicitly configured test group; sending also requires a separate confirmation flag. Offline passing tests do not establish current live WhatsApp compatibility. No live messages were sent in this verification pass.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0whatsapp_automated_search_planwhatsapp_browser_closewhatsapp_browser_openwhatsapp_browser_policywhatsapp_browser_runtime_statuswhatsapp_capabilitieswhatsapp_chat_structurewhatsapp_confirm_send_messagewhatsapp_export_conversationwhatsapp_find_contactswhatsapp_prepare_send_messagewhatsapp_probe_reply_to_messagewhatsapp_probe_send_mediawhatsapp_search_messageswhatsapp_select_contextwhatsapp_set_browser_policywhatsapp_sourceswhatsapp_transcribe_fileScored across 18 tools
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.
Your own WhatsApp as an MCP server: read, search and send from any MCP client.
WhatsMCP connects Claude and other MCP-compatible AI agents directly to WhatsApp. Send and receive text, images, documents, and voice notes; manage groups (create, add/remove members, promote admins); look up contacts and profiles; follow channels; and read call and message history — all through a standard MCP interface. For voice use cases, WhatsMCP offers SIP-based calling plans (inbound-only, or full inbound/outbound) so AI voice agents can answer and place WhatsApp calls, plus low-latency WebSocket integrations with voice agent providers like ElevenLabs. Multiple WhatsApp accounts can be paired and managed per workspace, with webhook support for real-time inbound message delivery to your own infrastructure.
Let Claude or ChatGPT search, read and send your WhatsApp messages over MCP. OAuth sign-in.
Drive WhatsApp from any MCP client: pair devices, send text and media, manage contacts and groups.
