Skip to main content
Glama
benthic-io

benthic-mcp

Official
by benthic-io

benthic_playbook

Read-onlyIdempotent

Call once per dataset to get access conventions, authoritative columns, signed join paths, and RPC operations; omit dataset for a routing index. Pass relations to get the signed route hop by hop.

Instructions

Dataset-specific access conventions built from signed metadata and prior sessions.

Call once per dataset before answering a question that depends on domain conventions: which
source to use, which columns are authoritative, which mistakes to avoid, and which signed join
paths and RPC operations exist. Join recipes come from the signed catalog and are never
invented here. Omit dataset for a routing index of every dataset.

To move data between two relations, pass from_relation and to_relation as 'dataset.relation'
instead of a dataset. That returns the signed route hop by hop, shortest first, with the exact
arguments for each benthic_join call, and nothing else. Do this rather than searching
benthic_discover for a join path: a search can be rephrased, so a request for a path that does
not exist comes back looking like a request that was worded wrongly.

Input Schema

NameRequiredDescriptionDefault
datasetNo
max_hopsNo
to_relationNo
from_relationNo

Output Schema

NameRequiredDescriptionDefault
coreNo
pathNo
statusYes
datasetsNo
warningsNo
generatorNo
collectionYes
generated_atNo
collection_notesNo
catalog_fingerprintNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, openWorld, non-destructive. The description adds genuinely new behavior: join recipes come from the signed catalog and are never invented here, the relation mode returns 'nothing else,' and results are ordered shortest-first with exact arguments for each benthic_join call. Only max_hops behavior and response shape are left unstated.

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?

Three well-organized paragraphs, front-loaded with the core purpose and the call-frequency guidance. The explanation of why not to use search (rephrasing masks non-existent paths) is slightly verbose but earns its place by steering tool selection.

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

Completeness4/5

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

An output schema exists so return values needn't be described, and the two main invocation modes (dataset lookup vs relation routing) are covered. The only shortfall is the undocumented max_hops parameter, minor for a read-only advisory tool.

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 description coverage is 0% for 4 parameters, so the description must carry the load; it explains dataset (omit for routing index) and the from_relation/to_relation 'dataset.relation' format plus their mode-switching effect. max_hops is never explained beyond the schema's min/max bounds, a minor gap.

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

Purpose4/5

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

The description states a specific verb (call/return) and resource (dataset-specific access conventions: authoritative columns, join paths, RPC operations) rather than restating the name. It partially distinguishes itself from siblings benthic_join and benthic_discover by naming them as alternatives, though the underlying resource ('playbook') remains slightly abstract.

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?

Explicit when-to-use ('Call once per dataset before answering a question that depends on domain conventions'), when-not ('Omit dataset for a routing index'), and a named alternative with the condition that selects it ('Do this rather than searching benthic_discover for a join path'). The rationale for preferring this tool over discover is even given.

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