Replay supplied records against old and new bounded JSON Schema draft-07 contracts. Receive exact regression indices, reasons and a request digest. Results cover the supplied corpus only. Price: 0.02 USDC per completed bounded job on Base.
| Name | Required | Description | Default |
|---|---|---|---|
| examples | Yes | ||
| new_schema | Yes | ||
| old_schema | Yes |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, idempotent, and non-destructive behavior. The description adds genuinely new behavioral context: the paid nature ('Price: 0.02 USDC per completed bounded job on Base') and the guarantee that results are restricted to the supplied corpus. There is no contradiction with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences front-load the action and output, with scope and pricing notes placed at the end. Every sentence earns its place and there is no filler or repetition of schema content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a paid, externally-scoped job with no output schema and no parameter descriptions, the description covers the action, output shape, scope, and cost. However, it leaves ambiguity around what 'bounded' means, when billing actually triggers (e.g., if a job fails partway), and error/failure semantics for invalid records — details an agent would need before invoking a paid tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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. It maps 'supplied records' to the examples parameter and 'old and new bounded JSON Schema draft-07 contracts' to old_schema/new_schema, adding the version and bounded qualifiers. However, it does not define what constitutes a valid record/example or what constraints 'bounded' imposes, leaving format details ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: 'Replay supplied records against old and new bounded JSON Schema draft-07 contracts.' It also states the exact outputs ('exact regression indices, reasons and a request digest'), so an agent knows precisely what the tool does and what it returns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
With no sibling tools, explicit alternative-routing is unnecessary. The scope caveat 'Results cover the supplied corpus only' sets a clear expectation about when the results are meaningful, and 'draft-07'/'bounded' qualifiers imply a schema-migration regression-testing use case. It could explicitly say 'use when checking schema compatibility,' but the context is otherwise clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
With only one tool, there is no possibility of confusing it with another. The name and description clearly define its purpose as comparing records against old and new schemas.
A single tool uses a clear, descriptive snake_case name. There are no other tools to create inconsistent naming patterns.
One tool is borderline thin but reasonable for a narrowly scoped server. The function is specific and self-contained, though the 'Schema Change Gate' name hints at a broader workflow.
The tool fulfills its stated comparison task well, but there are minor gaps like no schema diffing, result history, or approval step. Agents can work around these missing features.