Skip to main content
Glama
Sign In
scherlok

scherlok

by rbmuller
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

reconcile

Verify an output table against its source table by comparing row counts, key coverage, duplicate keys, and column totals with tolerance; returns pass/fail and anomaly fix hints.

Instructions

Check that an output table adds up against the input it was built from.

Read-only: compares target with source on the configured connection and saves nothing. Always compares row counts. With key_columns (unique in the target; several for a composite key) it also counts keys repeated in the target (a join that fans out), source keys missing from the target and target keys the source lacks. With sum_columns it compares each column's total, which may differ by at most tolerance (absolute). Returns counts and totals only, never a key value; passed is false on any mismatch, each a CRITICAL anomaly with a fix hint. Both tables must be listed by list_tables.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "source": "<source>",
      "target": "<target>"
    },
    "name": "reconcile"
  }
}

Input Schema

NameRequiredDescriptionDefault
sourceYes
targetYes
toleranceNo
key_columnsNo
sum_columnsNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.3.0

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations to lean on, the description carries the full burden and does: it declares read-only with nothing saved, always compares row counts, explains what extra checks each optional parameter triggers, specifies the pass/fail rule and anomaly severity, and commits to never returning key values.

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?

Front-loaded with the core action and the read-only guarantee, then parameter behavior, then return semantics. Dense but nearly every clause carries information; the middle sentence about key comparisons is a long run-on that could be split for faster parsing.

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?

An output schema exists, yet the description already signals the shape of the result (counts, totals, `passed`, CRITICAL anomalies with a fix hint), and it covers the prerequisite and comparison logic. An agent has everything needed to invoke this correctly without opening other tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate and it does: `key_columns` is documented including its uniqueness requirement in the target and composite-key usage, `sum_columns` explains the per-column total comparison, and `tolerance` is defined as an absolute allowance on those totals. It also implicitly maps source input table to target output table.

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?

States a specific verb and resource: 'Check that an output table adds up against the input it was built from', which pins down reconciliation rather than generic checking. It is not, however, explicitly distinguished from the near-synonym siblings `check`, `verify`, and `investigate`, so an agent must infer the difference from semantics alone.

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?

The trigger condition is clear (after an output table has been built from an input) and it states a hard prerequisite: both tables must be listed by `list_tables`. It does not explicitly say when to prefer `check` or `verify` instead, which is the main gap given those siblings.

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

Deploy Server

Other Tools