Valuein — SEC EDGAR Fundamentals & Smart-Money Data

Save Citation Override

save_citation_override

Idempotent

Persist a correction of a citation value. The correction is keyed on the canonical fact_id (a stable hash of CIK + accession + concept + period) so it applies to every report that references that same fact — including agent-regenerated reports. Re-saving the same fact_id replaces the prior correction in place (no duplicate row).

The fact_id is VERIFIED against live SEC data (scoped to ticker) before the correction is stored — a fact_id that doesn't resolve to a real fact is rejected with INVALID_ARGUMENT (its resolution_error_code says why the lookup failed) and nothing is persisted. You therefore must supply the ticker the fact belongs to.

Use this when the user notices an inaccuracy in an AI-generated report and wants the fix to persist. Provide notes for the rationale (≤500 chars) and source_report_id for provenance. Flat 10,000-override anti-abuse cap per account (deleting frees a slot; never a tier limit).

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": {
      "fact_id": "<fact_id>",
      "corrected_value": "<corrected_value>",
      "ticker": "<ticker>"
    },
    "name": "save_citation_override"
  }
}

Input Schema

Name	Required	Description
`notes`	No	Optional free-form rationale, ≤500 chars.
`ticker`	Yes	Ticker the fact belongs to (REQUIRED) — scopes fact_id resolution against live SEC data and denormalises the row for fast filtering (the workspace UI's 'my corrections on AAPL' view).
`fact_id`	Yes	Canonical fact identifier — usually returned in a citation's `fact_ids` array by get_report or any compute tool. Stable across report regenerations. Verified against live SEC data (scoped to `ticker`) before persistence — a fabricated or unresolvable fact_id is rejected.
`corrected_value`	Yes	User-corrected value, stringified. The frontend interprets it based on the fact's known datatype (number, string, ISO date).
`source_report_id`	No	Optional report id the user was viewing when they applied the correction (provenance).

Output Schema

Name	Required	Description
`_meta`	Yes	Provenance envelope — data lineage for every MCP response
`created`	Yes
`capacity`	Yes
`override`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 11, 2026

removedOutput schema / properties / _meta / properties / price_as_of

Removed value: -{
-  "description": "ISO timestamp when the price surfaces were last refreshed.",
-  "type": "string"
-}

First observedNov 9, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare idempotentHint=true and destructiveHint=false, but the description adds substantial context beyond them: the fact_id is verified against live SEC data before persistence, failures return INVALID_ARGUMENT with a resolution_error_code and persist nothing, and there is a flat 10,000-override anti-abuse cap per account that is freed by deletion. It also confirms the in-place replacement behavior that the idempotency annotation only implies.

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 behavior, then verification semantics, then usage and limits — a sensible progression. There is mild redundancy: 'You therefore must supply the ticker' restates the ticker parameter description, and the uppercase 'VERIFIED' emphasis is stylistic rather than informative.

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 5-parameter mutation with an output schema (so return values needn't be explained), the description covers the trigger, persistence key, validation and failure mode, idempotent replacement, and quota behavior. An agent has everything needed to call it correctly and interpret failures.

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 baseline is 3. The description goes further by explaining that fact_id is a stable hash of CIK + accession + concept + period, that ticker is mandatory because it scopes verification, and that corrected_value is a stringified value the frontend interprets by datatype — useful cross-parameter meaning the schema only partially conveys.

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+resource ('Persist a correction of a citation value') and immediately explains the keying model (canonical fact_id derived from CIK + accession + concept + period). That distinguishes it cleanly from delete_citation_override and list_citation_overrides without needing their schemas.

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?

It gives a concrete trigger ('when the user notices an inaccuracy in an AI-generated report and wants the fix to persist') plus the update-vs-create rule ('Re-saving the same fact_id replaces the prior correction in place'). It stops short of explicitly naming a sibling as the alternative for the removal or listing cases, so it's clear context rather than full when/when-not routing.

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.