Skip to main content
Glama

pond_search

Read-onlyIdempotent

Find relevant messages in past AI agent sessions to recall what was worked on, decided, or discussed. Supports semantic and exact-word search, with filters for project, date, and session.

Instructions

Find relevant messages in past sessions - the entry point for recall: "have we worked on X", "what did we decide about Y", "find the session where...". mode="vector" (default) matches meaning; mode="fts" matches exact whole words (BM25). Scope with project / session_id / source_agent / from_date / to_date; keep the query semantic (concepts, not project names). Returns scored hits grouped by session, best session first; pass a hit's session_id to pond_get_session or its message_id to pond_get_message to read it. Searches conversational text only (tool calls/results and reasoning are excluded by design - a gap there is expected, not a failure) and excludes subagent sessions; reach both via pond_sql. Response format details: resource schema://pond.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNoRetrieval arm: "vector" (default - matches on meaning) or "fts" (matches exact whole words via BM25). Use vector for concepts/ paraphrases, fts when you know the literal words. Falls back to fts when the store has no embeddings.
limitNoMax sessions to return. Default 10, server-capped at 200. This is also the "want more results" knob - raise it; there is no pagination.
queryYesWhat to search for: concepts and keywords. Keep it semantic - do not put project names in the query, use the `project` filter instead.
projectNoFilter to projects whose path contains this substring.
sort_byNoResult order: "relevance" (default - best match first) or "recency" (newest first; the response is labeled so you don't read rank-1 as the best match).
to_dateNoOnly messages on or before this date (YYYY-MM-DD).
from_dateNoOnly messages on or after this date (YYYY-MM-DD).
session_idNoFilter to one session (exact match) - search within a single, possibly long, session.
source_agentNoFilter to one source harness. A root value ("openclaw", "claude-code") returns that harness's main sessions (subagents stay excluded, like the default). Name a subpath ("claude-code/general-purpose", "openclaw/subagent") to search those subagent sessions directly - a subpath value is the deliberate opt-in that disables the default subagent exclusion.
Behavior5/5

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

Annotations already declare read-only and idempotent, and the description adds substantial behavioral detail: vector mode fallback to fts, scored hits grouped by session with best-first ordering, conversational-text-only scope, subagent exclusion with deliberate opt-in via source_agent subpath, and no pagination (limit as knob). No contradiction with annotations.

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

Conciseness5/5

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

Four dense sentences, each earning its place: purpose/examples, modes, scoping/filters, output/navigation, exclusions. Well front-loaded and free of fluff.

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?

Despite lacking an output schema, the description explains return structure (scored hits grouped by session), how to access full messages, and the expected gap for excluded content. It also points to a resource schema for further response details. Given the tool's complexity, this is complete.

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 coverage is 100% with rich per-parameter descriptions. The main description reinforces a few concepts (semantic query, mode meaning, scoping filters) but adds limited new parameter-level detail beyond the schema. Baseline 3 is appropriate since the schema carries the heavy lifting.

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?

Description opens with a specific verb+resource: 'Find relevant messages in past sessions' and positions it as 'the entry point for recall' with example queries. It further distinguishes from siblings by directing users to pond_get_session/pond_get_message for reading hits and to pond_sql for excluded content.

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?

Explicitly defines when to use: entry point for recall queries. Clearly states what is excluded (tool calls/results, reasoning, subagent sessions) and points to pond_sql for those cases, giving concrete when-not-to-use guidance. Also explains mode choices (vector vs fts) and scoping filters.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/tenequm/pond'

If you have feedback or need assistance with the MCP directory API, please join our Discord server