Skip to main content
Glama

verify

Check the figures in a memo against SEC filings. Each claim gets one verdict: supported, supported_rounded, period_mismatch, contradicted, ambiguous, not_in_primary_sources or skipped. Returns record_id, counts by verdict, each contradicted claim (memo value vs filed value, period, accession, and the error when it is a unit or sign error) and how_to_read. Every call is written to your account's append-only Record; call verify_evidence with the record_id for each claim's full evidence.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "company": "<company>"
    },
    "name": "verify"
  }
}

Input Schema

NameRequiredDescriptionDefault
agentNoThe model and version that wrote the memounknown
claimsNoUp to 50 claims you parsed, each {claim_id, span (the verbatim clause), type 1-6 (1 reported, 2 derived, 3 company_disclosed, 4 market, 5 estimate, 6 forward_looking), concept, value or stated (e.g. '$94.9bn'), unit (USD, shares, USD/shares, pure, percent), period (the memo's phrase), precision}; type 4 also takes price and price_date. Give claims or sentences, not both
companyYesTicker (e.g. 'AAPL') or SEC CIK of the company the memo is about
memo_dateNoThe memo's date, e.g. '2026-06-30': figures are read as they were on file that day
sentencesNoInstead of claims: up to 50 memo sentences, parsed for you, with ids C1..Cn
input_textNoOptional: the prompt. On the Fund plan it is kept encrypted in your Record; on other plans it is not kept.
output_textNoOptional: the memo. On the Fund plan it is kept encrypted in your Record; on other plans it is not kept.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / input_text / description
      Previous value: -"Optional: the prompt, stored encrypted in your Record"New value: +"Optional: the prompt. On the Fund plan it is kept encrypted in your Record; on other plans it is not kept."
    • changedInput schema / properties / output_text / description
      Previous value: -"Optional: the memo, stored encrypted in your Record"New value: +"Optional: the memo. On the Fund plan it is kept encrypted in your Record; on other plans it is not kept."
  2. Added

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses that every call is written to an append-only Record, lists the possible verdicts, describes the return payload (counts, contradicted claims with memo vs filed value, accession), and explains that input_text/output_text retention is plan-dependent. Missing pieces are rate limits, cost, and authentication requirements.

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 action, then the verdict list, then the record/verify_evidence workflow. The enumeration of seven verdicts is dense but earns its place as it defines the contract; a minor trim would improve scanability.

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 7-parameter verification tool with an output schema, the description covers the workflow, the side effect (append-only Record), data retention, and the escalation path to verify_evidence. Remaining gaps are operational details (limits, auth) rather than conceptual ones.

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, but the description adds meaning beyond the schema: the exclusive choice between claims and sentences, the sense of the verdict vocabulary, and what record_id enables downstream. It does not restate field-level detail, which is correct given the rich schema.

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 the figures in a memo against SEC filings') and immediately names the verdict taxonomy that defines the output. It is clearly distinguishable from siblings like verify_evidence (which returns per-claim evidence) and the fetch_* financial data tools.

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?

The description makes the core use case clear (auditing memo claims against filings) and explicitly routes follow-up work to verify_evidence with the record_id. The phrase 'Give claims or sentences, not both' is a useful mutual-exclusion rule, but there is no explicit when-not-to-use guidance or statement of prerequisites/plan requirements.

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.

Resources