FinancialMD

Verify a number against the filing

verify_value

Read-onlyIdempotent

Check a number you have (from a model, a news story, a spreadsheet or memory) against what the company filed. Give the company, the concept (a concept_id or fiscal alias from metrics_list, for example revenue or net_income), the period (fiscal_year plus fiscal_period, or a period string such as "FY2024", "Q4 2024" or a period end date) and the value in whole currency units; FinancialMD returns the filed value object with its proof, the delta (absolute and percent), the tolerance (half a unit at the filed precision), a scale_hint when the number would match after a power-of-ten scale (millions given as units), and a verdict: matches, differs, or unknown (company and concept exist but no fact matches the period). Optionally name the source so the audit trail records it, and as_of to verify against what was known on a date. Metered call: 1 of 25 keyless calls a day. Free through this connector within the keyless limits; the per-call price on agent.financial.md is $0.02. Use it before repeating a figure that came from a model, an article or memory. If a dataset, field, company or analysis you need is missing, call request_data.

Example tool call

This call uses example arguments supplied in the tool’s input schema.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "value": 391035000000,
      "source": "analyst note",
      "company": "ticker:AAPL",
      "concept": "revenue",
      "fiscal_year": 2024,
      "fiscal_period": "FY"
    },
    "name": "verify_value"
  }
}

Input Schema

Name	Required	Description
`as_of`	No	Knowledge date or timestamp (YYYY-MM-DD or RFC 3339). The answer is what FinancialMD knew at that instant: only facts whose known interval contains as_of. Omit for the current view.
`value`	Yes	The number to check, in the concept's base unit (whole currency units, not millions).
`period`	No	Alternative to fiscal_year and fiscal_period: "FY2024", "Q4 2024", "2024Q4", or a period end date "2024-09-28".
`source`	No	Optional: where your number came from, recorded in the audit trail.
`company`	Yes	Company identifier: a FinancialMD id ("fmd_01H..."), an SEC CIK ("cik:320193"), or a ticker ("ticker:AAPL", optionally with the MIC "ticker:AAPL.XNAS"). A bare ticker like "AAPL" is accepted and sent as ticker:AAPL.
`concept`	Yes	Concept id or fiscal alias from metrics_list, for example revenue, net_income, total_assets, free_cash_flow.
`fiscal_year`	No	Fiscal year of the period to check (use with fiscal_period, or give period instead).
`fiscal_period`	No	Fiscal period label: FY, Q1 to Q4 (or H1, H2). Defaults to FY when fiscal_year is given alone.

Output Schema

Name	Required	Description
`data`	No	{ verdict, submitted { value, source }, filed (value object with proof) or null, delta { absolute, percent } or null, tolerance, scale_hint, concept { concept_id, label } }.
`meta`	No	Request metadata: request_id, as_of, company resolution, coverage, pipeline_version, licence, terms, proof_base.
`error`	No	Present only on isError results: the API error code and message plus remedy hints.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 13, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Beyond the readOnly/idempotent annotations, the description discloses the verdict taxonomy (matches, differs, unknown), the half-unit tolerance rule, the scale_hint behavior for power-of-ten mismatches, the audit-trail recording of source, and metering/pricing (1 of 25 keyless calls per day, $0.02 per call). That is substantial behavioral context an agent cannot get from annotations alone.

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 body is a single dense run-on sentence mixing input instructions, return semantics, and pricing. Metering is stated three times in overlapping ways ('1 of 25 keyless calls a day', 'free within the keyless limits', '$0.02 per call'), which is redundant 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?

For an 8-parameter verification tool the description covers required inputs, the semantics of the verdict, tolerance and scale behavior, the audit-trail effect of source, and the fallback path for missing data. Nothing an agent needs to invoke it correctly is absent, and an output schema exists for the detailed return shape.

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 description coverage is 100%, so every parameter is already documented in structured form; the description largely restates it (concept from metrics_list, period formats, whole currency units, as_of). It does add a little connective guidance on period versus fiscal_year/fiscal_period, but below the threshold for a 4.

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 a supplied number against what the company filed, and names the returned artifacts (filed value object with proof, delta, tolerance, verdict). It is clearly distinguishable from data-fetching siblings like filing_facts or proof_get, since this one takes a value as input and adjudicates it.

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?

Gives concrete triggers ('before repeating a figure that came from a model, an article or memory') and routes to metrics_list for concept identifiers and request_data for missing data. It stops short of stating when NOT to use it versus alternatives such as filing_facts, so it lands at clear-context rather than full when/when-not coverage.

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

All FinancialMD 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.

Resources

Need Help?