Skip to main content
Glama
Sign In
scherlok

scherlok

by rbmuller
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

verify

Compare database tables with a stored baseline and return a pass/fail CI gate; read-only, so no profiles or anomalies are written.

Instructions

Compare tables with the stored baseline and return a pass/fail gate, leaving it unchanged.

Read-only, unlike watch and check: no profiles or anomalies are written, so retrying after a failure keeps failing until the data is fixed; only the run itself is recorded. Pass tables to limit scope, or omit to verify everything. fail_on is "critical" (default) or "warning". Tables with no stored baseline are listed in tables_without_baseline and never counted as verified. Naming one in tables says it was just built, so an empty table, an all-NULL column or a duplicate key there is CRITICAL; unnamed, they stay WARNING. Once the data is right, investigate sets a baseline.

against compares with another database's baseline instead, e.g. production's when the connection is a dev schema you just built: its scope, such as postgresql://db.example.com/shop (adapter, host, port and path, never a connection string with credentials). Only records saved under that scope count, freshness is not compared, and a scope with no baseline in the store is an error. ignore=["volume"] is for a build on sampled data: row counts are not compared and the column checks allow for a sample.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "verify"
  }
}

Input Schema

NameRequiredDescriptionDefault
ignoreNo
tablesNo
againstNo
fail_onNocritical

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.3.0

TDQS

A4.9/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden and does so: it declares read-only behavior, that no profiles or anomalies are written, that retrying after failure keeps failing until data is fixed, that only the run is recorded, and that a scope with no baseline in the store is an error. It also discloses non-obvious classification rules — tables named in `tables` escalate empty table/all-NULL/duplicate key to CRITICAL, unnamed stay WARNING, and `tables_without_baseline` entries are never counted as verified.

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?

Every sentence earns its place: the read-only contrast, the retry consequence, the no-baseline rule, the scoping rule, the `fail_on` values, the escalation rule, the `against` semantics, and the `ignore` caveat are each distinct facts. Parameter names are set off in backticks and the leading sentence front-loads the core contract before the detail.

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, so return values needn't be explained, yet the description still names the `tables_without_baseline` field because its semantics are surprising (excluded from verified counts). For a four-parameter, zero-annotation tool with mutation-adjacent semantics, nothing an agent needs to call it correctly is missing.

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%, so the description must compensate, and it defines all four parameters: `tables` as an optional scope limiter, `fail_on` as "critical" (default) or "warning", `against` as a database scope string with the exact shape (adapter, host, port, path — never a connection string with credentials), and `ignore=["volume"]` meaning row counts skipped and column checks sample-tolerant. It falls short only on `ignore` and `tables`, whose other accepted values and formats are not enumerated.

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?

Opens with a specific verb and resource: 'Compare tables with the stored baseline and return a pass/fail gate.' It explicitly names the siblings it differs from ('Read-only, unlike `watch` and `check`') and mentions `investigate` as the baseline-setting counterpart, so an agent can place it precisely among seven siblings.

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?

Gives explicit when-to-use context: use when you want a non-mutating comparison, pass `tables` to scope or omit to verify everything, use `against` when the connection is a dev schema you just built, and use `ignore=["volume"]` for sampled builds. It also states the corrective path ('Once the data is right, `investigate` sets a baseline'), which is genuine routing guidance.

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