Skip to main content
Glama

Company financials (SEC filings)

company_financials
Read-only

A US-listed company's reported numbers, from the financial data tagged in its SEC filings (10-K and 10-Q; not the reports' text, which is filing_text): revenue, gross and operating profit, net income, diluted EPS, operating cash flow, capital spending, free cash flow, R&D, cash, long-term debt, assets, liabilities, equity and share count, for the last few fiscal years or quarters, with growth and net margin, and its latest filings (10-K, 10-Q, 8-K with item numbers). Every value links to the filing it came from. Look a company up by ticker (AAPL), name or SEC CIK. Use for 'how is X doing', 'is X profitable', 'how much debt does X have', due diligence on a public company. Only companies that file with the SEC; not private companies or crypto projects.

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

Input Schema

NameRequiredDescriptionDefault
periodNoDefault annual
companyYesTicker (AAPL), company name, or SEC CIK
periodsNoHow many periods, default 4, max 8

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnlyHint and openWorldHint; the description adds substantial context beyond them — data provenance (XBRL-tagged 10-K/10-Q values), traceability ("every value links to the filing it came from"), including 8-K item numbers, and the SEC-filer population limit. These are exactly the facts an agent needs to trust and interpret the output.

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 what the tool returns, then usage and exclusions — a sensible order. The metric enumeration is long and reads as a dense run-on list, but each item adds retrieval value, and the parenthetical aside about filing_text is placed where it prevents misuse.

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 read-only lookup tool with a simple 3-parameter schema and no output schema, the description pre-explains the response shape (metrics plus growth/margin plus latest filings), identifier formats, and population limits. Nothing material is missing for correct invocation.

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% with defaults and the annual/quarterly enum documented, so the baseline is 3. The description still adds value by clarifying that `company` accepts a ticker, name, or SEC CIK and that results span "the last few fiscal years or quarters," reinforcing the periods/period semantics without contradicting the defaults (4, max 8).

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 with scope: reported financials from SEC-tagged data, enumerating the exact metrics returned (revenue, operating cash flow, debt, equity, share count) plus latest filings. It explicitly distinguishes itself from the sibling filing_text ("not the reports' text, which is filing_text"), so an agent can route correctly without opening either schema.

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?

Gives concrete use cases ("how is X doing", "is X profitable", "how much debt does X have", due diligence) and hard exclusions ("only companies that file with the SEC; not private companies or crypto projects"). It also names the alternative for report text, covering both when-to-use and when-not-to.

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.