stl-transit

Overview Schema Source Related Servers Discussions Admin

stl_oracle_verify

Read-onlyIdempotent

Recompute committed fixtures against the current feed to identify drift, revealing feed changes or stale fixtures. Distinguishes permanent drift from legitimate errors for scheduled verification.

Instructions

Recompute every committed fixture against the current feed and report which ones no longer match. Drift means either the feed changed or the fixtures are stale -- both are things you want to learn from a scheduled run, not a user.

A case that legitimately raises (unknown stop code, expired feed) is a first-class expectation, compared on error type rather than message, so it does not read as permanent drift.

Args: fixtures_dir: directory of committed fixture JSON, normally the tool repo's test resources rather than anywhere in this store.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`snapshot`	No
`fixtures_dir`	No		fixtures

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 7, 2026

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already indicate readOnly, idempotent, and non-destructive behavior. The description adds no additional behavioral details beyond the core 'recompute and report', so it meets the baseline without enriching beyond annotations.

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?

The description is two sentences long and mostly relevant, but the second sentence about 'scheduled run' could be more concise. It does not waste words, yet the phrasing is slightly convoluted.

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

Completeness3/5

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

The tool's main purpose is clear, but the undocumented 'snapshot' parameter and lack of output description (though an output schema exists) leave gaps for an agent attempting to call it correctly. The scheduled-run context helps but does not fully compensate.

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?

Only 'fixtures_dir' is described in the args section; 'snapshot' is left entirely undocumented. With 50% coverage, the description provides partial meaning but lacks full parameter clarity.

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?

The description clearly states the tool's purpose: recompute committed fixtures against the current feed and report mismatches. It distinguishes this verification tool from sibling tools like 'stl_oracle_generate' by focusing on checking rather than creating fixtures.

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?

It provides context on when to use: scheduled runs to detect drift, and notes that user-driven calls are not the primary scenario. However, it does not explicitly contrast with alternative tools, leaving some inference to the agent.

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

Deploy Server