Revenue, profit, cash, debt and EPS for any US-listed company straight from SEC XBRL filings.
Scored across 3 tools
Each tool occupies a fairly distinct niche: key_financials is a single-company latest snapshot, history is a single-company time series, and compare is a multi-company cross-section. There is some overlap (history with one year/quarter largely reproduces key_financials, and compare aggregates metrics also available elsewhere), but descriptions make the intended use cases clear.
All three names are short, lowercase, un-prefixed and visually consistent, so the set reads cleanly. The only minor inconsistency is grammatical style: 'compare' is a verb while 'history' and 'key_financials' are nouns, and 'key_financials' is the only compound/underscored name.
Three tools is thin for a financial-data server, though each one earns its place (snapshot, trend, cross-company comparison). It sits at the borderline where an agent has no spare surface for adjacent needs like symbol lookup or screening.
The core retrieval pattern (latest, historical, comparative) is covered, but there are notable gaps: no company/ticker search or listing, no balance-sheet detail beyond assets and cash, no quarterly key_financials, and only limited derived ratios (net margin, growth). Agents will hit dead ends for valuation, segment, or symbol-resolution tasks.
PRO. Compare latest annual revenue, net margin, revenue growth, debt and cash across up to 10 companies.
| Name | Required | Description | Default |
|---|---|---|---|
| companies | Yes | ||
| access_token | No | Subscriber token from /success (or Authorization: Bearer) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose some useful traits, such as 'latest annual' data and a limit of up to 10 companies, but it omits whether the operation is read-only, authentication requirements beyond the vague 'PRO' label, rate limits, and return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The definition is a single, front-loaded sentence with no wasted words. It conveys the tool's scope and main constraint efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description is adequate: it names the metrics being compared and the 10-company cap. It still leaves the company identifier format and authentication details unclear, which are important gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%: access_token is documented in the schema, while companies has no schema description. The description partially compensates by saying 'up to 10 companies', but it does not explain the expected string format for each company, such as ticker versus company name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Compare') and lists concrete financial metrics, so the tool's purpose is immediately clear. It does not explicitly distinguish itself from the sibling tools history and key_financials, which keeps it from a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by 'Compare ... across up to 10 companies', suggesting this is the multi-company comparison tool. However, it never states when to use it instead of history or key_financials, nor does it give exclusions or prerequisites beyond 'PRO'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PRO. Up to 10 years (annual) or 12 quarters of revenue, net income, operating income, cash flow, debt, equity, EPS.
| Name | Required | Description | Default |
|---|---|---|---|
| period | No | annual (default) | quarterly | |
| company | Yes | ||
| access_token | No | Subscriber token from /success (or Authorization: Bearer) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It discloses the data range and premium ('PRO') nature but omits read-only status, authentication requirements beyond the schema, rate limits, error behavior, and return structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact, front-loaded sentence fragment with no wasted words. 'PRO.' is slightly cryptic but likely signals subscription access, and the core data scope is stated immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with no output schema and no annotations, the description covers the data scope and metrics but leaves gaps around return format, authentication behavior, and sibling differentiation. It is minimally sufficient to guide invocation but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%. The description adds useful meaning to the period parameter by stating maximum annual and quarterly periods, but does not explain the required company parameter or access_token beyond what the schema already says.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates historical financial data by listing metrics and time ranges (10 years annual or 12 quarters). It lacks an explicit verb and does not differentiate from siblings like key_financials or compare, but the resource is understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as key_financials or compare. The only contextual hint is 'PRO,' which suggests a subscription tier but not usage conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FREE. Latest annual revenue, net income, total assets and cash for a US-listed company (ticker or name) from SEC XBRL data.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the whole burden. It usefully discloses the upstream source (SEC XBRL) and that coverage is limited to US-listed issuers, which implies XBRL filing latency and restatement risk, but it says nothing about permissions, failure modes for unknown tickers, currency, or how quickly new filings appear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence with the cost signal front-loaded and the scope, metrics, and source packed into a single readable clause. Nothing redundant and nothing deferred to the end.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter lookup tool with no output schema this covers the essentials, but return shape (annual vs fiscal year end, currency, units) and identifier-matching behavior are left unstated. An agent knows what it will get at a high level but not what edge cases to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the single 'company' parameter would be opaque without the description; 'ticker or name' at least tells the agent both identifier forms are accepted. It does not say which format is preferred, how ambiguous names are resolved, or what happens on a miss, so the compensation is partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names the exact metrics returned (revenue, net income, total assets, cash), the scope (latest annual, US-listed), and the data source (SEC XBRL). It distinguishes itself from 'history' only implicitly via the word 'latest', so the sibling differentiation is not explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Latest annual' implies this is the snapshot tool and that time-series needs belong to 'history', but no alternative is named and there is no when-not-to-use guidance. The 'FREE' marker helps an agent weigh cost against the unnamed siblings, which is the only explicit routing signal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
comparehistorykey_financialsSEC XBRL financials, company lookup, Treasury yields, ECB FX, token prices, perp funding spreads.
Research U.S. public companies from their SEC filings: financials, XBRL facts and filing text.
Clean annual and quarterly company financials from official SEC EDGAR XBRL data.
SEC filings, financial statements, metrics, insider and institutional holdings as structured data
Add one secure layer between your agents and this server.
