Valuein — SEC EDGAR Fundamentals & Smart-Money Data

Verify Facts (batch)

verify_facts

Read-onlyIdempotent

Resolve MANY cited facts to their SEC filings in ONE call — the batch form of verify_fact_lineage. Use this whenever you are checking a LIST of figures rather than a single number: reviewing a report's citations, auditing a thesis's evidence, or confirming every figure in a draft before you sign it. A 30-figure report is one call here and 30 calls with verify_fact_lineage.

Use verify_fact_lineage INSTEAD when you have one figure, or when you do not have a fact_id and need the concept-name lookup (concept + as_of_date) — this tool resolves by fact_id only.

A MISS IS DATA, NOT A FAILURE: each item comes back found:true with its full lineage, or found:false with an error code and message. One unresolvable fact_id never costs you the other verdicts, so read every item — summary gives you requested / found / missing at a glance.

Duplicate (ticker, fact_id) pairs are collapsed before anything is read, so summary.requested counts UNIQUE pairs and may be lower than the number of entries you sent; results come back in first-seen order. Maximum 50 facts per call.

Never state a figure this tool returned found:false for, and never fabricate a lineage it did not return. Available on all plans; each fact is subject to the same tier reach as verify_fact_lineage.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`facts`	Yes	The facts to verify, 1–50 of them. Group a report's whole citation list here rather than calling once per figure. Duplicate (ticker, fact_id) pairs are resolved once and returned once, in first-seen order.

Output Schema

TableJSON Schema

Name	Required	Description
`_meta`	Yes	Provenance envelope — data lineage for every MCP response
`results`	Yes	One entry per UNIQUE requested pair, in first-seen order. Check `found` before reading `lineage`.
`summary`	Yes	Counts over `results`. Quote `missing` when reporting coverage — it is the number of figures you could NOT tie to a filing.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 18, 2026

changedOutput schema / properties / _meta / properties / fundamentals_as_of / description

Previous value: -"ISO timestamp when the FINANCIAL STATEMENTS were last rebuilt. Use THIS — not `last_updated` — when telling a user how current the fundamentals are. The snapshot is republished on every weekday price refresh while the statements are carried forward unchanged, so `last_updated` can be far more recent than the numbers it sits next to."New value: +"ISO timestamp when the FINANCIAL STATEMENTS were last rebuilt in bulk. Use THIS — not `last_updated` — when telling a user how current the cross-sectional fundamentals are. The snapshot is republished on every weekday price refresh while the statements are carried forward unchanged, so `last_updated` can be far more recent than the numbers it sits next to. It is a floor for a single filer, not a ceiling: a filer with a live partition receives its filing, facts and ratios intraday (minutes after EDGAR dissemination), so an entity-scoped read may carry a filing newer than this; cross-sectional ranks (factor scores, earnings signals) refresh with the weekly bulk export."

AddedSep 16, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already mark this as readOnly, idempotent, and non-destructive, and the description adds substantial behavioral context beyond those: per-item found:true/found:false semantics, partial batch success, duplicate collapse with first-seen ordering, summary counts, the 50-fact limit, and clear integrity constraints about never stating found:false figures or fabricating lineage. This is rich, non-obvious behavior that an agent genuinely needs to invoke and interpret the tool correctly.

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

Conciseness5/5

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

Though longer than average, every sentence earns its place: purpose is front-loaded, usage caveats are clearly separated, and behavioral caveats are grouped into digestible chunks. The formatting with emphasis and short paragraphs preserves scannability despite the density.

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?

For a batch verification tool with one structured parameter and an existing output schema, the description covers all essential context: when to use it, when not to, partial-failure behavior, dedupication, ordering, limits, and the hard rule never to fabricate lineage. Nothing critical is left for the agent to infer.

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 description coverage is 100% and the schema already provides detailed semantics for ticker and fact_id, including patterns and the deterministic hash formula. The description adds useful batch-level param semantics: duplicates are collapsed, summary.requested counts unique pairs, results are in first-seen order, and the maximum is 50 per call. This goes beyond the schema without repeating it.

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?

The description opens with a specific verb and resource: 'Resolve MANY cited facts to their SEC filings in ONE call.' It explicitly identifies itself as the batch form of verify_fact_lineage and distinguishes itself by fact_id-only resolution, so an agent can differentiate it from its sibling immediately.

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

Usage Guidelines5/5

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

It gives explicit when-to-use guidance (checking a LIST of figures, reviewing citations, auditing a thesis, confirming a draft) and when-not-to-use guidance (one figure, or needing concept-name lookup without a fact_id). It names the alternative tool verify_fact_lineage and the conditions that select it, leaving no ambiguity.

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

All Valuein — SEC EDGAR Fundamentals & Smart-Money Data tools Inspect

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.