Skip to main content
Glama

Check a sentence against a figure's contract

check_claim_contract
Read-onlyIdempotent

Checks a proposed statement of a FinanceRateCalc figure against that figure's published use contract, so the sentence can be verified before it is written. Two input modes. (A) Flags: claim id plus the use you propose (population, period, scope, cause, individual prediction, lender recommendation, legal conclusion). (B) Sentence: claim id plus proposed_sentence, the exact sentence you intend to write; the tool checks it with fixed patterns, no model, for a missing period, missing program scope, a population wider than the claim, second-person prediction, causal wording, lender advice, legal conclusions, and values this publisher has since corrected. Returns a deterministic verdict: pass, needs_qualifier (naming the missing qualifier) or block (with a reason code), plus a safe sentence you may use verbatim and the required attribution. Most misuse of these statistics is omission, not invention: the number is right and the population is missing. NOT FOR: figures published by anyone other than FinanceRateCalc. (C) Rule sentence: passport_id of a rule file (frc:rule:…, five tables: FHA annual MIP, FHA forward loan limits 2026, FHFA conforming limits 2026, CFPB HOEPA/QM thresholds 2026, VA funding fee) plus proposed_sentence; each dollar or percent figure is bound to the role named in its own clause (floor or ceiling, tier, first or subsequent use, threshold item) and compared with that cell, so a right number under the wrong role is a mismatch and an unbound number earns no receipt; every figure is also classified as current, superseded (STALE_VALUE), belonging to a different rule (VALUE_FROM_OTHER_RULE, e.g. the $726,200 MIP threshold quoted as a loan limit), or not in the table (VALUE_MISMATCH / UNVERIFIED_VALUE); the year, units, tier, use, down-payment band and stated dates are checked (a date before the rule's start blocks; a missing MIP case date is never assumed), and a passing sentence with at least one bound figure returns a verifiable rule receipt.

Input Schema

NameRequiredDescriptionDefault
passport_idYes
causal_assertionNo
legal_conclusionNo
proposed_sentenceNoThe exact sentence you intend to write. Checked with fixed patterns; no model.
qualifier_droppedNo
attribution_presentNo
individual_predictionNo
scope_beyond_universeNo
personalized_recommendationNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / proposed_sentence
      Added value: +{
      +  "description": "The exact sentence you intend to write. Checked with fixed patterns; no model.",
      +  "type": "string"
      +}
  2. Added

TDQS

A4.2/5.0
Behavior5/5

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

Adds substantial behavior beyond the annotations: 'deterministic verdict', 'checked with fixed patterns, no model', and enumerates the return values (pass / needs_qualifier / block with reason code, plus a verbatim safe sentence, required attribution, and rule receipt). The rule mode also enumerates misclassification codes (STALE_VALUE, VALUE_FROM_OTHER_RULE, VALUE_MISMATCH/UNVERIFIED_VALUE). This is rich context the annotations cannot carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded, but the bulk is dense, comma-spliced, parenthetical-heavy prose (mode C in particular is one long run-on). The content is largely useful, yet the packing makes it harder to scan than it needs to be. Efficient in word count but not in structure.

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

Completeness4/5

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

For a complex, no-output-schema tool the description is close to self-sufficient: it explains the verdict shape, reason codes, and the receipt, so an agent knows what comes back without an output schema. The main residual gap is the incomplete flag-to-parameter mapping given 11% schema coverage.

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?

Schema coverage is only 11% across 9 params, so the description must compensate. It maps several flags loosely (population, period, scope, cause, individual prediction, lender recommendation, legal conclusion) and mentions qualifier/attribution outcomes, but never explicitly links each named flag to its parameter (e.g. qualifier_dropped, attribution_present, scope_beyond_universe) nor explains the flag-vs-sentence precedence. Partial compensation only.

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?

States a precise verb+resource+scope: 'Checks a proposed statement of a FinanceRateCalc figure against that figure's published use contract'. An agent can immediately distinguish this checker from the data-fetching siblings (get_rule, resolve_fha_annual_mip, screen_counterparties). The three input modes further pin down what the tool operates on.

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?

Names the workflow position ('so the sentence can be verified before it is written') and gives an explicit exclusion: 'NOT FOR: figures published by anyone other than FinanceRateCalc'. It also disambiguates the three modes (flags, sentence, rule sentence) by input shape. It stops short of routing to a specific sibling tool, so it is strong but not a full when/when-not/alternative set.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.