Skip to main content
Glama

Valuein — SEC EDGAR Fundamentals & Smart-Money Data

Match Derived Figures

match_derived
Read-onlyIdempotent

Check whether figures a report STATES can be reproduced by the engine from the SEC facts the report cites. For each { token, ticker, fact_ids } it tries every registered margin, growth, share-of, difference and ratio formula over those facts and compares the rendered result to your token EXACTLY. Use it for a figure that has no fact_id or derived_id of its own (the model worked it out, or retyped it) — never to invent a figure.

Per item: cited (your token is an exact quote of one cited fact's display: cite that fact_id), derived (exactly one formula reproduces it: cite the returned derived_id like a fact_id), reformatted (your token is a rounding of a cited fact such as "$403B" for "$402.83B": quote the returned display instead), ambiguous (two or more different formulas reproduce it: a person must choose, never auto-pass), none (nothing reproduces it: treat as unsupported) or error (the cited facts could not be read).

Up to 50 items per call, each with 1–20 cited fact_ids (64-char hex, from a tool result) of ONE company; at most 5 distinct companies per call (chunk larger sets). Every fact is read from your own plan's data; as_of_date (YYYY-MM-DD) drops facts accepted after it. Read-only; available on all plans.

Input Schema

NameRequiredDescriptionDefault
itemsYesThe figures to check, 1–50; one call per report, not one per figure.
as_of_dateNoPoint-in-time cut (YYYY-MM-DD): a cited fact accepted after this date is not used.

Output Schema

NameRequiredDescriptionDefault
_metaYesProvenance envelope — data lineage for every MCP response
resultsYesOne entry per item, in the order sent.
summaryYesCounts of each outcome over `results`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedOutput schema / properties / results / items / properties / rounded
      Added value: +{
      +  "description": "outcome derived: true when the token is a rounding (2+ significant digits) of `display`, the engine's unrounded figure.",
      +  "type": "boolean"
      +}
  2. Changed5 schema fields changed
    • addedOutput schema / properties / results / items / properties / fact_id
      Added value: +{
      +  "description": "outcome cited: the cited fact whose display the token quotes exactly.",
      +  "type": "string"
      +}
    • changedOutput schema / properties / results / items / properties / outcome / description
      Previous value: -"derived = exactly one candidate reproduces the token; reformatted = the token is a rounding of a cited fact or derived figure, quote `display` instead; ambiguous = two or more different candidates reproduce it; none = nothing reproduces it; error = the cited facts could not be read."New value: +"cited = the token is an exact quote of exactly one cited fact's display; derived = exactly one candidate reproduces the token; reformatted = the token is a rounding of a cited fact or derived figure, quote `display` instead; ambiguous = two or more different candidates reproduce it; none = nothing reproduces it; error = the cited facts could not be read."
    • changedOutput schema / properties / results / items / properties / outcome / enum
      Previous value: -[
      -  "derived",
      -  "reformatted",
      -  "ambiguous",
      -  "none",
      -  "error"
      -]New value: +[
      +  "cited",
      +  "derived",
      +  "reformatted",
      +  "ambiguous",
      +  "none",
      +  "error"
      +]
    • addedOutput schema / properties / summary / properties / cited
      Added value: +{
      +  "type": "number"
      +}
    • changedOutput schema / properties / summary / required
      Previous value: -[
      -  "items",
      -  "derived",
      -  "reformatted",
      -  "ambiguous",
      -  "none",
      -  "error"
      -]New value: +[
      +  "items",
      +  "cited",
      +  "derived",
      +  "reformatted",
      +  "ambiguous",
      +  "none",
      +  "error"
      +]
  3. Changed1 schema field changed
    • changedOutput schema / properties / _meta / properties / cost_usd / properties / basis / description
      Previous value: -"payg_charge = real charge (agent-pay or your balance). payg_rate_card = indicative price, not billed."New value: +"payg_charge = real pay-per-call charge (a card or MPP payment through agent-pay). payg_rate_card = indicative price, not billed."
  4. Changed2 schema fields changed
    • changedOutput schema / properties / _meta / properties / cost_usd / properties / basis / description
      Previous value: -"payg_charge = real agent-pay charge. payg_rate_card = indicative price, not billed."New value: +"payg_charge = real charge (agent-pay or your balance). payg_rate_card = indicative price, not billed."
    • changedOutput schema / properties / _meta / properties / cost_usd / properties / billed / description
      Previous value: -"true = this amount was actually charged via PAYG for this call. false = indicative PAYG-equivalent value; your plan already covers this call for free."New value: +"true = this amount was actually charged via PAYG for this call. false = indicative PAYG-equivalent value only: no charge was made for this call (it was within your plan)."
  5. Added

TDQS

A4.6/5.0
Behavior5/5

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

Goes well past the readOnly/idempotent annotations by explaining exact-match comparison semantics, the full outcome taxonomy (cited, derived, reformatted, ambiguous, none, error) with the required follow-up action for each, and the warning that ambiguous results must never be auto-passed. Plan availability and per-call/per-company caps are also disclosed.

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?

Front-loaded with the core purpose in the first clause, then limits, then the outcome taxonomy; every section carries information an agent needs. The result is dense and long, but no sentence is filler.

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?

An output schema exists so return shape need not be restated, yet the description still tells the agent how to interpret each outcome and what to do next. Combined with the parameter constraints, nothing needed to call this correctly is missing.

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 3; the description still adds meaning by explaining that fact_ids must be 64-char hex from a tool result and all belong to ONE company, that the cited facts must be read from the caller's own plan data, and what as_of_date actually excludes (facts accepted after that date).

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 specific verb and resource: check whether stated figures are reproducible by the engine from cited SEC facts, comparing rendered results to the token exactly. It also carves out its niche against the fact-verification siblings by restricting itself to figures with no fact_id or derived_id of their own.

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?

Explicit about when to use it (model-derived or retyped figures) and when not to ('never to invent a figure'), plus hard limits of 50 items and 5 companies per call. It does not name a sibling such as verify_facts or verify_report_figures as the alternative for figures that do have fact_ids, leaving that boundary to inference.

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.