Skip to main content
Glama
Sign In

Finbolt

by com.getfinbolt
OverviewDiscussionsAdmin

restatement_history

Figures that a later SEC filing changed: the value as first filed, the latest value, the change in percent, and which one get_fact gives you. Most changes are recasts (a new accounting rule, a reclassification or a discontinued business shown again on the new basis), not corrections of errors. amended: true marks a change from an amended filing. Covers the main lines of the income statement, balance sheet and cash flow statement for up to 8 years, or any line you name. Not listed: rounding, stock-split rebasing, a sign flipped by tagging, a 1,000-times scale fix, and a full-year figure tagged with a quarter's value. 1 credit. The main lines checked are: revenue, total_revenues, total_net_revenue, cost_of_revenue, gross_profit, selling_general_admin, research_and_development, operating_income, interest_expense, net_interest_income, noninterest_income, noninterest_expense, provision_for_credit_losses, premiums_earned, benefits_and_losses, net_investment_income, pretax_income, income_tax, net_income, eps_basic, eps_diluted, diluted_shares_weighted, total_assets, total_liabilities, stockholders_equity, cash, long_term_debt, loans_net, deposits, operating_cash_flow, investing_cash_flow, financing_cash_flow, capital_expenditure, depreciation_amortization, dividends_paid, share_repurchases.

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": "restatement_history"
  }
}

Input Schema

NameRequiredDescriptionDefault
as_ofNoOptional date: the history as it was on file then
yearsNoFiscal years back from the latest on file, 1 to 8
companyYesTicker (e.g. 'AAPL') or SEC CIK
conceptNoOptional line item such as 'revenue' or 'net_income'; left out, the main lines listed below are checked

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4/5.0
Behavior4/5

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

With no annotations, the description must carry the whole behavioral burden and it does much of it: cost (1 credit), coverage depth (8 years), what the amended flag means, the recast-vs-correction semantic, and a concrete exclusion list for spurious diffs. It leaves out result ordering, behavior when as_of is set, and any failure modes, so 4 rather than 5.

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?

The first sentence is front-loaded and the exclusions are tight, but the 36-item list of line items is a heavy block that consumes most of the text. It is justified by the schema's forward reference ('listed below') and by disambiguating the concept parameter, yet the same information could have been placed in the concept field's schema description.

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?

An output schema exists, so explaining return fields is not required, and the description still previews them. For a 4-parameter read tool with full schema coverage, the only real gap is how as_of interacts with the returned history and whether results are ordered chronologically.

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 coverage is 100%, so the baseline is 3. The description adds some meaning — it enumerates the main lines checked for concept, which compensates for the schema's vague 'such as' phrasing — but it says nothing about as_of's semantics beyond the schema, so it does not clearly exceed baseline.

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 opening line names the resource precisely — figures a later SEC filing changed — and enumerates what comes back (as-first-filed value, latest value, percent change, amended flag). It distinguishes itself from get_fact by explaining which of the two values that sibling returns, so an agent can tell the tools apart without opening 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 establishes when the tool is meaningful (recasts from new accounting rules, reclassifications, discontinued businesses) and warns that most hits are not error corrections, which shapes interpretation. It also enumerates what is deliberately NOT reported, so the agent knows not to hunt for rounding or split adjustments here. It stops short of naming an explicit alternative for the current-value case, but the get_fact reference implies the routing.

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

All Finbolt toolsInspect
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