Skip to main content
Glama
Sign In

ZTL Judge

by io.github.inventor1975
OverviewDiscussionsAdmin

check_steps

Check an algebra derivation step by step: does each step keep exactly the same solutions?

Args:
    request: {"equations": ["x^2 = x", "x = 1"], "var": "x", "domain": [lo, hi] or null,
        "domain_verified": true}. Each equation is the next step; one unknown; + - * / ^ with whole powers.

Returns:
    The chain's verdict (its weakest step) and each step's: EARNED = same solutions on the domain;
    ON CREDIT = the same, on an unverified domain; REFUTED = a solution is lost (e.g. cancelling a factor that
    can be 0) or gained (e.g. clearing a denominator where the original was undefined), with the witness and
    the cause; E = the step divides by an expression that is 0 for every value. A request above the public
    limits is refused with the reason (ok: false, refused).

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": {
      "request": "<request>"
    },
    "name": "check_steps"
  }
}

Input Schema

NameRequiredDescriptionDefault
requestYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.1/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the verdict categories EARNED, ON CREDIT, REFUTED, and E, explains causes and witnesses, and states that requests above public limits are refused with a reason. This is strong behavioral context, though it does not discuss performance or other operational constraints beyond refusal.

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 purpose is front-loaded, and the Args/Returns structure is easy to scan. The Returns section is dense and detailed, but the detail is useful for interpreting verdicts rather than padding.

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?

Although an output schema exists, the description still explains the key return semantics and refusal behavior. For a one-parameter checker with a complex nested request, the definition gives enough information for an agent to call it correctly and understand the verdicts.

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%, and the request schema is only a generic object or string. The description compensates by naming and explaining every meaningful request field: equations as successive steps, the single unknown var, the optional domain bounds, and domain_verified. It also constrains the allowed operators and powers.

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?

The description uses a specific verb and resource: it checks an algebra derivation step by step and asks whether each step preserves exactly the same solutions. This is clear and not tautological, but it does not differentiate the tool from sibling names like judge or checker_examples.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for checking derivations and explains the request format, but it gives no explicit when-to-use guidance, no when-not-to-use guidance, and no comparison to alternatives such as judge or judge_naive. Usage is inferable rather than stated.

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

All ZTL Judge toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources