Skip to main content
Glama
Sign In
scherlok

scherlok

by rbmuller
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

watch

Profiles tables and detects anomalies against stored baselines, returning severity and hints per table. Pass table names to limit scope or omit to check saved or all tables.

Instructions

Profile tables and detect anomalies against the stored baseline.

Returns the anomalies found (type, severity, message per table), capped. Each also carries column, metric, baseline, current, change_pct and a fixed hint on where to look, null when one does not apply. Pass tables to limit scope, or omit to watch the tables saved with scherlok connect --table, else everything. A table with no prior baseline gets the new-table checks instead (empty_table, all_null_column, duplicate_key as WARNING, constant_column as INFO), and its baseline is set for next time. A table with a CRITICAL anomaly keeps its baseline, so the anomaly is reported again on every call until the data recovers or a person runs scherlok accept; WARNING and INFO findings are learned. With baselines locked, nothing is learned.

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": "watch"
  }
}

Input Schema

NameRequiredDescriptionDefault
tablesNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does most of it: it discloses that the tool mutates state (baselines are set and learned), which findings persist across calls, and what happens with locked baselines. It omits cost/latency expectations and error conditions, but the state-change semantics are clear.

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, then scope, then baseline lifecycle — a sensible order with little filler. The enumeration of returned fields (`column`, `metric`, `baseline`, `current`, `change_pct`, `hint`) is somewhat redundant given an output schema exists, which is the main wasted sentence.

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?

For a single-optional-parameter profiling tool with an output schema, the description covers scope resolution, return contents, and the full baseline state machine including the CRITICAL/WARNING distinction. An agent has everything needed to call it correctly and interpret repeat calls.

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 does: `tables` is explained as a scope limiter with two distinct default behaviors (saved tables, then everything). It adds real meaning beyond the bare array-of-strings schema, though it doesn't give format examples for table identifiers.

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: 'Profile tables and detect anomalies against the stored baseline.' Combined with the new-table check listing and the baseline-learning rules, an agent can distinguish this from siblings like check or verify. However, no sibling is named explicitly, so differentiation is inferred from mechanics rather than stated.

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 clear scoping guidance: pass `tables` to limit scope, omit to watch connect-saved tables, else everything. It also explains the repeat-invocation situation (CRITICAL anomalies reappear until data recovers or `scherlok accept`) and the new-table case. It stops short of naming an alternative sibling tool for the accept/unlock workflow.

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