Skip to main content
Glama
Sign In
yehudashtein

wa-bridge-mcp

by yehudashtein
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

list_messages

Retrieve WhatsApp messages filtered by date, sender, chat, or content, with pagination and optional surrounding context.

Instructions

Get WhatsApp messages matching specified criteria with optional context.

Args:
    after: Optional ISO-8601 formatted string to only return messages after this date
    before: Optional ISO-8601 formatted string to only return messages before this date
    sender_phone_number: Optional phone number to filter messages by sender
    chat_jid: Optional chat JID to filter messages by chat
    query: Optional search term to filter messages by content
    limit: Maximum number of messages to return (default 20)
    page: Page number for pagination (default 0)
    include_context: Whether to include messages before and after matches (default True)
    context_before: Number of messages to include before each match (default 1)
    context_after: Number of messages to include after each match (default 1)
    include_groups: Whether to include group chat messages (default False)

Input Schema

NameRequiredDescriptionDefault
pageNo
afterNo
limitNo
queryNo
beforeNo
chat_jidNo
context_afterNo
context_beforeNo
include_groupsNo
include_contextNo
sender_phone_numberNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.1/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden, and it discloses only the context-window behavior (include_context with before/after counts) and the include_groups default. It says nothing about read-only semantics, ordering of results, pagination behavior beyond default values, or whether data is local-cached versus live, all of which matter for an 11-parameter query tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose sentence is front-loaded and the Args enumeration is dense but earns its space given zero schema descriptions. There is minor redundancy in restating defaults that already exist in the schema, but no filler prose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 11-parameter tool with no annotations and no output schema, the description covers inputs adequately but never indicates what a returned message looks like, how context messages are flagged or ordered relative to matches, or what an empty result means. It is usable as-is but leaves the agent guessing about the response shape.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the Args block is the only documentation for all 11 parameters, and it does the job: it gives format hints (ISO-8601), meaning (sender vs chat vs content filters), and defaults. It falls short of 5 because 'page' semantics (offset vs page index, interaction with limit) remain ambiguous and context_before/context_after applicability is not tied explicitly to include_context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence states a specific verb (Get) and resource (WhatsApp messages) plus the scoping notion of matching criteria with optional surrounding context. It is clear what the tool does, but it does not distinguish itself from siblings like get_message_context or list_chats, which an agent must differentiate on name alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Nothing states when to use this versus get_message_context, list_chats, or get_last_interaction, nor are there any exclusions or prerequisites. Usage is only inferable from the parameter list (filters imply search-style retrieval), which is guidance by implication rather than statement.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools