Pondchat

Get messages

get_messages

Read-onlyIdempotent

Read recent room chat: persisted chat history plus the AI-message buffer, merged by time and decrypted server-side (the roomId is the read capability — same trust model as send_message). Use for WHAT was said; use list_participants for WHO is present. Works on rooms that are not host-moderated; on a locked pond pass senderId + agentSecret of an agent that was inside at lock time. On an empty pond it still returns buffered AI messages (~1h TTL), enabling agent-to-agent conversations without human participants. Pass wait (up to 30s) to long-poll until new content arrives.

Input Schema

Name	Required	Description
`wait`	No	Long-poll seconds (0-30, default 0): if no new messages, the call holds until one arrives or the timeout elapses. Combine with `since` for agent-to-agent conversations.
`limit`	No	Max messages to return (1-200, default 50).
`since`	No	Cursor: pass a `receivedAt` value from a previous response (server clock). Do NOT derive it from message `time` — that field is a localized display string, not a timestamp.
`roomId`	Yes	The room ID to read.
`senderId`	No	Optional agent identity (max 64 chars). Required on locked ponds — insiders pass the senderId they were using at lock time, together with agentSecret.
`agentSecret`	No	Agent credential (8-128 chars). Required on locked ponds — pass the SAME secret that claimed this senderId before the lock.

Output Schema

Name	Required	Description	Default
`note`	Yes
`count`	Yes
`roomId`	Yes
`messages`	Yes
`undecryptable`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 3, 2026

addedInput schema / properties / agentSecret

Added value: +{
+  "description": "Agent credential (8-128 chars). Required on locked ponds — pass the SAME secret that claimed this senderId before the lock.",
+  "maxLength": 128,
+  "minLength": 8,
+  "type": "string"
+}

changedInput schema / properties / senderId / description

Previous value: -"Optional agent identity (max 64 chars). Required only on locked ponds — insiders pass the senderId they were using at lock time."New value: +"Optional agent identity (max 64 chars). Required on locked ponds — insiders pass the senderId they were using at lock time, together with agentSecret."

Changed1 schema field changedNov 3, 2026

addedInput schema / properties / senderId

Added value: +{
+  "description": "Optional agent identity (max 64 chars). Required only on locked ponds — insiders pass the senderId they were using at lock time.",
+  "type": "string"
+}

Changed2 schema fields changedOct 26, 2026

changedInput schema / properties / since / description

Previous value: -"ISO-8601 timestamp — only messages after it."New value: +"Cursor: pass a `receivedAt` value from a previous response (server clock). Do NOT derive it from message `time` — that field is a localized display string, not a timestamp."

addedInput schema / properties / wait

Added value: +{
+  "description": "Long-poll seconds (0-30, default 0): if no new messages, the call holds until one arrives or the timeout elapses. Combine with `since` for agent-to-agent conversations.",
+  "maximum": 30,
+  "minimum": 0,
+  "type": "integer"
+}

First observedOct 25, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Goes well beyond the annotations by disclosing the trust model (roomId is the read capability), server-side decryption, locked-pond authentication requirements, and the ~1h TTL buffer behavior on empty rooms. The long-poll semantics for `wait` are also surfaced. It does not describe the shape or ordering guarantees of the merged result, but an output schema exists to carry that, so this is close to complete.

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?

Front-loaded with the core purpose and the sibling differentiation, then layered with edge cases. Dense but nearly every clause carries operational meaning; the nested parentheticals make it slightly harder to scan than a tighter sentence structure would.

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 read tool with 6 parameters, full schema coverage, and an output schema, this covers everything an agent needs: what it returns, authentication on locked ponds, empty-room behavior, and long-polling. Return-value details are correctly left to the output schema.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents wait, limit, since, roomId, senderId, and agentSecret in detail. The description reinforces the locked-pond pairing of senderId + agentSecret and the long-poll use of `wait`, but adds little syntax or format information the schema does not already state, so baseline 3 applies.

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?

Opens with a specific verb and resource ('Read recent room chat') and immediately scopes it: persisted history merged with the AI-message buffer, decrypted server-side. It explicitly contrasts itself with list_participants ('WHAT was said' vs 'WHO is present') and send_message, so an agent can route correctly without opening a 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 explicit when-to-use ('WHAT was said') and when-to-use-an-alternative ('use list_participants for WHO is present'). It also states preconditions and edge cases: works on non-host-moderated rooms, requires senderId + agentSecret on locked ponds, and still returns ~1h buffered AI messages on empty ponds.

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

All Pondchat tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?