Company financials from official filings, each figure keyed to its filing date.
Scored across 5 tools
Each tool has a clearly stated and largely separate role: coverage/metadata, data dictionary, latest snapshot, historical series, and ticker lookup. The only mild overlap is between get_latest_fundamentals and get_fundamentals_history, since 'latest' can often be derived from history, but the descriptions explicitly steer usage (current figures vs. trends/as-of) so misselection risk is low.
All names follow a predictable verb_noun pattern: get_coverage, get_data_dictionary, get_fundamentals_history, get_latest_fundamentals, search_companies. The single 'search' verb is appropriate for the lookup tool and still fits the convention.
Five tools is well-scoped for a read-only fundamentals data API: discovery (coverage, dictionary, company search) plus two data-retrieval entry points. No tool feels redundant or missing at this granularity.
The surface covers the full read lifecycle: find a company, learn what metrics exist and mean, then pull latest or historical figures with as-of dating and licence/attribution handling. Minor gaps exist — no multi-ticker/bulk comparison or explicit metric-listing endpoint (metric discovery is embedded in coverage/dictionary) — but agents can work around these.
Markets covered, company counts, history depth per market, the companies that answer with full history without a licence key (full_history_sample), the metric vocabulary, the source attributions that must travel with the data, and the licence the data is supplied under (for a time-limited key, its terms and end date). compact (true) leaves out the per-market notes and accounting descriptions.
| Name | Required | Description | Default |
|---|---|---|---|
| compact | No | true leaves out the long per-market notes (market_notes, schema) to save tokens; default false |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: it discloses that source attributions 'must travel with the data' (a licensing obligation on downstream use) and that a time-limited key carries terms and an end date.
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?
A single dense sentence with the headline content (markets covered, company counts) front-loaded, and the only parameter behavior moved to the end. It is long but nearly every clause names a distinct returned artifact, so little is wasted.
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?
There is no output schema, so the description must carry the return-value burden, and it does so thoroughly, listing each section of the payload plus the licence caveat. The only real gap is not saying how to use the result or how it differs from get_data_dictionary.
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?
With one parameter and 100% schema description coverage, the baseline is 3. The description restates the compact effect, but its phrasing ('per-market notes and accounting descriptions') only loosely matches the schema's 'market_notes, schema', so it adds little meaning beyond what the schema already provides.
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 enumerates exactly what the tool returns: markets covered, company counts, history depth, full_history_sample, metric vocabulary, source attributions, and licence terms. That is far more specific than a tautology, but it is a bare noun list with no verb and it does not distinguish itself from get_data_dictionary, which the mention of 'the metric vocabulary' partially overlaps with.
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 explicit statement of when to call this versus the siblings. Usage is only implied by the content list (call it to learn what data exists before querying) and by the compact note implying a token-saving call pattern. No exclusions or named alternatives are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The data dictionary of the detailed line items: for every metric, its definition, which filed line each market reads it from (or why a market has none), and the measured share of that market's company-periods that carry it; the figures we calculate from them, with their formulas; and the rules that apply to all of them (dating, signs, annual-only cash-flow lines, small employers). Use it before comparing a line item across markets, or to learn what a line-item code means. It also defines company.industry and company.status (the register's industry code and legal status, with source and dates), per market. Codes: trade_receivables, trade_and_other_receivables, inventories, trade_payables, trade_and_other_payables, ppe, noncurrent_assets, current_assets, current_liabilities, retained_earnings, depreciation_amortization, interest_expense, cash_flow_operating, capex, minority_interest, temporary_equity, land_and_buildings, land, buildings, pension_provisions, cost_of_materials, purchases_of_goods, purchases_of_materials, wages_and_salaries, operating_taxes, income_tax; calculated: free_cash_flow, working_capital, current_ratio, ebitda.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive, closed-world, so safety needs no restating. The description adds real behavioral context beyond that: it explains that missing lines are explained per market, that coverage shares are quantified, and that global rules (dating, signs, annual-only cash-flow lines, small employers) are included. It does not indicate response size or that the call is unfiltered and therefore returns everything.
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 opening sentence is well front-loaded and states the resource and its four components efficiently. However, the final two-thirds is a long comma-separated inventory of ~26 line-item codes plus 4 calculated codes, which is dense, hard to scan, and largely discoverable from the tool's own output; it dilutes the structure of an otherwise tight definition.
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?
With no output schema, the description carries the burden of describing returns, and it does so thoroughly: contents, per-market sourcing, coverage measurement, formulas, and shared rules. What is missing is any sense of scope or size (all markets, all metrics in one payload) that would help an agent plan around the response.
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?
The tool takes zero parameters, which is the baseline-4 case, and the empty schema leaves nothing to interpret. The trailing code inventory usefully enumerates the identifiers the dictionary defines, which pre-answers the agent's question of whether a code exists, though it is not a parameter in the schema.
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 names the exact resource (the data dictionary of detailed line items) and enumerates its contents: per-metric definitions, the source filed line per market, the measured share of company-periods carrying it, calculated figures with formulas, and cross-cutting rules. It also states that company.industry and company.status are defined here, so an agent can distinguish this metadata tool from get_latest_fundamentals or get_fundamentals_history without opening a schema.
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 stated concretely: 'Use it before comparing a line item across markets, or to learn what a line-item code means.' That gives a clear triggering condition. It stops short of naming alternatives (e.g., get_coverage) or saying when not to call it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The stored figures for one ticker, one row per metric and period, each with its period (fy, fp), period end, filing date and form. Use it for trends and for what was on file at a past date. Inputs: ticker, metric (comma-separated), from (earliest period end), as_of (only filings dated on or before that day), max_rows (1-250, default 250), compact (true leaves out market_notes and schema). Without a licence key, a company outside the full-history sample answers with its most recent reported fiscal year only: full_history false and history_depth say so, and older filings exist. Long histories are capped at max_rows, keeping the most recent rows of EVERY metric (per_metric says how many of each); metric and from select older rows. Figures are as filed, each keyed to its filing date (filed) as its market records it (how each market dates a filing: https://www.tradingagentapp.com/fundamentals/methodology). .TW quarterly values are already SINGLE-QUARTER amounts, so differencing adjacent quarters gives wrong figures. For a quarterly row (US, Taiwan) fy and fp are the CALENDAR quarter containing the period end, not the company's fiscal quarter. Each reply's market_notes and schema state the per-market caveats (solo or group accounts, lawful gaps, charities, flags in form). Detailed line items follow local accounting rules and keep the filed sign (capex is negative in Taiwan and Japan); get_data_dictionary defines them per market. The source licences require each reply's attribution and licence notices to accompany the figures.
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Earliest period end to include, YYYY-MM-DD | |
| as_of | No | Filing-date cut-off, YYYY-MM-DD: only filings dated on or before that day | |
| metric | No | Comma-separated metrics, e.g. revenue,net_income | |
| ticker | Yes | Ticker symbol, e.g. AAPL or 2330.TW | |
| compact | No | true leaves out the long per-market notes (market_notes, schema) to save tokens; default false | |
| max_rows | No | Most rows to return, 1-250 (default 250); every metric keeps its most recent rows |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare a safe, idempotent, closed-world read; the description goes well beyond them, disclosing the unlicensed-tier limitation (full_history false, truncated to the latest fiscal year), the max_rows truncation contract per metric with per_metric counts, TW single-quarter semantics, calendar-quarter fy/fp for US/Taiwan, signed capex in TW/JP, and the licence obligation to surface attribution and licence notices.
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 purpose and main caveats are front-loaded and nearly every sentence carries real information. It is, however, a single dense block with an 'Inputs: ...' enumeration that partly duplicates the schema, and some market caveats could be delegated to the referenced methodology page.
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 six-parameter, no-output-schema tool with heavy per-market quirks, the description supplies the licensing gate, truncation behavior, row semantics, and legal attribution requirement, and points to the methodology URL and get_data_dictionary for the rest. An agent has enough to call it correctly and interpret the result honestly.
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 100%, so baseline is 3; the description earns a bump by explaining behavior the schema does not: max_rows keeps the most recent rows of EVERY metric and per_metric reports counts, compact drops market_notes and schema, and as_of filters on filing date rather than period end. It largely restates the input list, so it stops short of 5.
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 opening states a concrete resource and shape: 'The stored figures for one ticker, one row per metric and period, each with its period (fy, fp), period end, filing date and form.' It clearly implies the historical counterpart to the live fundamentals tool, but never names get_latest_fundamentals, so differentiation from the sibling relies on inference.
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?
Explicit use cases are given ('Use it for trends and for what was on file at a past date'), plus concrete guidance on when rows are dropped and how metric/from recover older rows. What's missing is a named alternative for point-in-time latest values (get_latest_fundamentals) or a pointer to get_data_dictionary for metric names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The most recent reported value of each metric for one ticker, each with its period (fy, fp), period end, filing date and form. Use it for a company's current figures, or with as_of for what had been filed by a given day. search_companies maps a company name to its ticker. Inputs: ticker (e.g. AAPL, 2330.TW, 005930.KS, 0403091220.BE, 775670417.FR, CC21860.NZC, and 10238429.EE, 5560356163.SE, 47239255.SK, 40003032949.LV where get_coverage lists them, and 96002925948.AU for Australia's tax figures); metric (comma-separated; a name we do not hold is listed in metrics_not_found); as_of (only filings dated on or before that day); compact (true leaves out market_notes and schema). Without a licence key, a company outside the full-history sample answers from its most recent reported fiscal year only (history_depth says so) and as_of is not available. Each metric is its own latest value, so two metrics can come from different periods; a quarterly fp is ONE quarter's figure, not a year; check stale (true: the company has filed since without this metric, so the figure is not current). Figures are as filed, each keyed to its filing date (filed) as its market records it (how each market dates a filing: https://www.tradingagentapp.com/fundamentals/methodology). .TW quarterly values are already SINGLE-QUARTER amounts, so differencing adjacent quarters gives wrong figures. For a quarterly row (US, Taiwan) fy and fp are the CALENDAR quarter containing the period end, not the company's fiscal quarter. Each reply's market_notes and schema state the per-market caveats (solo or group accounts, lawful gaps, charities, flags in form). Detailed line items follow local accounting rules and keep the filed sign (capex is negative in Taiwan and Japan); get_data_dictionary defines them per market. The source licences require each reply's attribution and licence notices to accompany the figures.
| Name | Required | Description | Default |
|---|---|---|---|
| as_of | No | Filing-date cut-off, YYYY-MM-DD (e.g. 2022-01-01). Defaults to today. | |
| metric | No | Comma-separated metrics, e.g. revenue,net_income. Omit for all. | |
| ticker | Yes | Ticker symbol, e.g. AAPL or 2330.TW | |
| compact | No | true leaves out the long per-market notes (market_notes, schema) to save tokens; default false |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, it discloses licence-key limits (non-sample companies answer from the latest fiscal year only, history_depth says so, as_of unavailable), the stale flag, per-market filing-date conventions, attribution/licence obligations, and sign conventions. These are exactly the operational caveats an agent needs and none are derivable from annotations.
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 purpose and the as_of guidance are front-loaded, which is good, but the body is a single dense paragraph. The sprawling parenthetical of nine exotic tickers and the trailing notice about market_notes/schema and attribution could be trimmed without losing agent-relevant information.
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 4-parameter read tool with no output schema, it covers return-shape fields, per-metric period independence, the quarterly-vs-fiscal-quarter trap, .TW single-quarter values, licence-tier behavior and stale detection. Nothing an agent needs in order to call and interpret it correctly is missing.
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 100%, so the 3 baseline is already met, and the description adds real meaning: unknown metric names are surfaced in metrics_not_found, as_of means 'only filings dated on or before that day,' and compact omits market_notes and schema. The long ticker example list is informative but largely redundant with the schema's example.
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 opening states a specific verb and resource: 'The most recent reported value of each metric for one ticker,' plus the per-row fields (period, fiscal period, period end, filing date, form). 'Most recent' implicitly contrasts with the sibling get_fundamentals_history, but it never names that tool explicitly, so sibling differentiation is left partly to inference.
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?
It gives clear when-to-use guidance: 'Use it for a company's current figures, or with as_of for what had been filed by a given day.' It also points to search_companies for name-to-ticker resolution. It stops short of explicit exclusions such as 'for historical series use get_fundamentals_history instead,' which would make it a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up the ticker for a company name or partial symbol — 'Apple', 'TSMC', '2330', 'samsung', 'LVMH'. Returns up to 8 matches, each with its ticker, name and market; a local subsidiary or a namesake in another country can share a name, and the market tells them apart. market (US, JP, TW, KR, FR, BE, DK, EE, SE, SK, LV, AU, NZC) limits the search to one market. Results with market NZC are New Zealand registered charities, not companies.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Company name or partial ticker | |
| market | No | Only this market: US, JP, TW, KR, FR, BE, DK, EE, SE, SK, LV, AU, NZC |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly=true, destructive=false, idempotent=true), so the description earns credit for going further: it discloses the result cap of 8 matches, the shape of each result (ticker, name, market), and the ambiguity risk of shared names. The NZC-are-charities caveat is genuinely non-obvious context an agent could not otherwise infer. It does not note behavior for zero matches or how ties are ordered.
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?
Front-loaded with the verb and examples, then results, then the market filter, then the NZC warning — a sensible priority order with no filler. It loses a point only because the enumerated market list restates the schema's description verbatim and makes the last third read as a run-on.
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?
With no output schema, the description carries the return-value burden and does so: cap of 8, per-result fields, and the disambiguation role of the market field. Combined with the annotations covering safety, nothing an agent needs in order to call this correctly is missing.
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 already 100%, so this is value added on top: the examples show that 'query' accepts both names and numeric tickers, and the description explains the purpose of 'market' as constraining the search to a single market rather than merely listing the codes. That causal framing is more than the schema's terse 'Only this market' note.
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?
States a specific verb and resource ('look up the ticker for a company name or partial symbol') and immediately differentiates its role from siblings, which all take a known ticker and return data. Concrete input examples ('Apple', '2330', 'samsung') make the intended resource unmistakable.
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 description clearly implies when to reach for this tool — before any fundamentals lookup, when you only have a name or fragment — and gives sample inputs that set expectations. It stops short of naming the sibling tools (get_latest_fundamentals, etc.) as the next step or stating exclusions, so the routing is inferred rather than explicit.
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.
get_coverage1 field changedInput schema / properties / compactAdded value: +{
+ "description": "true leaves out the long per-market notes (market_notes, schema) to save tokens; default false",
+ "type": "boolean"
+}get_fundamentals_history4 fields changedInput schema / properties / compactAdded value: +{
+ "description": "true leaves out the long per-market notes (market_notes, schema) to save tokens; default false",
+ "type": "boolean"
+}Input schema / properties / max_rowsAdded value: +{
+ "description": "Most rows to return, 1-250 (default 250); every metric keeps its most recent rows",
+ "maximum": 250,
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / ticker / maxLengthAdded value: +40Input schema / properties / ticker / minLengthAdded value: +1get_latest_fundamentals3 fields changedInput schema / properties / compactAdded value: +{
+ "description": "true leaves out the long per-market notes (market_notes, schema) to save tokens; default false",
+ "type": "boolean"
+}Input schema / properties / ticker / maxLengthAdded value: +40Input schema / properties / ticker / minLengthAdded value: +1search_companies3 fields changedInput schema / properties / market / descriptionPrevious value: -"Only this market: US, JP, TW, KR, FR, BE, DK or NZC"New value: +"Only this market: US, JP, TW, KR, FR, BE, DK, EE, SE, SK, LV, AU, NZC"Input schema / properties / query / maxLengthAdded value: +120Input schema / properties / query / minLengthAdded value: +1get_coverageget_data_dictionaryget_fundamentals_historyget_latest_fundamentalssearch_companiesThe filed record of India's listed companies, every figure tied to the filing it came from.
Read-only fundamentals of developed-market listed companies from official filings, with dates.
Dated, source-linked public records about companies, from SEC filings and other primary documents.
Financial statements, ratios, findings, screens and peer comparisons from official filings. Keyless.
Add one secure layer between your agents and this server.