pond
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
| resources | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| pond_get_messageA | Expand one message with its full part bodies (tool_call / tool_result / reasoning / file), plus conversational neighbors for context. Pass a message_id from pond_search or a transcript line; context_before / context_after size the neighbor window (default 3, like grep -B/-A). For the whole session use pond_get_session. Response format details: resource schema://pond. |
| pond_get_sessionA | Read a whole past session as a chronological transcript - the tool for analyzing, reviewing, or summarizing a session (user/assistant text plus one-line tool/file refs; tool bodies stay one pond_get_message away). Pass the id from pond_search or a subagent footer; a message_id also works - it resolves to its parent session with the page anchored at that message. Paging: limit (default 20), from="end" reads the most recent turns first (the session's final state; late conclusions supersede early ones), after_message_id / before_message_id continue from a page marker. The first page lists subagent sessions in a footer - pass a listed id back to open one. Not for bulk export - use |
| pond_searchA | 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. |
| pond_sqlA | Advanced escape hatch: run ONE read-only SQL statement (SELECT/WITH, DataFusion / PostgreSQL-compatible) over the sessions / messages / parts tables. NOT for finding or reading conversations - pond_search and pond_get_session / pond_get_message cover almost all recall. Reach for SQL only for: aggregation (counts, group-by, joins, time buckets), exact strings or identifiers in conversational text (contains_tokens / fts), tool-call analytics and tool bodies, subagent sessions, bulk export (format=parquet|ndjson). Read resource schema://pond-sql FIRST - exact columns, indexed predicates, JSON access rules, worked examples; do not guess column names or JSON paths. Inline text output is row-capped and long cells clip with a +N chars marker (full values via format=parquet|ndjson); queries are wall-clock-capped (raise via timeout_seconds). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| pond search schema | |
| pond SQL table schema | |
| pond corpus stats |
TDQS
Scored across 4 tools
Each tool targets a distinct purpose: pond_search for discovery, pond_get_message for single-message expansion, pond_get_session for full-session transcripts, and pond_sql for advanced SQL queries. The descriptions make the boundaries clear, and there is no overlap in functionality.
All tools share the pond_ prefix and use snake_case, but the pattern is not perfectly uniform: two use get_ (pond_get_message, pond_get_session), one uses a bare verb (pond_search), and one uses a noun (pond_sql). This is mostly consistent but with a slight deviation.
Four tools is well within the ideal 3-15 range for a focused server. Each tool earns its place: search, single-message read, session read, and SQL access cover the core recall/analytics functionality without redundancy.
The set provides a complete workflow for recalling past conversations: search to find, then either get a message or get a session to read, with SQL as an escape hatch for advanced queries, exact matching, and analytics. The documented gaps (tool bodies, subagent sessions) are explicitly addressed via SQL, so there are no dead ends.