Skip to main content
Glama
Sign In
Parley

Parley

by Verbiflow
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Load a chat's history

load_history

Fetch older WhatsApp messages from the account holder's phone, including attachments and reactions, to page back through chat history beyond what Parley has already synced.

Instructions

Fetch a chat's older messages from the account holder's phone, as WhatsApp's own "get older messages from your phone" does: the count messages before the oldest one Parley has (e.g. from before the account was linked, or while the chat was ignored), with their attachments and reactions. Call it again to go further back, count at a time. Waits up to about 20 seconds for the phone, which must be online; answered says whether it replied. Answered, it returns the older messages it fetched; not, the chat's latest messages as Parley has them. Afterwards they're in read_inbox too. Like read_inbox, it says what's new since the chat was last read (new_since_last_read, new: true, new_reactions; older history fetched now isn't new) and marks what it returns as read unless mark_read is false — and then, by default, sends read receipts on WhatsApp too (see read_receipts).

Input Schema

NameRequiredDescriptionDefault
countNoHow many older messages to fetch (default 20, at most 50).
chat_idYesThe chat (chat_id from list_chats or read_inbox).
mark_readNoMark what this returns as read (default true). Pass false to look without changing what counts as new.
connection_idNoWhich of your accounts: a connection id from list_connections, or the account's number. Optional when only one account fits. Left out, it's the account that has the chat.
read_receiptsNoAlso mark the messages this returns read on WhatsApp itself, as opening the chat on the phone would. On by default whenever this marks them read (each number's setting in Parley); pass false to read without telling the sender. The senders see blue ticks only if that number's WhatsApp has read receipts on; otherwise only its own devices mark the chat read. On a number whose read receipts the account holder turned off in Parley, none are sent.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/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 does so: the phone must be online, the call waits about 20 seconds, and the `answered` flag reports whether the phone replied. It further discloses the degraded fallback (latest messages instead of older ones when unanswered) and the side effects — marking returned messages read and sending WhatsApp read receipts unless overridden.

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 core purpose is front-loaded and nearly every clause carries operational information, but the single dense paragraph mixes purpose, failure modes, read semantics, and receipts with nested parentheticals. The repeated 'Like read_inbox...' comparison is useful once but adds bulk to an already long block.

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

Completeness5/5

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

For a tool with no annotations, no output schema, and five parameters, the description covers everything an agent needs: what is returned in each outcome, the `answered` discriminator, the phone-online prerequisite, timeout expectations, and the read/receipt side effects. Nothing material is left for the agent to infer.

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 coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: `count` is framed as the paging step size, `mark_read: false` is explained as 'look without changing what counts as new', and read-receipt sending is tied to the read-marking behavior. It stops short of explaining `connection_id` resolution beyond what the schema already says.

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

Purpose5/5

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

States a specific verb and resource: 'Fetch a chat's older messages from the account holder's phone', with the precise scope 'the count messages before the oldest one Parley has'. It explicitly distinguishes itself from the sibling read_inbox by noting the fetched messages end up there afterwards, so an agent can tell the two apart without opening either schema.

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

Usage Guidelines5/5

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

Gives the exact condition for use (messages from before the account was linked, or while the chat was ignored) and how to iterate ('Call it again to go further back, count at a time'). It also names the alternative path implicitly by explaining that results afterwards live in read_inbox, so an agent knows when paging vs. reading is appropriate.

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