Skip to main content
Glama

pond_sql

Read-onlyIdempotent

Run read-only SQL (SELECT/WITH) over session, message, and part tables for aggregation, exact-string matching, tool-call analytics, and bulk export (parquet/NDJSON).

Instructions

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).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYesOne read-only SQL statement (SELECT/WITH only; writes rejected). Exact columns - messages(session_id, message_id, timestamp, role, source_agent, project, content [system-role only], search_text [the conversational text], embedding_model, options) | sessions(session_id, parent_session_id, parent_message_id, source_agent, created_at, project, options) | parts(session_id, message_id, id, ordinal, type, provenance, tool_name, call_id, is_failure, variant_data, options). parts.type enums use underscores: 'tool_call', 'tool_result', 'text', 'reasoning', 'file'. Tool bodies live in JSONB variant_data - tool_call is {call_id, name, params} (a Bash command is json_extract(variant_data, '$.params.command')), tool_result is {call_id, name, is_failure, result}; never CAST JSON columns. No substring index covers tool bodies: an unscoped LIKE over variant_data full-scans and times out on a remote store - scope-then-scan instead (collect session_ids WHERE contains_tokens(search_text, '...'), then match variant_data fields only within them; worked example in schema://pond-sql). Tool analytics: prefer the narrow native columns (tool_name, call_id, is_failure). Text search: WHERE contains_tokens(search_text, 'words'), or FROM fts('messages', '{...}') for BM25 ranking. Joins, indexed columns, JSON functions, pagination, worked examples: resource schema://pond-sql.
formatNoOutput format: "text" (default; rendered ASCII table with metrics footer, row-capped), "parquet", or "ndjson". For parquet/ndjson the full result set is written to a file and a `pond-sql-export://` resource link is returned (no truncation) - ndjson is the path for machine-readable JSON output.
timeout_secondsNoPer-query timeout in seconds (default 30, max 600). Raise it for a genuinely long-running query (e.g. a large remote-store scan); prefer narrower predicates and the indexed/native columns first.
Behavior5/5

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

Beyond the annotations (readOnlyHint, openWorldHint, idempotentHint), the description discloses critical runtime behaviors: output is 'row-capped' with 'long cells clip with a +N chars marker', queries are 'wall-clock-capped', and writes are rejected (in schema description). It also warns about performance pitfalls ('unscoped LIKE over variant_data full-scans and times out') and tells users to scope-then-scan. This goes well beyond annotation hints and prepares the agent for real-world edge cases.

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?

The description is a single, dense paragraph that front-loads purpose and exclusions, then lists use cases, then gives operational guidance and output/performance caveats. Every sentence earns its place; there is no filler or tautology. The structure makes it easy to scan and absorb.

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?

Given the tool's complexity (SQL over multiple tables, JSONB fields, export modes, potential for timeouts), the description is remarkably complete. It covers return value behavior (row cap, truncation, export links), performance pitfalls, schema resources to read first, and use-case boundaries. No output schema exists, but nothing is missing for selecting and invoking the tool correctly.

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?

With 100% schema description coverage and highly detailed parameter descriptions, the baseline is 3. The tool description adds usage context for parameters: linking format=parquet|ndjson to avoiding truncation, and timeout_seconds to raising the wall-clock cap for long-running queries. This enriches the bare schema without being essential, so a 4 is appropriate rather than a 5.

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?

The description opens with a clear verb+resource: 'run ONE read-only SQL statement' over specific tables ('sessions / messages / parts'). It explicitly distinguishes itself from siblings by stating 'NOT for finding or reading conversations' and naming pond_search and pond_get_session / pond_get_message as alternatives. This leaves no ambiguity about the tool's niche.

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?

The description provides explicit when-to-use guidance: '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'. It also gives a clear exclusion ('NOT for finding or reading conversations') and names alternative tools, fulfilling the when/when-not/alternatives criteria perfectly.

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