Forecast + analytics market data for AI agents: financial forecasts (revenue/net income/EPS), fundamental screening, historical market cap across 70+ exchanges and 100k+ tickers. OAuth 2.1 or API token.
Scored across 25 tools
Most tools target clearly distinct resources or actions, with helpful cross-references between ai_asset/ai_company, events/splits, and prices/benchmark. However, general_isin and general_mainstock overlap heavily for ISIN-to-listing resolution, and prices, market_lastday, and benchmark have some fuzzy boundaries around price data.
All names use lowercase snake_case consistently, so the surface is readable and predictable overall. The main inconsistency is that some tools carry category prefixes (ai_*, general_*) while many do not, and a few names like market_lastday and prices_relative_move break a clean noun pattern.
The server covers a broad financial-data domain, so many tools are justified, but 25 is at the heavy end and feels borderline. Some consolidation is possible, especially between general_isin/general_mainstock and events/splits, which would reduce surface area without losing much capability.
The surface is broad: research, prices, fundamentals, dividends, splits, market cap, calendars, macro, government series, forex, sentiment, ratings, screening, and reference/account utilities are all represented. Minor gaps remain around bond price history, fund/ETF-specific detail, and some niche asset classes, but agents can work around most of these.
Research on a tradable asset such as a commodity or currency, passed as symbolexchange in SYMBOL.EXCHANGE form. topic is whatsnew, timeline, price_drivers, or events. Wallet pay-per-use. HTTP 402 if the wallet is too low. For a stock, use ai_company.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | Which asset research brief. | |
| sources | No | Pass true to include sources. Omit this parameter to leave sources out. | |
| maxAgeDays | No | Maximum age of a cached context object in days. | |
| symbolexchange | Yes | Ticker in SYMBOL.EXCHANGE format, for example AAPL.US. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuine non-obvious context: it is wallet pay-per-use and returns HTTP 402 when the wallet is too low, an operational precondition the agent cannot get from annotations. It stops short of rate limits or result shape, but the payment/error disclosure is meaningful added value.
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?
Four dense, front-loaded sentences with no filler: purpose, topic modes, payment behavior, and sibling routing. The telegraphic style is efficient, though the run-on clause about symbolexchange is slightly awkward.
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 research tool with 100% schema coverage and annotations covering the safety profile, the description covers purpose, routing, valid topic modes, and payment/error behavior. No output schema exists, so return values need not be described, and nothing an agent needs to invoke 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 description coverage is 100%, so the schema already documents all four parameters including the topic enum and the SYMBOL.EXCHANGE format. The description reinforces the symbolexchange format and lists topic values but adds little beyond structured fields; baseline 3 applies.
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 (Research) and resource (a tradable asset such as a commodity or currency), and explicitly distinguishes itself from sibling ai_company by routing stocks there. An agent can tell which tool to use 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit use condition (commodity/currency assets) and a named alternative with the selecting condition ('For a stock, use ai_company'). It also enumerates the valid topic modes, leaving virtually nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Research on one stock, passed as symbolexchange in SYMBOL.EXCHANGE form. topic is whatsnew, timeline, competitors, risks, price_drivers, industry, or sector. Wallet pay-per-use. HTTP 402 if the wallet is too low. maxAgeDays=0 forces a refresh. lang (de or en) applies to whatsnew, timeline, competitors, and risks. industry returns HTTP 400 when the company has no industry. sector returns HTTP 400 when the company has no sector. For a commodity or currency, use ai_asset.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Response language: de or en. | |
| topic | Yes | Which company research brief. | |
| sources | No | Pass true to include sources. Omit this parameter to leave sources out. | |
| maxAgeDays | No | Maximum age of a cached context object in days. | |
| symbolexchange | Yes | Ticker in SYMBOL.EXCHANGE format, for example AAPL.US. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/openWorld annotations it discloses a lot of behavioral context: wallet pay-per-use, HTTP 402 on insufficient balance, HTTP 400 for industry/sector topics when the company has none, and the fact that maxAgeDays=0 forces a cache refresh. It also scopes lang to specific topics. These are exactly the failure modes and side effects an agent needs before calling.
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?
Purpose is front-loaded and the remaining sentences are short and information-dense, with no filler. The telegraphic fragment style ('industry returns HTTP 400 when the company has no industry') is functional and scannable, though the wall of terse clauses is slightly harder to parse than prose.
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 reasonably well by enumerating the seven topic briefs, plus it covers payment, error, caching and language behavior. It is slightly thin on what a brief actually contains, but nothing critical to correct invocation 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 description coverage is 100%, so baseline is 3, but the description adds meaning the schema lacks: maxAgeDays=0 is defined as a forced refresh, and lang is restricted to whatsnew/timeline/competitors/risks rather than all topics. The topic list merely restates the enum, so this is above baseline but not maximally additive.
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 sentence states a specific verb and resource (research on one stock) and immediately pins the key input format (SYMBOL.EXCHANGE, e.g. implied by 'symbolexchange'). It also names the sibling it is not, ai_asset, so an agent can separate company research from commodity/currency research 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives one explicit routing rule with its condition: 'For a commodity or currency, use ai_asset.' That is real when-to-use guidance. It stops short of a full 5 because it never distinguishes this tool from other closely related company-data siblings (fundamentals, news, ratings, sentiment), which an agent would also have to choose between.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Market briefing from the shared cache. view=weekly is the weekly briefing and is included for every account. view=daily needs a trader subscription. view=cio_view needs an investor or trader subscription. For those three, length=short returns the email and length=long returns the website text, and lang (de or en) is required. They do not charge the wallet and do not generate. HTTP 403 without the subscription. HTTP 404 when that version is missing. view=timeline is the weekly timeline of market developments. view=topic is one research topic; pass cadence (today or weekly) and topic. Pass sources=true to include sources.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Response language: de or en. | |
| view | Yes | weekly, daily, cio_view, timeline, or one research topic. | |
| topic | No | Research topic. Required when view=topic. | |
| length | No | short returns the email. long returns the full website text. | |
| cadence | No | Market briefing cadence. | |
| sources | No | Pass true to include sources. Omit this parameter to leave sources out. | |
| maxAgeDays | No | Maximum age of a cached context object in days. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnlyHint/openWorldHint annotations by disclosing that the calls do not charge the wallet and do not generate, and by documenting concrete failure modes (HTTP 403 without subscription, HTTP 404 when the version is missing). These are exactly the operational traits an agent needs before invoking.
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-loads the core description, then walks each view in sequence with no filler sentences. The prose is telegraphic and occasionally dense, but every clause carries an actionable constraint, 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?
For a 7-parameter, no-output-schema tool with only safety annotations, this covers view-dependent behavior, auth requirements, and error semantics thoroughly. The only untouched parameter is maxAgeDays, a minor cache-tuning knob already described in the schema.
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 baseline is 3, but the description adds conditional relationships the schema alone does not express: lang is required for the three subscription views, topic pairs with cadence for view=topic, and sources is opt-in. It adds real routing meaning beyond the enum descriptions.
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 resource and retrieval intent ('Market briefing from the shared cache') and enumerates the view modes it serves, so the agent knows exactly what data domain this covers. It does not explicitly differentiate itself from sibling tools like macro or news, but the internal view taxonomy makes the scope unambiguous.
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?
Gives clear per-view usage conditions: weekly is always available, daily/cio_view require trader or investor subscriptions, and 403/404 outcomes are spelled out. It stops short of explicitly steering the agent away from siblings or naming when-not-to-use cases, so it is strong context without full alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Period returns and highs and lows for one SYMBOL.EXCHANGE. performance is the absolute return over 1M, 3M, 6M, 1Y, 3Y, and 5Y. highLow is the high and the low over 1M, 52W, and 5Y. Pass benchmark as comma-separated SYMBOL.EXCHANGE values to add the relative return for each. Omit benchmark for the absolute figures only. For the daily price series, use prices. Costs 1 request unit.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Primary symbol in SYMBOL.EXCHANGE format. Example: SAP.XETRA | |
| benchmark | No | Optional comma-separated benchmark symbols (SYMBOL.EXCHANGE). Each adds relative performance columns.. Example: DAX.INDX,ACWI.US |
| Name | Required | Description |
|---|---|---|
| symbol | No | |
| highLow | No | |
| performance | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds real context beyond the readOnly/openWorld annotations: the exact metric windows returned (1M/3M/6M/1Y/3Y/5Y and 1M/52W/5Y) and the cost of '1 request unit', which no annotation conveys. Slightly terse on what happens with an invalid symbol, but the safety profile is already carried by 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?
Dense and front-loaded — every sentence adds a distinct fact (output fields, benchmark semantics, alternative tool, cost). The telegraphic 'performance is… highLow is…' phrasing is efficient rather than sloppy, though slightly abrupt.
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 an output schema present and annotations covering safety, the remaining burden is usage and cost, both addressed. An agent knows when to call it, what fields to expect, and what it costs; little 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 3 is the baseline; the description goes further by explaining that benchmark values add relative-return columns for each symbol listed, which turns a comma-separated string into a predictable output shape. The behavioral consequence of the parameter is clearer than the schema alone.
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+resource (period returns, highs and lows for one SYMBOL.EXCHANGE) and immediately delineates why it isn't the sibling 'prices' tool. The scope is precise enough that an agent can distinguish it from all 20+ siblings without reading the 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?
Explicitly says to omit benchmark for absolute figures only and to use prices for the daily price series — a named alternative with the condition that selects it. Both the when and the when-not are covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Bond record for one bond ISIN, such as XS0971721963. Read-only: it does not write data. Each call fetches the current record from the market-data source. This server does not keep a snapshot and does not take an as-of date. Requires an API token allowed to call this endpoint. Costs 1 request unit. HTTP 429 when the daily request limit is reached. HTTP 403 when the token may not call this endpoint. An unknown or rejected ISIN comes back as the text Invalid call with HTTP 200. Use this when you have a bond ISIN and need that bond record. For company statements, key figures, or forecasts on SYMBOL.EXCHANGE, use fundamentals. To turn a company name or equity ISIN into SYMBOL.EXCHANGE, use general_isin. For U.S. Treasury, BLS, and Bank of England series, use government. For listed price history, use prices.
| Name | Required | Description | Default |
|---|---|---|---|
| isin | Yes | Bond ISIN.. Example: XS0971721963 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnlyHint annotation: discloses that no snapshot is kept and no as-of date is accepted, that an API token scoped to this endpoint is required, that each call costs 1 request unit, and the meanings of HTTP 429 (daily limit) and 403 (token not permitted). It also warns that an unknown or rejected ISIN returns the text 'Invalid call' with HTTP 200 — a crucial trap an agent would otherwise misread as success.
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 is front-loaded in the first clause and the rest is dense, mostly non-redundant operational detail followed by alternative routing. Slight waste in 'Read-only: it does not write data', which restates the readOnlyHint annotation, and the long run of one-line sentences is more list-like than structured.
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, no-output-schema tool this covers nearly everything needed to call it correctly: cost, auth, error codes, and the notable HTTP 200 'Invalid call' failure mode. The only gap is any indication of what the returned bond record contains or its shape, which matters given there is no output schema.
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% and the schema already documents the single isin parameter with an example, so the baseline is 3. The description adds validation semantics beyond the schema: an unknown or rejected ISIN produces 'Invalid call' with HTTP 200 rather than an error code, which changes how the agent should interpret results.
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+resource: fetch the current bond record for a single bond ISIN, with a concrete example (XS0971721963). It explicitly disambiguates from sibling tools that handle other data domains (fundamentals, general_isin, government, prices), so an agent can choose it without opening the 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?
Explicitly says when to use it ('when you have a bond ISIN and need that bond record') and names four alternatives with the exact condition that selects each: fundamentals for company statements/forecasts on SYMBOL.EXCHANGE, general_isin to resolve names/equity ISINs, government for Treasury/BLS/BoE series, prices for listed price history.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Dividends for SYMBOL.EXCHANGE. view=latest is the dividend events, with date, declarationDate, paymentDate, period, value, unadjustedValue, and currency. calculations=true on that view adds stockprice and yield, where yield is unadjustedValue divided by stockprice. view=history is one point per trading day, with date, open, high, low, and close. A zero means no dividend is active that day. For split ratios, use splits. Costs 2 request units.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | YYYY-MM-DD. The end date. | |
| from | No | Format: YYYY-MM-DD. The start date. | |
| view | Yes | latest is dividend events. history is the daily yield series. | |
| calculations | No | Format: Boolean. If true, returns price at Ex-Div date as well as dividend payout ratio. | |
| symbolExchange | Yes | Symbol and Exchange. Example: SAP.XETRA |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and openWorldHint annotations, the description discloses the return fields for each view, the meaning of a zero value, calculations=true behavior and yield formula, and the cost of 2 request units. These details materially help an agent understand the output and cost profile.
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 front-loaded with the resource and identifier, then proceeds through view semantics, calculations, history behavior, exclusions, and cost with no filler. Every sentence carries useful operational 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?
With no output schema, the description compensates by specifying return fields for both views, zero-value semantics, calculation behavior, and request cost. It also names an alternative for split data, making the definition complete for an agent to call it correctly.
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 schema already documents all parameters. The description still adds value by elaborating on view behavior, calculations=true output, and the yield formula, though it does not add meaning for from, to, or symbolExchange beyond 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 opening phrase 'Dividends for SYMBOL.EXCHANGE' names the resource and identifier format, and 'For split ratios, use splits' distinguishes it from a sibling tool. It lacks an explicit verb such as 'retrieve', but the purpose is still clear from the view descriptions.
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 explains when to use view=latest versus view=history and explicitly routes split-ratio needs to the splits tool. It does not address other nearby alternatives (e.g. prices for stock prices) or state broader exclusions, so it is strong but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Market calendar. view=ipos lists offerings in the window. view=earnings lists report dates with actual and estimated EPS. view=trends is earnings trends and requires symbols as comma-separated SYMBOL.EXCHANGE tickers. view=splits lists split dates across symbols in the window. For ipos, earnings, and trends, an omitted from is today and an omitted to is seven days ahead. For view=splits, an omitted from is the earliest split and an omitted to has no end. Dates are YYYY-MM-DD. For one symbol's split ratios, use splits. Costs 2 request units.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | YYYY-MM-DD. For ipos, earnings, and trends, omit for seven days ahead. For splits, omit for no end date. | |
| from | No | YYYY-MM-DD. For ipos, earnings, and trends, omit for today. For splits, omit to include the earliest split. | |
| view | Yes | ipos, earnings, trends, or splits. | |
| symbols | No | Required: List of tickers in format SYMBOL.EXCHANGE, comma-separated. Example: AAPL.US,SAP.XETRA,OR.PA |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, but the description adds genuinely new context: the cost ('Costs 2 request units') and the asymmetric default date behavior per view. It does not describe response shape or pagination, but with read-only annotations and no output schema the disclosure is above the bar.
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 resource type, then a tight view-by-view enumeration, then defaults, then format, then cost. Every sentence carries information, though the date-format and default-window statements partially repeat what the schema already documents.
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 four-mode, four-parameter tool with no output schema, the description covers per-view return contents, required-symbol conditions, default windows, date format, and cost. Missing only secondary details like ordering or result limits, which are unlikely to block 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 coverage is 100% so the baseline is 3, but the description adds meaning beyond the enum labels by explaining what each view actually returns and how 'from'/'to' default differently per view. It reinforces the SYMBOL.EXCHANGE format requirement for 'symbols', though that detail duplicates 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?
States the resource ('Market calendar') and then defines exactly what each of the four view modes returns (IPOs, earnings with actual/estimated EPS, earnings trends, split dates). An agent can tell it apart from the sibling 'splits' tool because the description says splits handles one symbol's split ratios. This is specific verb+resource+scope, not a restatement of the generic name 'events'.
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?
Explicitly routes the agent to the sibling tool ('For one symbol's split ratios, use splits') and states the prerequisite that trends 'requires symbols as comma-separated SYMBOL.EXCHANGE tickers'. The per-view default windows (today/seven days ahead vs. earliest split/no end) give concrete conditions for how to call each mode.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ECB euro foreign-exchange reference rates. Omit pair to list them. Pass pair as EUR plus the quote currency, such as EURUSD, to read one series. The rate is units of the quote currency for one euro, unchanged from the ECB observation. from and to are YYYY-MM-DD and apply only with pair. Costs 1 request unit.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Last date, YYYY-MM-DD | |
| from | No | First date, YYYY-MM-DD | |
| pair | No | EUR plus the quote currency, such as EURUSD |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), and the description adds genuinely new behavioral context: the upstream source (ECB), the invariant unit convention, the rule that date filters are ignored without pair, and the cost of '1 request unit'. It does not say what happens on an invalid or non-EUR pair, or whether a bad date range errors or returns empty.
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?
Five short sentences, front-loaded with the resource and the mode-selection rule, then unit semantics, then the date-filter constraint, then cost. Every sentence carries distinct information; nothing repeats the name or the schema.
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 read-only, three-optional-param tool with no output schema, the description covers both modes, the date-filter condition, the rate's unit convention, and the request cost. What's left uncovered is the shape of the returned list or series and the currency universe available, which the agent must infer.
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 schema already documents all three params, setting the baseline at 3. The description does add real meaning beyond the schema — the conditional applicability of from/to and the 'EUR plus quote currency' construction of pair — but it adds no format edge cases (e.g. lowercase, non-EUR bases) that the schema line 'EUR plus the quote currency, such as EURUSD' doesn't already imply.
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 (ECB euro foreign-exchange reference rates) and the two operating modes — omit pair to list all series, pass pair such as EURUSD to read one. It also states the unit semantics ('units of the quote currency for one euro'), so an agent knows both what the tool returns and how to choose between modes without opening the 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?
Conditional usage is explicit: 'Omit pair to list them', 'Pass pair ... to read one series', and 'from and to ... apply only with pair'. That removes the main ambiguity for a tool with three optional params. It stops short of naming any exclusions or alternatives (none of the siblings are FX tools), which keeps it off a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Company figures for SYMBOL.EXCHANGE. view=statements is the statements and profile. view=keyfigures is calculated series; pass fields as a comma-separated list and from as YYYY-MM-DD. view=forecast is analyst estimates.
| Name | Required | Description | Default |
|---|---|---|---|
| fmt | No | Output format, default is JSON. Options: XML | |
| from | No | YYYY-MM-DD. Points before this date are omitted. | |
| lang | No | Language setting, default is english. Input 'german' for translated version. | |
| view | Yes | statements, keyfigures, or forecast. | |
| fields | No | Comma-separated series names, for example stock_buybacks,EBIT_margin. Omit to return every series. | |
| mainexchange | No | When 'true', return the home listing’s full fundamentals (including General.Code and General.Exchange) instead of the requested listing. Without this flag, secondary listings keep their own General identity and merge Financials from the home listing when available. | |
| symbolExchange | Yes | SYMBOL.EXCHANGE or ISIN. Example: SAP.XETRA |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds the view-mode structure and hints that keyfigures returns a series you filter with fields/from, but says nothing about rate limits, pagination, data freshness, or auth requirements beyond the 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?
Three compact sentences with zero waste, front-loading the resource identity and then the view semantics. Every clause carries information an agent needs.
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 7-parameter, no-output-schema tool, the description covers the core view modes and the fields/from usage. It is silent on fmt, lang, and mainexchange, but those are well documented in the schema, so the omission is acceptable though not ideal.
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 baseline is 3, but the description genuinely enriches the schema: the enum's own description is just 'statements, keyfigures, or forecast', while the description explains what each view actually returns. It also clarifies that fields is a comma-separated list used with keyfigures and that from follows YYYY-MM-DD, adding intent beyond the raw 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 clearly identifies the resource (company fundamentals for a given SYMBOL.EXCHANGE) and explains the three view modes, so an agent knows what it retrieves. It does not, however, differentiate itself from closely related siblings such as ai_company, general_account, or market_cap, leaving overlap ambiguous.
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 describes what each view returns ('statements is the statements and profile', 'keyfigures is calculated series', 'forecast is analyst estimates'), which implicitly guides view selection. But it never states when to choose this tool over sibling tools or the prerequisites/conditions for use, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Limits for this API token. view=credits is the AI wallet (included, purchased, total, autoRecharge) and does not use a daily request unit. view=requests_left is how many request units remain today. Read credits after HTTP 402.
| Name | Required | Description | Default |
|---|---|---|---|
| view | Yes | credits is the AI wallet. requests_left is the daily request budget. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only and non-open-world, and the description adds real context beyond them: the credits view has no daily request-unit cost, what the wallet contains (included, purchased, total, autoRecharge), and the error path (402) that should prompt a read. It does not describe rate limits or failure modes for requests_left, keeping it below a 5.
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?
Three tight sentences, front-loaded with the scope, then the two views, then the operational hint. Every sentence carries information and nothing is repeated from the schema verbatim.
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 single-enum-parameter, read-only tool with no output schema, the description covers purpose, view semantics, and the practical 402 trigger. What remains uncovered (exact return shape, reset timing for the daily budget) is minor.
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% and the enum values are documented there, so the baseline is 3; the description nonetheless adds meaning by clarifying that credits does not consume request units and by breaking out the wallet sub-fields, which the schema does not mention.
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 concretely states the resource ('limits for this API token') and enumerates the two views, so an agent can distinguish it from the market-data siblings. It is not a clean verb+resource phrasing and the name 'general_account' is opaque, but the first sentence is specific enough.
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 a clear trigger for one view ('Read credits after HTTP 402') and explains that requests_left tracks the daily request budget, which implies checking it before spending units. It stops short of explicitly saying when to prefer requests_left or what the views do not cover.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Exchange directory. view=exchanges lists the exchanges. view=symbols lists the securities on one exchange; pass exchange, and type when you need Common Stock, ETF, or FUND.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Common Stock | ETF | FUND | |
| view | Yes | exchanges lists exchanges. symbols lists one exchange. | |
| exchange | No | exchange |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds mode semantics and filtering behavior, but does not describe auth, rate limits, or return shape beyond what annotations provide.
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?
Three short sentences with the purpose front-loaded. Every sentence adds useful information, and there is no redundant or wasted text.
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 read-only directory tool with three parameters and no output schema, the description covers both views and the relevant optional inputs well. It omits output shape and pagination details, but those are minor here.
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 100%, so the baseline is 3. The description clarifies that exchange scopes symbols and type filters to Common Stock/ETF/FUND, but it mostly restates schema content and omits exchange code format.
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 resource (exchange directory) and the two distinct modes, making the tool's function clear. It does not explicitly differentiate from any sibling tool by name, so it falls short of 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?
Explains when to use each view: exchanges lists exchanges, symbols lists securities on one exchange, and type filters to Common Stock/ETF/FUND. It gives clear mode-selection guidance but does not mention alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve a company name or ISIN to its primary stock symbol and exchange. Use this first if you only have a name or ISIN.
| Name | Required | Description | Default |
|---|---|---|---|
| isin | Yes | ISIN (e.g. DE0007164600) or name/code substring (e.g. SAP). Example: SAP |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds the output shape (primary symbol and exchange) and its workflow role, but says nothing about ambiguity handling for name substrings or rate limits. With an output schema present, the return format need not be re-explained.
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?
Two short sentences, zero waste, with the core resolution action front-loaded and the usage hint immediately after. Nothing could be trimmed without losing meaning.
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 single-parameter read tool with full schema coverage, annotations, and an output schema, the description is nearly sufficient. A brief note on how fuzzy name matching behaves would make it complete.
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 100% and there is a single well-documented parameter with an example, so the schema carries the load. The description's 'name or ISIN' phrasing mirrors the schema and adds no new syntax or format detail, making the baseline 3 appropriate.
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 ('Resolve') and the exact transformation (company name or ISIN → primary stock symbol and exchange). The purpose is unambiguous, though it does not name or contrast any of the many sibling tools that consume the resolved symbol.
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?
'Use this first if you only have a name or ISIN' gives an explicit entry condition and positions the tool at the start of a workflow. It stops short of naming which downstream sibling to call next, so it is clear context without full alternatives mapping.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the primary listing for a given ISIN. Useful to avoid secondary or illiquid listings.
| Name | Required | Description | Default |
|---|---|---|---|
| isin | Yes | isin |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds the useful behavioral nuance that results are the primary rather than secondary/illiquid listing, but says nothing about the return shape, error behavior when no primary listing exists, or data freshness.
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?
Two short sentences with zero waste; the core action is front-loaded and the rationale follows 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 single-parameter lookup with no output schema, the description leaves the return value and no-match behavior unexplained, and does not differentiate from the closely related general_isin sibling. It is adequate but not complete.
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?
Only one parameter, and schema description coverage is 100% ('isin'), so the schema already carries the parameter burden. The description adds no format or validation detail (e.g., ISIN format, case sensitivity) beyond 'for a given ISIN'.
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 ('Find the primary listing for a given ISIN'), so an agent can tell what the tool returns. It does not, however, distinguish itself from the sibling general_isin, which also keys off an ISIN and could plausibly be confused with this lookup.
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 second sentence ('Useful to avoid secondary or illiquid listings') implies when the tool is valuable, but there is no explicit when-to-use/when-not guidance and no named alternative (e.g., general_isin) for the cases this tool does not cover.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Screen stocks by listing fields, Highlights, keyfigures (incl. aliases like pe/roe/market_cap), and/or market signals. At least one of filters, signals, or preset is required. Supports preset=quality with explicit thresholds; pagination up to limit 1000. See OpenAPI filters/signals/preset params for the full field catalog.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort by a numeric result field using field.asc or field.desc. market_capitalization is in the listing currency. MarketCapitalizationUSD is in USD, converted from the listing currency at the latest available FX rate. Sorting by MarketCapitalizationUSD requires a filter on MarketCapitalizationUSD or market_cap_usd.. Example: market_capitalization.desc | |
| limit | No | Number of results to return. Default 50, min 1, max 1000.. Example: 50 | |
| offset | No | Pagination offset. Default 0, max 999.. Example: 0 | |
| preset | No | Named filter preset. Currently: quality (ReturnOnEquityTTM>0.15, ReturnOnAssetsTTM>0.1, OperatingMarginTTM>0.15, debt_to_equity<0.5, current_ratio>1.5, interest_coverage>5, earnings_growth_5y_cagr>0.05, sales_growth_5y_cagr>0.05, free_cashflow>0, MarketCapitalizationUSD>10000000000, PERatio<30). Matching filter fields in filters override the preset thresholds. Max limit 1000.. Example: quality | |
| filters | No | JSON array of [field, op, value]. Listing fields: adjusted_close, avgvol_1d, avgvol_200d, code, dividend_yield, earnings_share, exchange, industry, market_capitalization, name, refund_1d_p, refund_5d_p, sector. Highlights: BookValue, DilutedEpsTTM, DividendShare, DividendYield, EBITDA, EPSEstimateCurrentQuarter, EPSEstimateCurrentYear, EPSEstimateNextQuarter, EPSEstimateNextYear, EarningsShare, GrossProfitTTM, MarketCapitalization, MarketCapitalizationMln, MostRecentQuarter, OperatingMarginTTM, PEGRatio, PERatio, ProfitMargin, QuarterlyEarningsGrowthYOY, QuarterlyRevenueGrowthYOY, ReturnOnAssetsTTM, ReturnOnEquityTTM, RevenuePerShareTTM, RevenueTTM, WallStreetTargetPrice. Keyfigures: EBITDA_margin, EBITDA_margin_rolling_quarters, EBIT_margin, EBIT_margin_rolling_quarters, EPSEstimateCurrentQuarter, EPSEstimateCurrentYear, EPSEstimateNextQuarter, EPSEstimateNextYear, ForwardPE, PEGRatio, PercentInsiders, PercentInstitutions, ShortPercentFloat, analyst_rating, analyst_upside, cashflow_growth, cashflow_growth_rolling_quarters, cashflow_margin, cashflow_margin_rolling_quarters, current_ratio, current_ratio_rolling_quarters, debt_to_equity, debt_to_equity_rolling_quarters, dynamic_debt, dynamic_debt_rolling_quarters, earnings_growth, earnings_growth_5y_cagr, earnings_growth_rolling_quarters, equity_ratio, equity_ratio_rolling_quarters, estimate_eps_growth_1y, estimate_eps_growth_2y, free_cashflow, free_cashflow_rolling_quarters, free_cashflow_yield, free_cashflow_yield_rolling_quarters, gross_margin, gross_margin_rolling_quarters, interest_coverage, interest_coverage_rolling_quarters, leverage, leverage_rolling_quarters, liquidity, liquidity_rolling_quarters, net_income_margin, net_income_margin_rolling_quarters, r_and_d_investment_sales, r_and_d_investment_sales_rolling_quarters, return_on_assets, return_on_assets_rolling_quarters, return_on_equity, return_on_equity_rolling_quarters, return_on_liabilities, return_on_liabilities_rolling_quarters, sales_growth, sales_growth_3y_cagr, sales_growth_5y_cagr, sales_growth_rolling_quarters, stock_buybacks, stock_buybacks_rolling_quarters, wallstreet_estimate_upside. Derived: MarketCapitalizationUSD is USD-normalized from local-currency Highlights.MarketCapitalization using the latest available FX rate. Aliases: ebit_margin→EBIT_margin, market_cap→MarketCapitalization, market_cap_usd→MarketCapitalizationUSD, operating_margin→OperatingMarginTTM, pe→PERatio, pe_ratio→PERatio, roa→ReturnOnAssetsTTM, roe→ReturnOnEquityTTM. String ops: =, match. Numeric ops: =, >, <, >=, <=.. Example: [["exchange","=","XETRA"],["pe","<",15]] | |
| signals | No | Comma-separated market signals: 200d_new_hi (price at a new 200-day high); 200d_new_lo (price at a new 200-day low); 50d_new_hi (price at a new 50-day high); 50d_new_lo (price at a new 50-day low); bookvalue_neg (price below book value); bookvalue_pos (price above book value); wallstreet_hi (price above Wall Street target); wallstreet_lo (price below Wall Street target).. Example: 200d_new_hi |
| Name | Required | Description |
|---|---|---|
| data | No | |
| total | No | |
| preset | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered; the description adds genuinely useful behavior beyond that: the required-parameter constraint, the limit ceiling of 1000, and that preset thresholds are overridable by matching filter fields. It does not describe result ordering defaults or how aliases resolve at query time.
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 purpose, then the required-input rule, then capability details; four sentences with little padding. The final 'See OpenAPI filters/signals/preset params' sentence is somewhat redundant given the schema is fully documented, but it is short.
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-required-field screening tool with a full schema and an output schema, the description covers the essential operational facts: what is screened, the required-input constraint, preset support, and pagination cap. Return-value shape is rightly left to the output schema.
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 100% and the schema already enumerates the full field catalog, aliases, operators, and the exact quality preset thresholds. The description largely restates this (aliases, preset thresholds, limit 1000) and then defers back to the schema for the catalog, so it adds little meaning beyond the structured data — baseline 3.
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 ('Screen stocks') and the dimensions being screened on (listing fields, Highlights, keyfigures, market signals), which is clearly distinct from single-entity siblings like fundamentals or market_cap. It stops short of naming an alternative tool or explicitly contrasting its multi-stock filtering role against the sibling data-fetch tools.
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?
Provides a hard usage rule — 'At least one of filters, signals, or preset is required' — which prevents an empty call and is exactly the kind of precondition an agent needs. It also points to preset=quality as a supported entry path, but gives no when-not guidance or comparison to alternative screening/data tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
First and last date this stock traded on its exchange. Pass symbolExchange as SYMBOL.EXCHANGE.
| Name | Required | Description | Default |
|---|---|---|---|
| symbolExchange | Yes | symbolExchange |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful substance by disclosing what is returned (a first and last trading date), which matters since there is no output schema, but it says nothing about coverage limits, delisted stocks, or missing-data 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?
Two short sentences, zero waste, with the purpose stated before the parameter instruction. Appropriately sized for a single-parameter lookup.
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 read tool with no output schema, the description supplies both the return content and the argument format, which is most of what an agent needs. Minor gaps remain around data coverage for delisted or untraded symbols.
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 baseline is 3, but the schema's own description merely repeats the field name. The description adds real meaning with the required SYMBOL.EXCHANGE composite format, which the schema does not convey.
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 resource and what is returned: the first and last date a stock traded on its exchange. This is clearly distinguishable from siblings like prices or splits, though it never explicitly contrasts itself with them.
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?
No guidance on when to use this versus alternatives such as prices or market_lastday, and no stated prerequisites. The only instruction given is the parameter format, which is more a parameter note than a usage rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
U.S. Treasury, Bureau of Labor Statistics, and Bank of England series. Omit series to list them. Pass series with an id from that list to read one series. from and to are YYYY-MM-DD and apply only with series. Costs 1 request unit.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Last date, YYYY-MM-DD | |
| from | No | First date, YYYY-MM-DD | |
| series | No | Series id from GET /government |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the description does not need to restate safety. It adds useful behavioral context by disclosing that the call costs 1 request unit and by clarifying the two operational modes and parameter applicability.
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?
Three short sentences, front-loaded with the data sources and the two usage modes. Every sentence carries actionable information; there is no filler.
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 read-only retrieval tool with three optional parameters, the description covers sources, modes, date format constraints, and request cost. It does not describe the shape of the returned series data or listing output, which is a minor gap given there is no output schema.
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 schema already documents the three parameters and date format. The description adds meaning beyond the schema by specifying that 'series' must be an id from the list returned when omitting it, and that 'from'/'to' apply only with 'series'.
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 data sources (U.S. Treasury, BLS, Bank of England) and describes the two modes: listing series when 'series' is omitted, and reading one series when 'series' is provided. It is clear what the tool does, but it does not explicitly differentiate itself from likely siblings like 'macro' or 'benchmark'.
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 clearly states how to use each mode: omit 'series' to list available series, pass an id from that list to read one series, and that 'from'/'to' apply only when 'series' is set. It lacks guidance on when to choose this tool over siblings such as 'macro', but the within-tool usage is explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Macroeconomic series. view=indicators lists indicators. view=countries lists countries. view=series is one country in Alpha-3; pass country, and indicator when you want a single indicator.
| Name | Required | Description | Default |
|---|---|---|---|
| view | Yes | indicators, countries, or one country series. | |
| country | No | Select Country in Alpha-3 ISO format. | |
| indicator | No | Select desired indicator. Default: gdp_current_usd |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds only the semantic mapping of view values to behavior, with no data range, freshness, rate limit, or return-shape context beyond what the schema enum already conveys.
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?
Three short, declarative sentences with zero filler; the resource statement is front-loaded and each subsequent clause maps one view mode to its parameters. Every sentence earns its place.
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?
Covers all three parameters and the view routing, which is the core need. With no output schema and no description of what a series result actually contains (single value, time series, units), an agent cannot anticipate the response shape.
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 baseline is 3, but the description goes further by explaining parameter interaction: country is only meaningful with view=series, and indicator is optional for a single-indicator pull. That clarifies the combinatorial semantics rather than repeating field text.
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 resource (macroeconomic series) and enumerates the three view modes, so the agent knows exactly what data domain this covers. However, it never differentiates itself from siblings like 'government' or 'bond', which also deal with macro-flavored economic data, so selection still relies on name 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?
The description gives clear internal routing guidance: view=indicators lists indicators, view=countries lists countries, and view=series needs country/indicator. But it offers no when-to-use-this-vs-another-tool guidance against the 22 siblings, and no exclusions, so cross-tool selection is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Market capitalization. view=history is one company; pass symbolExchange. view=aggregation is valuation multiples across companies; pass type as pe, pb, ps, pc, or liab.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | YYYY-MM-DD. The end date, if not provided, today in 7 days will be used. | |
| from | No | Format: YYYY-MM-DD. The start date, if not provided, today will be used. | |
| type | No | History of common multiples, options are pe, pb, ps, pc, liab for ratios of price in regard to earnings, bookvalue, sales, cashflow and liabilities. | |
| view | Yes | history is one company. aggregation is multiples across companies. | |
| byname | No | Set this to true and pass a Companyname in symbolExchange. | |
| maxCap | No | Limits aggregation to companies of marketcap between smaller than maxCap | |
| minCap | No | Limits aggregation to companies of marketcap between greater than minCap | |
| sector | No | Limits aggregation to companies of that sector or industry | |
| country | No | Limits aggregation to companies of that country or area (EU, NA, ASIA, OTHER) | |
| valuation | No | Optional. pe, pb, ps, pc, or liab for one ratio; all returns an object with all five keys. Omit for market-cap history. | |
| symbolExchange | No | Symbol and Exchange. Example: SAP.XETRA |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds that output shape varies by view (single-company series vs cross-company multiples), which is genuinely useful, but says nothing about rate limits, pagination, or how large an aggregation result can be.
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?
Two tightly packed sentences with no filler, and the mode split is front-loaded ahead of the parameter rules. The semicolon-separated clauses are dense but readable.
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 an 11-parameter tool with no output schema, the description covers only view, symbolExchange, and type, leaving the aggregation filters (sector, country, minCap, maxCap, byname) and the return shape entirely to the schema. Adequate but with clear gaps for the aggregation path.
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, but the description goes beyond per-field docs by explaining how parameters combine per mode (symbolExchange only with history, type only with aggregation). That relational guidance is not derivable from the individual schema entries.
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 resource (market capitalization) and splits it into two clearly labeled modes, history (one company) vs aggregation (multiples across companies), so an agent can distinguish it from siblings like prices or fundamentals. It lacks an explicit retrieval verb, but the resource and mode split are unambiguous.
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?
Gives explicit routing for each view and the required companion parameter (symbolExchange for history, type/pe,pb,ps,pc,liab for aggregation). It does not say when to prefer this tool over siblings such as fundamentals or benchmark, so it stops short of full when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One OHLCV bar per listed instrument on an exchange for a trading day. Omit date for the latest session. symbols limits the result to a comma-separated list. Costs 1 request unit.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Trading date (YYYY-MM-DD). Default: last trading day.. Example: 2026-06-10 | |
| filter | No | Extended fields (name, EMAs, avg volumes). Past 30 days only. | |
| symbols | No | Optional. Comma-separated symbols to limit results.. Example: SAP,RWE,ALV | |
| exchange | Yes | Exchange code. Example: XETRA |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuinely useful non-schema behavior: the cost of one request unit and that the whole exchange is returned unless symbols narrows it. It does not mention rate limits or failure modes, keeping it below a 5.
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?
Three short sentences with zero waste, front-loading what the tool returns before mentioning the date default, the symbols narrowing, and the cost. Every sentence earns its place.
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?
An output schema exists, so return shape needn't be explained, and the read-only safety profile is covered by annotations. For a 4-parameter tool the description is nearly complete, though it omits any mention of the 'filter' extended-fields constraint or result size expectations.
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 100%, so the schema already documents date, filter, symbols, and exchange. The description restates only the symbols and date semantics in slightly different words, adding no format, boundary, or interaction detail beyond what the schema 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?
States a specific verb+resource+scope: one OHLCV bar per listed instrument on an exchange for a trading day, with the latest-session default. However, it never contrasts itself with siblings such as 'prices', 'market_cap', or 'ai_market', so an agent must infer which market tool applies.
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?
Gives one concrete usage rule ('Omit date for the latest session') and the cost, but offers no when-to-use vs alternatives guidance. The sibling set is large and related (prices, market_cap, benchmark), yet none are mentioned as alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
News for companies, stocks, and currencies. Pass s as SYMBOL.EXCHANGE when you want one instrument. from and to are YYYY-MM-DD.
| Name | Required | Description | Default |
|---|---|---|---|
| s | No | Format: Code.Exchange. The code for which the news are queried . | |
| to | No | YYYY-MM-DD. The end date. | |
| from | No | Format: YYYY-MM-DD. The start date. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered without the description. The description adds no further behavioral context such as pagination, result caps, recency window, or what the response contains, so it clears the lowered bar but goes no further.
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?
Two tight sentences with no filler, and the purpose leads before the parameter notes. Efficient, though the parameter-format sentences duplicate the schema and could have carried something more valuable instead.
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 zero-required-parameter, read-only query tool with full schema coverage and no output schema, the description supplies enough to invoke it correctly. The only real gap is not knowing the shape or volume of returned news items, which is a minor omission.
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 100%, so all three parameters are already documented with format details. The description's 'SYMBOL.EXCHANGE' and 'YYYY-MM-DD' notes merely restate what the schema says, adding no semantics beyond it. Baseline 3 applies.
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 the resource and its domain scope clearly: news covering companies, stocks, and currencies. No sibling tool shares this purpose, so differentiation is implicit rather than argued, but an agent can immediately tell this is the news-retrieval tool.
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 line 'Pass s as SYMBOL.EXCHANGE when you want one instrument' implies the alternative (omit s for broader news) but never states it explicitly, and gives no guidance on typical use cases, freshness, or result limits. Usage is inferable rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prices for SYMBOL.EXCHANGE. view=eod is daily OHLCV. view=live is the latest quote. view=intraday is 1m, 5m, or 1h bars; pass interval. For whether today's move is unusual, use prices_relative_move.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | YYYY-MM-DD. The end date, if not provided, today in 7 days will be used. | |
| from | No | Format: YYYY-MM-DD. The start date, if not provided, today will be used. | |
| view | Yes | eod is daily bars. live is the latest quote. intraday is intraday bars. | |
| multi | No | Optional: Comma-separated list of additional SYMBOL.EXCHANGE tickers. Response is an array when provided.. Example: SAP.XETRA,EURUSD.FOREX | |
| byname | No | Set this to true and pass a Companyname in symbolExchange. | |
| filter | No | Set this to e.g. close to get only ONE (e.g. close) for each day. Date is always returned. Keys are renamed to time,value | |
| interval | No | '5m' for 5 minutes, '1h' for 1 hour, and '1m' for 1 minute intervals. 1 minute is only available for US exchanges NYSE and NASDAQ. | |
| symbolExchange | Yes | Symbol and Exchange. Example: SAP.XETRA |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and openWorldHint=false, so the bar is lower. The description adds useful behavioral context: what each view returns (daily OHLCV, latest quote, intraday bars) and a constraint that 1m intraday is only for US exchanges.
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?
Three sentences, front-loaded with the core purpose and view semantics, then the alternative. Every sentence earns its place with no redundancy.
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?
Given 8 parameters, full schema coverage, and no output schema, the description covers the key usage dimensions (view modes, interval, sibling alternative). It omits mention of optional batch parameter 'multi', but the schema handles that adequately.
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 100%, so the schema fully documents all 8 parameters. The description adds little beyond the schema—it mentions interval for intraday, but the schema already covers that and more.
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 states the resource ('Prices for SYMBOL.EXCHANGE') and details the three view modes, clearly indicating what the tool returns. It distinguishes from sibling prices_relative_move, but does not use an explicit verb and only differentiates from one sibling among many.
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 context for each view (eod, live, intraday) and explicitly routes unusual-move queries to prices_relative_move. However, it does not state when not to use this tool or mention other alternatives like market_lastday.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare today's price change to the average daily range over the last year (unusual move detection).
| Name | Required | Description | Default |
|---|---|---|---|
| symbolExchange | Yes | Symbol and exchange. Example: SAP.XETRA |
| Name | Required | Description |
|---|---|---|
| change_p | No | |
| relativeMove | No | |
| averageTrueRange_1Y | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety and scope are covered. The description adds the behavioral concept that the result measures deviation from a one-year baseline, but it does not say how the comparison is expressed or what constitutes an 'unusual' threshold. Reasonable given annotations, but not rich.
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 well-formed sentence with the core comparison front-loaded and the use case in parentheses at the end. No filler, though it stays terse enough that it could afford one clarifying clause without becoming bloated.
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 single-parameter read tool with a 100%-covered schema and an output schema that carries the return values, the description covers what is needed to call it. The only real gap is ambiguity around what 'average daily range' means (high-low range vs. average absolute change), which an agent might misread.
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?
Only one parameter (symbolExchange) and schema coverage is 100%, with an example supplied in the schema itself, so the baseline is 3. The description adds no format or interpretation guidance about the symbol/exchange argument beyond what the schema already states.
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 (Compare) and specific resources (today's price change, average daily range over the last year) and even tags the analytical intent as 'unusual move detection'. It is far more specific than most siblings, but it never distinguishes itself from related tools like prices or market_lastday, so an agent still has to infer which one applies.
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 when-to-use or when-not-to-use guidance and no named alternative among the many sibling tools. The parenthetical '(unusual move detection)' implies the scenario the tool serves, which is enough to count as implied usage, but nothing tells the agent when this beats a plain prices lookup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Leeway ratings for a listing. Market-Fit measures how well the company fits historically successful fundamental patterns using 18 metrics across profitability, financial strength and valuation; adaptive peer groups learn optimal ranges from roughly four years of returns, hit rates and stability, with rolling recalibration and forecasts. Business-Rating measures long-term business quality independently of price across twelve dimensions; it is produced from scored, fact-checked analysis. Cycle-Rating measures whether the listing is cheap or expensive versus its own valuation history using valuation multiples, leverage and dividend yield; higher means historically cheaper. Leeway-Score combines Market-Fit, Business and Cycle in equal thirds. Market-Fit, Business and Leeway-Score range from -100 to +100; Cycle ranges from 0 to 100. Factor statistics include the current raw value, machine-learning score, average performance, normalized performance, win rate and deviation. These are analytical ratings, not buy recommendations. Methodology: https://leeway.tech/en/hilfe/scores; Market-Fit: https://leeway.tech/en/hilfe/scores/marketfit; Business: https://leeway.tech/en/hilfe/scores/business; Cycle: https://leeway.tech/en/hilfe/scores/cycle. Free access is SAP only; Investor covers US/Europe; Trader worldwide.
| Name | Required | Description | Default |
|---|---|---|---|
| symbolExchange | Yes | Symbol and exchange. Example: SAP.XETRA |
| Name | Required | Description |
|---|---|---|
| code | No | |
| name | No | |
| country | No | |
| factors | No | |
| ratings | No | |
| exchange | No | |
| discontinued | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already declaring readOnly and closed-world, the description goes further by disclosing score ranges (-100..+100, Cycle 0..100), the fact these are analytical not buy recommendations, and entitlement limits per subscription tier — genuinely useful context. It omits error/empty-result behavior, keeping it below a 5.
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 core purpose is front-loaded, but the body is a dense wall of prose mixing rating definitions, range clamps, factor-statistic field lists, disclaimers, and four methodology URLs. Several sentences (notably the factor-statistics enumeration, duplicated by the output schema) do not earn their place.
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 single-parameter tool whose output schema exists, the description is largely complete: it explains what each of the four scores means, their scales, and access constraints. It over-describes return fields while saying nothing about failure modes, but nothing essential for invoking it 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% and the schema supplies the "SAP.XETRA" example, so the baseline would be 3; the description earns an extra point by tying subscription tier to regional exchange coverage, which informs which symbol/exchange an agent may validly pass.
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 sentence states a specific verb and resource ("Get Leeway ratings for a listing") and the following sentences define each rating type, so an agent can tell this returns composite analytical scores rather than raw fundamentals. It never names a sibling, though, so differentiation from tools like fundamentals or ai_company must be inferred.
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 when-to-use/when-not statement or named alternative; usage is only implied by the description of what the ratings measure. The access-tier note (SAP-only free, Investor US/Europe, Trader worldwide) is the closest thing to guidance, but it constrains coverage rather than tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Market sentiment. family is breadth, breadth_volume, naaim, fear_index, smart_money, cot, or sce. For breadth, breadth_volume, cot, and sce, omit series to list the catalog and pass series to read one. breadth and breadth_volume take an index symbol such as GSPC.INDX. cot and sce take the id from the catalog. naaim, fear_index, and smart_money are single series, so omit series. from and to are YYYY-MM-DD and apply to one series. cot filters active, set, contract, and report apply only when series is omitted. Free access is delayed: the newest points are omitted, and the response includes pointsRemoved and remedy_url. Costs 1 request unit.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Last date, YYYY-MM-DD | |
| set | No | Pass all to list every stored series | |
| from | No | First date, YYYY-MM-DD | |
| active | No | true (default), false, or all | |
| family | Yes | Which sentiment series. | |
| report | No | disagg, tff, or legacy | |
| series | No | Index symbol or series id. Omit to list the catalog. Omit for naaim, fear_index, and smart_money. | |
| contract | No | One CFTC market code |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint/openWorldHint annotations, it discloses that free access is delayed with the newest points omitted and that the response carries pointsRemoved and remedy_url, plus an explicit cost of 1 request unit. That is exactly the operational context (data truncation, quota cost, remediation path) an agent needs before invoking.
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 domain label is front-loaded, followed by the family enumeration and then parameter rules in priority order. It is dense and somewhat run-on across many short clauses, but essentially every sentence carries a distinct rule with no filler.
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 an 8-parameter, no-output-schema tool, the description covers the family taxonomy, series/catalog behavior, date semantics, cot-only filters, and free-tier return caveats. The main omission is that it never describes the shape of a returned series or catalog entry, though pointsRemoved/remedy_url are called out.
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 schema documents each field, but the description adds conditional meaning the schema lacks: which families accept series, that from/to apply to a single series, that cot's active/set/contract/report filters only apply when series is omitted, and the index-symbol format (GSPC.INDX). It exceeds the baseline-3 expectation for full-coverage schemas.
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 a specific resource domain ('Market sentiment') and enumerates all seven sub-families (breadth, breadth_volume, naaim, fear_index, smart_money, cot, sce), so an agent knows exactly what data it returns. It does not state an explicit verb (retrieve/list) or name a sibling tool, but the resource is distinct from anything in the sibling list (prices, news, macro, etc.).
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 concrete routing rules: for breadth/breadth_volume/cot/sce omit series to list the catalog and pass series to read one; naaim, fear_index, and smart_money are single series so omit series entirely. It also scopes cot filters to the catalog-listing case. It stops short of naming alternative tools for when sentiment is the wrong choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Split history for one SYMBOL.EXCHANGE. Each row has date and split. split is new shares over old shares, as in 5.000000/1.000000. For splits across many symbols in a date window, use events with view=splits. Costs 1 request unit.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | YYYY-MM-DD. The end date. | |
| from | No | Format: YYYY-MM-DD. The start date. | |
| symbolExchange | Yes | Symbol and Exchange. Example: SAP.XETRA |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds useful behavioral context beyond that: it explains the row shape, the split ratio semantics, and the request-unit cost. It does not discuss pagination or optional date-window defaults, so it falls short of full transparency.
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?
Three tightly packed sentences, front-loaded with the core purpose, then output semantics, then the alternative and cost. No sentence is redundant.
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 read-only endpoint with full schema coverage, an output schema, and annotations, the description is complete enough. It covers purpose, return semantics, alternative routing, and cost without needing to restate schema or output schema details.
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 schema already documents 'symbolExchange', 'from', and 'to'. The description reinforces the 'SYMBOL.EXCHANGE' format for the required parameter, but does not add syntax or constraint details beyond the schema, so baseline 3 is appropriate.
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 states a specific resource ('Split history') and scope ('one SYMBOL.EXCHANGE'), and explicitly distinguishes it from the sibling 'events' path for multi-symbol windows. An agent can identify the tool's precise purpose without opening the 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?
It gives explicit routing guidance: use this for one symbol's split history, and use 'events with view=splits' for splits across many symbols in a date window. The cost note also helps invocation planning.
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.
forexratings1 field changedOutput schema / properties / ratings / anyOfPrevious value: -[
- {
- "additionalProperties": {},
- "properties": {
- "business": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "cycle": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "earnings": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "esg": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "financial": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "growth": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "leewayScore": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "marketFit": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "marketFitTrend": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "marketFitTrendScore": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "price": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "value": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- }
- },
- "type": "object"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "additionalProperties": {},
+ "properties": {
+ "business": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "cycle": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "earnings": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "financial": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "growth": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "leewayScore": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "marketFit": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "marketFitTrend": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "marketFitTrendScore": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "price": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "value": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]events2 fields changedInput schema / properties / from / descriptionPrevious value: -"Format: YYYY-MM-DD. The start date, if not provided, today will be used."New value: +"YYYY-MM-DD. For ipos, earnings, and trends, omit for today. For splits, omit to include the earliest split."Input schema / properties / to / descriptionPrevious value: -"YYYY-MM-DD. The end date, if not provided, today in 7 days will be used."New value: +"YYYY-MM-DD. For ipos, earnings, and trends, omit for seven days ahead. For splits, omit for no end date."ai_assetai_asset_eventsai_asset_price-driversai_asset_timelineai_asset_whatsnewai_companyai_marketai_market_cio-viewai_market_dailyai_market_timeline-weeklyai_market_topicsai_market_weeklyai_research_competitorsai_research_industryai_research_price-driversai_research_risksai_research_sectorai_research_timelineai_whatsnewbenchmarkdividends4 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / viewAdded value: +{
+ "description": "latest is dividend events. history is the daily yield series.",
+ "enum": [
+ "latest",
+ "history"
+ ],
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "symbolExchange"
-]New value: +[
+ "view",
+ "symbolExchange"
+]Output schema / (root)Previous value: -{
- "$schema": "http://json-schema.org/draft-07/schema#",
- "additionalProperties": false,
- "properties": {
- "result": {
- "anyOf": [
- {
- "items": {
- "anyOf": [
- {
- "additionalProperties": {},
- "properties": {
- "currency": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "date": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "declarationDate": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "paymentDate": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "period": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "unadjustedValue": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "value": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- }
- },
- "type": "object"
- },
- {
- "type": "null"
- }
- ]
- },
- "type": "array"
- },
- {
- "type": "null"
- }
- ]
- }
- },
- "required": [
- "result"
- ],
- "type": "object"
-}New value: +nulldividends_historyeventsevents_earningsevents_iposevents_splitsevents_trendsfundamentals6 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / fieldsAdded value: +{
+ "description": "Comma-separated series names, for example stock_buybacks,EBIT_margin. Omit to return every series.",
+ "type": "string"
+}Input schema / properties / fromAdded value: +{
+ "description": "YYYY-MM-DD. Points before this date are omitted.",
+ "type": "string"
+}Input schema / properties / viewAdded value: +{
+ "description": "statements, keyfigures, or forecast.",
+ "enum": [
+ "statements",
+ "keyfigures",
+ "forecast"
+ ],
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "symbolExchange"
-]New value: +[
+ "view",
+ "symbolExchange"
+]Output schema / (root)Previous value: -{
- "$schema": "http://json-schema.org/draft-07/schema#",
- "additionalProperties": {},
- "properties": {
- "Earnings": {
- "anyOf": [
- {
- "additionalProperties": {},
- "properties": {
- "History": {
- "anyOf": [
- {
- "items": {
- "anyOf": [
- {
- "additionalProperties": {},
- "properties": {
- "beforeAfterMarket": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "currency": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "date": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "epsActual": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "epsDifference": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "epsEstimate": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "reportDate": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "surprisePercent": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- }
- },
- "type": "object"
- },
- {
- "type": "null"
- }
- ]
- },
- "type": "array"
- },
- {
- "type": "null"
- }
- ]
- },
- "Trend": {
- "anyOf": [
- {
- "items": {
- "anyOf": [
- {
- "additionalProperties": {},
- "properties": {
- "date": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "earningsEstimateAvg": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "earningsEstimateNumberOfAnalysts": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "period": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "revenueEstimateAvg": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- }
- },
- "type": "object"
- },
- {
- "type": "null"
- }
- ]
- },
- "type": "array"
- },
- {
- "type": "null"
- }
- ]
- }
- },
- "type": "object"
- },
- {
- "type": "null"
- }
- ]
- },
- "Financials": {
- "anyOf": [
- {
- "additionalProperties": {},
- "properties": {
- "Balance_Sheet": {
- "anyOf": [
- {
- "additionalProperties": {},
- "properties": {
- "currency_symbol": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "quarterly": {
- "anyOf": [
- {
- "items": {
- "anyOf": [
- {
- "additionalProperties": {},
- "properties": {
- "cash": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "currency_symbol": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "date": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "filing_date": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "goodWill": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "netWorkingCapital": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "retainedEarnings": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "totalAssets": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "totalCurrentAssets": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "totalCurrentLiabilities": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "totalLiab": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "totalStockholderEquity": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- }
- },
- "type": "object"
- },
- {
- "type": "null"
- }
- ]
- },
- "type": "array"
- },
- {
- "type": "null"
- }
- ]
- },
- "yearly": {
- "anyOf": [
- {
- "items": {
- "anyOf": [
- {
- "additionalProperties": {},
- "properties": {
- "cash": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "currency_symbol": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "date": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "filing_date": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "goodWill": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "netWorkingCapital": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "retainedEarnings": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "totalAssets": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "totalCurrentAssets": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "totalCurrentLiabilities": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "totalLiab": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "totalStockholderEquity": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- }
- },
- "type": "object"
- },
- {
- "type": "null"
- }
- ]
- },
- "type": "array"
- },
- {
- "type": "null"
- }
- ]
- }
- },
- "type": "object"
- },
- {
- "type": "null"
- }
- ]
- },
- "Cash_Flow": {
- "anyOf": [
- {
- "additionalProperties": {},
- "properties": {
- "currency_symbol": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "quarterly": {
- "anyOf": [
- {
- "items": {
- "anyOf": [
- {
- "additionalProperties": {},
- "properties": {
- "capitalExpenditures": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "currency_symbol": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "date": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "dividendsPaid": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "filing_date": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "freeCashFlow": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "netIncome": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "totalCashFromOperatingActivities": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- }
- },
- "type": "object"
- },
- {
- "type": "null"
- }
- ]
- },
- "type": "array"
- },
- {
- "type": "null"
- }
- ]
- },
- "yearly": {
- "anyOf": [
- {
- "items": {
- "anyOf": [
- {
- "additionalProperties": {},
- "properties": {
- "capitalExpenditures": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "currency_symbol": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "date": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "dividendsPaid": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "filing_date": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "freeCashFlow": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "netIncome": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "totalCashFromOperatingActivities": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- }
- },
- "type": "object"
- },
- {
- "type": "null"
- }
- ]
- },
- "type": "array"
- },
- {
- "type": "null"
- }
- ]
- }
- },
- "type": "object"
- },
- {
- "type": "null"
- }
- ]
- },
- "Income_Statement": {
- "anyOf": [
- {
- "additionalProperties": {},
- "properties": {
- "currency_symbol": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "quarterly": {
- "anyOf": [
- {
- "items": {
- "anyOf": [
- {
- "additionalProperties": {},
- "properties": {
- "currency_symbol": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "date": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "ebit": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "ebitda": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "filing_date": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "grossProfit": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "incomeBeforeTax": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "incomeTaxExpense": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "netIncome": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "operatingIncome": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "researchDevelopment": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "totalRevenue": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- }
- },
- "type": "object"
- },
- {
- "type": "null"
- }
- ]
- },
- "type": "array"
- },
- {
- "type": "null"
- }
- ]
- },
- "yearly": {
- "anyOf": [
- {
- "items": {
- "anyOf": [
- {
- "additionalProperties": {},
- "properties": {
- "currency_symbol": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "date": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "ebit": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "ebitda": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "filing_date": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "grossProfit": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "incomeBeforeTax": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "incomeTaxExpense": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "netIncome": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "operatingIncome": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "researchDevelopment": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "totalRevenue": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- }
- },
- "type": "object"
- },
- {
- "type": "null"
- }
- ]
- },
- "type": "array"
- },
- {
- "type": "null"
- }
- ]
- }
- },
- "type": "object"
- },
- {
- "type": "null"
- }
- ]
- }
- },
- "type": "object"
- },
- {
- "type": "null"
- }
- ]
- },
- "General": {
- "anyOf": [
- {
- "additionalProperties": {},
- "properties": {
- "Code": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "CountryISO": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "CountryName": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "CurrencyCode": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "CurrencyName": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "CurrencySymbol": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "Description": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "Exchange": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "FiscalYearEnd": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "FullTimeEmployees": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "GicIndustry": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "GicSector": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "GicSubIndustry": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "IPODate": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "ISIN": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "Industry": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "LEI": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "Name": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "Officers": {
- "anyOf": [
- {
- "items": {
- "anyOf": [
- {
- "additionalProperties": {},
- "properties": {
- "Name": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "Title": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "YearBorn": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- }
- },
- "type": "object"
- },
- {
- "type": "null"
- }
- ]
- },
- "type": "array"
- },
- {
- "type": "null"
- }
- ]
- },
- "PrimaryTicker": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "Sector": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "Type": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- }
- },
- "type": "object"
- },
- {
- "type": "null"
- }
- ]
- },
- "Highlights": {
- "anyOf": [
- {
- "additionalProperties": {},
- "properties": {
- "BookValue": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "DilutedEpsTTM": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "DividendShare": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "DividendYield": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "EPSEstimateCurrentYear": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "EPSEstimateNextYear": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "EarningsShare": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "GrossProfitTTM": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "MarketCapitalization": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "MostRecentQuarter": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "OperatingMarginTTM": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "PEGRatio": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "PERatio": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "ProfitMargin": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "QuarterlyEarningsGrowthYOY": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "QuarterlyRevenueGrowthYOY": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "ReturnOnEquityTTM": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "RevenuePerShareTTM": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "RevenueTTM": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- }
- },
- "type": "object"
- },
- {
- "type": "null"
- }
- ]
- },
- "SharesStats": {
- "anyOf": [
- {
- "additionalProperties": {},
- "properties": {
- "PercentInsiders": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "PercentInstitutions": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "SharesFloat": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "SharesOutstanding": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- }
- },
- "type": "object"
- },
- {
- "type": "null"
- }
- ]
- },
- "SplitsDividends": {
- "anyOf": [
- {
- "additionalProperties": {},
- "properties": {
- "ExDividendDate": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "ForwardAnnualDividendRate": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "ForwardAnnualDividendYield": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "LastSplitDate": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "LastSplitFactor": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "NumberDividendsByYear": {
- "anyOf": [
- {
- "items": {
- "anyOf": [
- {
- "additionalProperties": {},
- "properties": {
- "Count": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "Year": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- }
- },
- "type": "object"
- },
- {
- "type": "null"
- }
- ]
- },
- "type": "array"
- },
- {
- "type": "null"
- }
- ]
- },
- "PayoutRatio": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- }
- },
- "type": "object"
- },
- {
- "type": "null"
- }
- ]
- },
- "Technicals": {
- "anyOf": [
- {
- "additionalProperties": {},
- "properties": {
- "200DayMA": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "50DayMA": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "52WeekHigh": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "52WeekLow": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "Beta": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- }
- },
- "type": "object"
- },
- {
- "type": "null"
- }
- ]
- },
- "Valuation": {
- "anyOf": [
- {
- "additionalProperties": {},
- "properties": {
- "EnterpriseValue": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "EnterpriseValueEbitda": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "EnterpriseValueRevenue": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "ForwardPE": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "PriceBookMRQ": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "PriceSalesTTM": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "TrailingPE": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- }
- },
- "type": "object"
- },
- {
- "type": "null"
- }
- ]
- },
- "outstandingShares": {
- "anyOf": [
- {
- "additionalProperties": {},
- "properties": {
- "annual": {
- "anyOf": [
- {
- "items": {
- "anyOf": [
- {
- "additionalProperties": {},
- "properties": {
- "date": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "dateFormatted": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "shares": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "sharesMln": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- }
- },
- "type": "object"
- },
- {
- "type": "null"
- }
- ]
- },
- "type": "array"
- },
- {
- "type": "null"
- }
- ]
- },
- "quarterly": {
- "anyOf": [
- {
- "items": {
- "anyOf": [
- {
- "additionalProperties": {},
- "properties": {
- "date": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "dateFormatted": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "shares": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "sharesMln": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- }
- },
- "type": "object"
- },
- {
- "type": "null"
- }
- ]
- },
- "type": "array"
- },
- {
- "type": "null"
- }
- ]
- }
- },
- "type": "object"
- },
- {
- "type": "null"
- }
- ]
- }
- },
- "type": "object"
-}New value: +nullfundamentals_forecastfundamentals_keyfiguresgeneral_accountgeneral_creditsgeneral_dailyrequestsleftgeneral_directorygeneral_exchangesgeneral_screener8 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseInput schema / properties / filtersAdded value: +{
+ "description": "JSON array of [field, op, value]. Listing fields: adjusted_close, avgvol_1d, avgvol_200d, code, dividend_yield, earnings_share, exchange, industry, market_capitalization, name, refund_1d_p, refund_5d_p, sector. Highlights: BookValue, DilutedEpsTTM, DividendShare, DividendYield, EBITDA, EPSEstimateCurrentQuarter, EPSEstimateCurrentYear, EPSEstimateNextQuarter, EPSEstimateNextYear, EarningsShare, GrossProfitTTM, MarketCapitalization, MarketCapitalizationMln, MostRecentQuarter, OperatingMarginTTM, PEGRatio, PERatio, ProfitMargin, QuarterlyEarningsGrowthYOY, QuarterlyRevenueGrowthYOY, ReturnOnAssetsTTM, ReturnOnEquityTTM, RevenuePerShareTTM, RevenueTTM, WallStreetTargetPrice. Keyfigures: EBITDA_margin, EBITDA_margin_rolling_quarters, EBIT_margin, EBIT_margin_rolling_quarters, EPSEstimateCurrentQuarter, EPSEstimateCurrentYear, EPSEstimateNextQuarter, EPSEstimateNextYear, ForwardPE, PEGRatio, PercentInsiders, PercentInstitutions, ShortPercentFloat, analyst_rating, analyst_upside, cashflow_growth, cashflow_growth_rolling_quarters, cashflow_margin, cashflow_margin_rolling_quarters, current_ratio, current_ratio_rolling_quarters, debt_to_equity, debt_to_equity_rolling_quarters, dynamic_debt, dynamic_debt_rolling_quarters, earnings_growth, earnings_growth_5y_cagr, earnings_growth_rolling_quarters, equity_ratio, equity_ratio_rolling_quarters, estimate_eps_growth_1y, estimate_eps_growth_2y, free_cashflow, free_cashflow_rolling_quarters, free_cashflow_yield, free_cashflow_yield_rolling_quarters, gross_margin, gross_margin_rolling_quarters, interest_coverage, interest_coverage_rolling_quarters, leverage, leverage_rolling_quarters, liquidity, liquidity_rolling_quarters, net_income_margin, net_income_margin_rolling_quarters, r_and_d_investment_sales, r_and_d_investment_sales_rolling_quarters, return_on_assets, return_on_assets_rolling_quarters, return_on_equity, return_on_equity_rolling_quarters, return_on_liabilities, return_on_liabilities_rolling_quarters, sales_growth, sales_growth_3y_cagr, sales_growth_5y_cagr, sales_growth_rolling_quarters, stock_buybacks, stock_buybacks_rolling_quarters, wallstreet_estimate_upside. Derived: MarketCapitalizationUSD is USD-normalized from local-currency Highlights.MarketCapitalization using the latest available FX rate. Aliases: ebit_margin→EBIT_margin, market_cap→MarketCapitalization, market_cap_usd→MarketCapitalizationUSD, operating_margin→OperatingMarginTTM, pe→PERatio, pe_ratio→PERatio, roa→ReturnOnAssetsTTM, roe→ReturnOnEquityTTM. String ops: =, match. Numeric ops: =, >, <, >=, <=.. Example: [[\"exchange\",\"=\",\"XETRA\"],[\"pe\",\"<\",15]]",
+ "type": "string"
+}Input schema / properties / limitAdded value: +{
+ "description": "Number of results to return. Default 50, min 1, max 1000.. Example: 50",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+}Input schema / properties / offsetAdded value: +{
+ "description": "Pagination offset. Default 0, max 999.. Example: 0",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+}Input schema / properties / presetAdded value: +{
+ "description": "Named filter preset. Currently: quality (ReturnOnEquityTTM>0.15, ReturnOnAssetsTTM>0.1, OperatingMarginTTM>0.15, debt_to_equity<0.5, current_ratio>1.5, interest_coverage>5, earnings_growth_5y_cagr>0.05, sales_growth_5y_cagr>0.05, free_cashflow>0, MarketCapitalizationUSD>10000000000, PERatio<30). Matching filter fields in filters override the preset thresholds. Max limit 1000.. Example: quality",
+ "type": "string"
+}Input schema / properties / signalsAdded value: +{
+ "description": "Comma-separated market signals: 200d_new_hi (price at a new 200-day high); 200d_new_lo (price at a new 200-day low); 50d_new_hi (price at a new 50-day high); 50d_new_lo (price at a new 50-day low); bookvalue_neg (price below book value); bookvalue_pos (price above book value); wallstreet_hi (price above Wall Street target); wallstreet_lo (price below Wall Street target).. Example: 200d_new_hi",
+ "type": "string"
+}Input schema / properties / sortAdded value: +{
+ "description": "Sort by a numeric result field using field.asc or field.desc. market_capitalization is in the listing currency. MarketCapitalizationUSD is in USD, converted from the listing currency at the latest available FX rate. Sorting by MarketCapitalizationUSD requires a filter on MarketCapitalizationUSD or market_cap_usd.. Example: market_capitalization.desc",
+ "type": "string"
+}general_symbolsgovernment4 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / fromAdded value: +{
+ "description": "First date, YYYY-MM-DD",
+ "type": "string"
+}Input schema / properties / seriesAdded value: +{
+ "description": "Series id from GET /government",
+ "type": "string"
+}Input schema / properties / toAdded value: +{
+ "description": "Last date, YYYY-MM-DD",
+ "type": "string"
+}government_serieshistoricalquoteshistoricalquotes_benchmarkhistoricalquotes_marketcaphistoricalquotes_marketcap_aggregationhistoricalquotes_marketwide-lastday-quoteimg_logosimg_logosbycodeexchangeintradaylivelive_relative-movemacro3 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / viewAdded value: +{
+ "description": "indicators, countries, or one country series.",
+ "enum": [
+ "indicators",
+ "countries",
+ "series"
+ ],
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "country"
-]New value: +[
+ "view"
+]macro_countriesmacro_indicatorsmarket_capmarket_lastdaypricesprices_relative_movesentimentsentiment_breadthsentiment_breadth_seriessentiment_breadth-volumesentiment_breadth-volume_seriessentiment_cotsentiment_cot_seriessentiment_fear-indexsentiment_naaimsentiment_scesentiment_sce_seriessentiment_smart-moneyfundamentals_keyfigures2 fields changedInput schema / properties / fieldsAdded value: +{
+ "description": "Comma-separated series names, for example stock_buybacks,EBIT_margin. Omit to return every series.",
+ "type": "string"
+}Input schema / properties / fromAdded value: +{
+ "description": "YYYY-MM-DD. Points before this date are omitted.",
+ "type": "string"
+}sentiment_breadth-volumesentiment_breadth-volume_seriessentiment_cot1 field changedInput schema / properties / activeAdded value: +{
+ "description": "true (default), false, or all",
+ "type": "string"
+}sentiment_cot3 fields changedInput schema / properties / contractAdded value: +{
+ "description": "One CFTC market code",
+ "type": "string"
+}Input schema / properties / reportAdded value: +{
+ "description": "disagg, tff, or legacy",
+ "type": "string"
+}Input schema / properties / setAdded value: +{
+ "description": "Pass all to list every stored series",
+ "type": "string"
+}sentiment_breadthsentiment_breadth_seriessentiment_scesentiment_sce_seriesgovernmentgovernment_seriessentiment_cotsentiment_cot_seriessentiment_fear-indexsentiment_naaimsentiment_smart-moneyai_asset_eventsai_asset_price-driversai_asset_timelineai_asset_whatsnewai_market_cio-viewai_market_dailyai_market_timeline-weeklyai_market_topicsai_market_weeklyai_research_competitorsai_research_industryai_research_price-driversai_research_risksai_research_sectorai_research_timelineai_whatsnewbonddividendsdividends_historyevents_earningsevents_iposevents_splitsevents_trendsfundamentalsfundamentals_forecastfundamentals_keyfiguresgeneral_creditsgeneral_dailyrequestsleftgeneral_exchangesgeneral_isingeneral_mainstockgeneral_screenergeneral_symbolsgeneral_tradingperiodhistoricalquoteshistoricalquotes_benchmarkhistoricalquotes_marketcaphistoricalquotes_marketcap_aggregationhistoricalquotes_marketwide-lastday-quoteimg_logosimg_logosbycodeexchangeintradaylivelive_relative-movemacromacro_countriesmacro_indicatorsnewsratingssplits
Add one secure layer between your agents and this server.