Skip to main content
Glama
benthic-io

benthic-mcp

Official
by benthic-io

benthic_join

Read-onlyIdempotent

Runs one signed join across qualified sources, auto-resolving the reliable identifier path when unambiguous, and requiring columns only for ambiguous or heuristic joins.

Instructions

Run one signed join using qualified sources.

Omit left_column and right_column when exactly one reliable identifier path connects the two
sources, and the signed path is resolved for you. That is the common case and it saves having to
look the path up first. Columns are still required whenever the path is ambiguous, absent, or
anything other than a reliable identifier join, so a heuristic or partial join is never chosen
for you; the error lists the candidates instead.

The adapter follows signed reliability metadata and returns warnings. Partial joins require
context_conditions. The left key filter is propagated to the right source; do not invent columns
or unsigned relationships.

Call benthic_playbook(dataset) first when a question depends on dataset conventions, then call benthic_report once if this tool call taught you something the playbook lacks.

Input Schema

NameRequiredDescriptionDefault
modeNoinner
limitNo
questionYes
left_whereNo
left_columnNo
left_sourceYes
right_whereNo
right_columnNo
right_sourceYes
context_conditionsNo

Output Schema

NameRequiredDescriptionDefault
rowsYes
joinsYes
columnsYes
sourcesYes
warningsNo
row_countYes
truncatedYes
next_offsetNo
source_completeYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds meaningful behavior beyond them: it follows signed reliability metadata, returns warnings, propagates the left key filter to the right source, requires context_conditions for partial joins, and refuses to pick heuristic joins. This is useful disclosed behavior; it stops short of describing output shape but an output schema exists.

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

Conciseness3/5

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

The core rule is front-loaded, which is good, but the prose is jargon-heavy ('signed', 'signed path', 'signed reliability metadata') and the trailing meta-instruction about benthic_playbook/benthic_report adds length. It is understandable but not tight.

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?

With an output schema present, return values need not be explained, and safety is covered by annotations. The description resolves the main ambiguity (when columns are optional/required) and the error path. Some parameters and the meaning of 'mode' remain unexplained, keeping it from a 5.

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 0% across 10 parameters, so the description carries the burden. It clarifies left_column/right_column omission rules, context_conditions, and left_where propagation, but says nothing about mode, limit, right_where, or question. Partial compensation only.

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?

Opens with a specific verb+resource: 'Run one signed join using qualified sources.' This is clearly a join-execution tool distinct from the query/discover/rpc siblings. It does not explicitly name which sibling to use instead, so it misses the top tier.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a concrete decision rule: omit left_column/right_column when exactly one reliable identifier path exists, provide them when the path is ambiguous/absent. It also states the error behavior (lists candidates) and the prerequisite for benthic_playbook. No explicit when-not-to-use-this-tool-vs-siblings guidance, so not a 5.

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