Skip to main content
Glama

Verify Claim

verify_claim
Idempotent

Verify a stated mathematical claim and get an honest verdict—proved, refuted, supported, or undecided—with evidence.

Instructions

Independently re-check a stated mathematical claim and report how far the evidence goes: proved, refuted, supported or undecided.

Use this to verify your own algebra before presenting it. The claim is a single comparison in Sage syntax -- an equality, an inequality, or anything that evaluates to True/False:

integral(x^2/(e^x-1), x, 0, oo) == 2*zeta(3) sin(x)^2 + cos(x)^2 == 1 pi < 22/7 e^pi != pi^e

The check climbs a ladder: Sage's symbolic prover, the exact difference ((lhs-rhs).simplify_full().is_zero()), exact arithmetic over QQbar/AA when the claim is constant, then certified interval arithmetic and numeric sampling over the free variables. Verdicts are honest by construction: 'proved' and 'refuted' are exact decisions ('refuted' always exhibits its counterexample or certified enclosure); 'supported' means the numeric evidence is consistent with the claim without proving it, and says how many samples at what precision; 'undecided' means every rung was inconclusive -- it never means false.

Exactness is never assumed. Decimal literals are read exactly (0.1 means 1/10, never the 53-bit double), and a comparison whose operands are machine floats (RR/RDF/CC, an .n() result) is reported as 'supported' over inexact numbers, never as an exact proof -- state it over ZZ/QQ/QQbar or symbolically for an exact verdict. The session's active assumptions (assume(x > 0), assume(x, 'integer')) are honored: a sampled counterexample must lie inside the stated domain, and any verdict that relied on an assumption names it in the evidence.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
claimYesThe claim to check, as a single comparison, e.g. 'sin(x)**2 + cos(x)**2 == 1'
samplesNoSample points per free variable sweep when the claim cannot be decided exactly
sessionNoWorkspace to use, as a name or a portable handle. Workspaces have independent variables. A name is scoped to this MCP session; a handle returned by start_sage_session (workspace_token) reaches the same workspace across reconnects and is a bearer credential -- keep it secret. Omit for 'default'.default
timeoutNoOverride the evaluation timeout in seconds
precision_bitsNoPrecision of the certified interval arithmetic behind numeric verdicts

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
claimYesThe claim that was checked, whitespace-folded.
methodNoThe rung that decided: exact_comparison, symbolic_prover, exact_difference, exact_algebraic, certified_interval, numeric_sampling, float_comparison (operands were machine floats, so the result is only supported, never exact) or exhausted.
samplesNoNumber of sample points supporting a numeric-sampling verdict.
verdictYesproved/refuted are exact; supported is evidence short of proof; undecided means every rung of the ladder was inconclusive.
evidenceNoWhat the deciding rung actually established, including the counterexample for a sampled refutation.
assumptionsNoThe session's active assumptions in force during the check (e.g. "x is integer"). A verdict is only valid under these; they are also named in the evidence so no branch can conceal them.
precision_bitsNoInterval-arithmetic precision behind a numeric verdict.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.7.0

TDQS

A4.6/5.0
Behavior5/5

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

Discloses far beyond the annotations: the proof ladder, honest-by-construction verdict semantics, that 'refuted' always exhibits a counterexample/enclosure, that decimal literals are read exactly, and that session assumptions are honored. None of this is derivable from the annotations, and it does not contradict them.

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 front-loaded with purpose and usage, and every paragraph carries genuinely useful information rather than filler. It is long, but the length is justified by the tool's subtle correctness semantics; still, the exactness and verdict sections could be tightened slightly without losing value.

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?

Given the tool's complexity, five parameters, and an existing output schema, the description covers input syntax, allowed claim shapes, verdict meanings, precision and sample behavior, exactness caveats, and assumption handling. An agent has enough context to invoke the tool correctly without needing the output schema to explain return values.

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 coverage is 100%, so the baseline is already strong, but the description adds meaningful semantics for the primary parameter: what counts as a single comparison, four concrete claim examples, exact-decimal parsing, and the fact that session assumptions affect verdicts. It does not need to add much for samples, timeout, or precision_bits beyond their schema descriptions.

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 precise verb and object: 'Independently re-check a stated mathematical claim' and names the four possible verdicts, which clearly separates it from solving, calculating, or plotting siblings. It also narrows the input to a single comparison in Sage syntax with concrete examples, so an agent knows what the tool is for.

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?

Explicitly says 'Use this to verify your own algebra before presenting it' and gives important context about when a verdict can be exact versus merely 'supported', including the machine-float caveat. It does not explicitly name alternative sibling tools or say 'use X instead', so it stops just short of full when/when-not routing.

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