Official economic statistics, company filings, earnings calls and market data - extracted from first party sources, with sources cited.
Scored across 14 tools
Most tools target clearly distinct resources and actions: catalog, dataset search, series search, SQL, filings, transcripts, media, news, market data, geo data, and feedback. The main ambiguity is among the discovery tools—search_datasets, search_series, describe_dataset, and get_data_catalog—where an agent may initially struggle to choose the right entry point. get_series versus run_sql also overlaps slightly, but the descriptions give strong guidance.
All tool names use consistent snake_case and follow recognizable verb_noun patterns, with clean get_*, search_*, and action-style families such as run_sql and send_feedback. There are no mixed naming conventions or confusing abbreviations.
Fourteen tools is well within the appropriate range for a broad financial and economic data platform. Each tool earns its place by covering a distinct part of discovery, retrieval, analysis, or feedback, and the set does not feel padded.
The surface covers the major lifecycle: catalog discovery, dataset and series search, metadata inspection, direct series retrieval, SQL analysis, market data, geo data, company filings, earnings calls, media appearances, news, style guidance, and feedback. Minor gaps exist in that full document or transcript bodies are not directly retrievable, but source links and row-level evidence mitigate this by design.
Full metadata for one dataset: topic, methodology, discontinuities,
any base-change notice, plus the live dimensions and example series.
Call after search_datasets narrows you to a dataset.
| Name | Required | Description | Default |
|---|---|---|---|
| schema | Yes | ||
| dataset_code | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the description is not carrying that burden. It adds that the returned dimensions and series are "live," which usefully explains the surprising idempotentHint=false, but it says nothing about failure modes when a dataset_code is unknown or about size/latency of the metadata payload.
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 sentences, zero filler, with the payload contents front-loaded and the sequencing instruction trailing as a natural second clause. Nothing could be cut without losing 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?
Output schema exists, so return values did not need explaining, and annotations cover the safety profile. The real gap is the two undocumented required parameters with 0% schema coverage, which is exactly where the description should have compensated and did not.
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 0% and the description never mentions either required parameter. `dataset_code` is inferable from context, but `schema` (which namespace/domain to resolve the code against) is completely unexplained by both schema and description, so the agent must guess.
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 (describe) and resource (one dataset), then enumerates the actual payload: topic, methodology, discontinuities, base-change notice, live dimensions, example series. It also names the sibling it follows (search_datasets), so an agent can place it in the pipeline 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?
"Call after `search_datasets` narrows you to a dataset" gives explicit sequencing and names the alternative tool that produces its input. There is no when-not guidance (e.g. do not call with a raw dataset name you have not resolved, or bulk use), which keeps it short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the data sources FactIQ has, plus the shared table structure.
Call this once before exploring. Returns the visible schemas (organization +
country), the ones with no data loaded yet (schemas_without_data — skip
them), a per-schema dataset index, and the shared DDL for the series,
data_points, dimensions and compound_series tables.
schemas: optional comma-separated filter (e.g. "bls,bea"). full: heavy per-dataset descriptions instead of the compact index.
| Name | Required | Description | Default |
|---|---|---|---|
| full | No | ||
| schemas | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the description only needs to add context — and it does: it warns about empty schemas to skip and flags that `full` returns heavy per-dataset descriptions instead of the compact index. It does not mention response size limits or cost implications of `full`.
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 core purpose, then a compact block covering what is returned and warnings, then a short line per parameter. Every sentence carries information; 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 two-parameter read-only catalog call, the description covers purpose, timing, return contents, skip conditions, and both parameter behaviors. An output schema exists, yet the description still usefully summarizes the payload 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 description coverage is 0%, so the description must carry both parameters — and it does, with syntax ('optional comma-separated filter (e.g. "bls,bea")') for `schemas` and a behavioral tradeoff description for `full`. This fully compensates for the empty schema 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 verb and resource ('List the data sources FactIQ has, plus the shared table structure') and enumerates exactly what comes back (visible schemas, per-schema dataset index, shared DDL). The 'Call this once before exploring' framing distinguishes it from siblings like search_datasets and describe_dataset as the entry-point inventory 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?
Gives clear timing guidance ('Call this once before exploring') and an actionable exclusion rule ('schemas_without_data — skip them'). It does not name alternative tools such as search_datasets or describe_dataset, so the routing is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get satellite-derived indicators aggregated over a country, one state/province, or a bounding box. Use for fires, emissions-based activity, rainfall, vegetation, temperature, and soil-moisture questions.
For a sub-national area, call one state/province at a time. Informal regions such as "north India" or "the Midwest" have no boundary, so cover them with one call per state or a bounding box; using the whole country answers a different question. Grid cells and fire detections are activity snapshots, never fire perimeters. For ndvi_s2 and *_tropomi grids, drop or flag cells with low valid_obs_share. Results include units, source attribution, and caveats; cite the attribution. External-provider calls can take about 30 seconds, and rainfall or grid calls can take longer.
| Name | Required | Description | Default |
|---|---|---|---|
| region | Yes | Region as an ISO3 code or country name ("IND" or "India"); "Country/State" or "ISO3/State" ("India/Punjab" or "CHN/Guangdong") for a state/province; or "bbox:west,south,east,north" in degrees. State/province boundaries are available for IND, CHN, IDN, VNM, THA, MYS, PHL, PAK, BGD, LKA, MMR, KHM, NPL, KOR, JPN, TWN, and USA. | |
| dataset | Yes | Satellite dataset. One of: - "fires_viirs": active fire detections and fire radiative power (NASA FIRMS, 2012->, one day behind). Covers crop-residue burning, forest fires, and flaring. - "no2_tropomi": tropospheric NO2 column (Sentinel-5P, 2018->, ~3 days), an industrial/traffic activity proxy. Check valid_obs_share; cloudy intervals below 0.2 are weakly supported. - "so2_tropomi": SO2 column (Sentinel-5P, 2018->, ~3 days) for coal power, smelting, refining, and volcanoes. Noisy away from strong sources; track trends rather than absolute background levels. - "co_tropomi": CO column (Sentinel-5P, 2018->, ~3 days) for biomass/crop burning and industrial combustion. CO drifts across borders and is seasonal, so compare the same season across years. - "aerosol_index_tropomi": UV aerosol index (Sentinel-5P, 2018->, ~3 days) for smoke, dust, and haze. It is dimensionless; sustained values above ~1 indicate heavy smoke or dust, and it works over clouds. - "ndvi_s2": cloud-masked vegetation NDVI (Sentinel-2, 2017->, ~2-5 days), a crop-condition signal. Check valid_obs_share and compare the same season across years. - "precip_chirps": gauge-calibrated rainfall (CHIRPS, 1981->, ~2 days, 50S-50N) for monsoon, drought, and flood risk. - "precip_imerg": rainfall totals (NASA IMERG V07 Late, 2000->, ~1-2 days, global at 0.1 degree). Use where CHIRPS has no coverage; daily and monthly values are rainfall totals. - "temperature_power": mean/max/min 2m air temperature (NASA POWER, 1981->, ~3 days) for heatwaves and energy demand. - "soil_moisture_power": root-zone soil wetness from 0 to 1 (NASA POWER, 1981->, ~3 days) for agricultural drought. - "wind_power": 10m wind speed, daily maximum, eastward and northward components, the direction the wind blows from, and a 0-1 steadiness score (NASA POWER, 1981->, ~3 days). Use it to separate weather from emission changes in air-pollution data and to trace where smoke comes from. - "humidity_power": 2m relative humidity in % (NASA POWER, 1981->, ~3 days), a weather control for haze and fine particles. NASA POWER serves MERRA-2 up to a cut-off date (2026-08-31 at the time of writing) and the GEOS-IT system after it. The two models sit at different levels, so a one-day step across that date in a POWER dataset is a model change, not weather. | |
| end_date | Yes | Inclusive end date in ISO YYYY-MM-DD format. | |
| resolution | No | Optional fires_viirs grid-cell size in degrees when aggregation="grid"; one of 0.005, 0.01, 0.02, 0.05, 0.1, 0.2, 0.5, 1, 2, or 5. Omit it to choose a size automatically from the region. Values finer than 0.1 read individual detections and return the 500 busiest cells. Not accepted by other datasets or aggregation modes. | |
| start_date | Yes | Inclusive start date in ISO YYYY-MM-DD format. | |
| aggregation | No | Aggregation mode. "monthly" (default) or "daily" returns a time series. Most datasets allow at most 50 intervals per call (~4 years monthly or ~7 weeks daily); fires_viirs allows 200 (~16 years monthly or ~7 months daily). fires_viirs, ndvi_s2, and *_tropomi also accept "grid": one spatial row per lat/lon cell over the whole window, at most 500 rows, with a 92-day maximum window (366 days for fires). fires_viirs also accepts "seasons", which repeats the requested calendar window in every year since 2012 and returns one row per year, and "points", which returns exact detections only when the window contains at most 500; otherwise use grid or narrow the window. | monthly |
| include_flares | No | fires_viirs only. False by default, excluding gas flares, other permanent industrial heat sources, volcanoes, and offshore detections so only vegetation fires are counted. Set true over a gas field or to count every detection NASA publishes. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, open-world, idempotent=false, non-destructive, but the description adds substantial behavior beyond them: ~30s latency for external providers (longer for rainfall/grid), the fact that grids and detections are activity snapshots rather than fire perimeters, and that results carry units, source attribution, and caveats that must be cited. This is exactly the extra operational context the annotations cannot express.
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 paragraphs, front-loaded with the core capability before the operational caveats. It is slightly dense and packs several distinct rules (region enumeration, grid caveats, attribution, latency) into one block, but no sentence is 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 7-parameter tool with a full input schema and an output schema, the description supplies everything else an agent needs: scope selection, spatial granularity traps, data-quality handling, and latency expectations. Return-value detail is correctly 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%, so the baseline is 3; the description lifts it by adding usage-level semantics for region (sub-national boundaries must be enumerated, informal regions have none) and for grid outputs (ndvi_s2 and *_tropomi valid_obs_share handling). It doesn't restate per-dataset parameter rules that the schema already covers in depth, which 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 first sentence names a specific verb and resource (retrieval of satellite-derived indicators) and states the three supported spatial scopes (country, state/province, bounding box). It enumerates the subject areas (fires, emissions, rainfall, vegetation, temperature, soil moisture), which cleanly separates it from siblings like get_market_data or search_news.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit routing guidance: call one state/province at a time, cover informal regions ('north India') with per-state calls or a bbox, and a stated reason why the country-level call answers a different question. It also flags when to drop/flag low valid_obs_share cells and cites the alternative caveats, giving the agent concrete when-to-use and when-not-to-use rules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent market data the warehouse lags on: quotes, OHLCV, company profiles, FX, and commodities.
Set data_type to price_history for stocks, currency pairs, and commodities; the asset format determines which market is queried. Use search_company_filings for financial statements and reported facts.
| Name | Required | Description | Default |
|---|---|---|---|
| asset | Yes | Ticker, currency pair, commodity, or company-search text. Examples: "AAPL", "EUR/USD", "WTI", "Brent", "NVIDIA". | |
| limit | No | Maximum number of historical price rows to request. | |
| data_type | No | The market or profile data to return. | price_history |
| frequency | No | Price-history frequency. Defaults to daily. | daily |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, non-destructive, open-world behavior, so the bar is lower. The description adds genuinely useful context the annotations don't: data is recent but the warehouse lags on it, and the asset format determines which market is queried. No auth, rate-limit, or pagination detail is given, but limit is documented in the schema.
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 what the tool returns, then parameter guidance, then the sibling alternative. The opening phrase 'the warehouse lags on' is slightly awkward but carries real freshness information rather than 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?
With an output schema present, annotations covering the safety profile, and 100% parameter description coverage, the description only needs to add routing and freshness context — which it does. Nothing an agent needs to call this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaning beyond the schema by explaining the cross-parameter interaction (asset format determines the market queried) and by prescribing a concrete data_type value for the common stock/currency/commodity case.
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 and its scope (quotes, OHLCV, company profiles, FX, commodities) and explicitly routes the agent away from search_company_filings for financial statements. An agent can tell what this tool returns 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 concrete selection guidance ('Set data_type to price_history for stocks, currency pairs, and commodities') and names an alternative tool with the condition that selects it. It stops short of explaining when to prefer the other data_type values (quote vs company_profile vs symbol_search) or when not to call this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one series' data: timeseries, tabular, or COMPOUND:: all work.
Returns title, units, frequency, notes and data points, with source metadata.
transform="yoy_pct" (percent change) or "yoy_diff" (difference, for rates)
adds a column with the change versus the same period one year earlier,
matched by calendar date — use it for inflation or growth from one series
instead of a LAG(value, 12) query, which goes wrong after any missing
month. The cell is null where the prior-year period is absent, and
transform.periods_without_prior lists those periods.
The transformed value is rounded to 4 decimal places; round it once more
only when you write the final figure, at the precision you report.
If the result carries a coverage_note, the series has periods with no
observation (listed in missing_periods): say so in the answer, leave them
blank rather than interpolating, and label any aggregate that spans them
as partial.
SEC-backed results include row_sources keyed by result_index; each entry
identifies the supporting filing, accession/form/publication date, whether
the observation is reported or derived, and its standardized source_link.
Cite that row's source URL beside any figure and label derived observations
as derived. A document-precision link does not open an exact passage.
IMF (imf schema) results also carry projections_start_after (the last
year the IMF counts as actual; later years are IMF staff projections),
release_label (the IMF publication, e.g. "Fiscal Monitor (October
2026)") and, when either is known, a projection_note. Say which years
are projections when you use them. Both fields are null when the IMF
gives no such fact for the series.
At most 50 points come back; if the series is longer the result is flagged
"truncated": true — narrow it with from_year/to_year, or pull the series
through run_sql with an aggregation (e.g. monthly/quarterly via
date_trunc) rather than trying to fetch every point.
| Name | Required | Description | Default |
|---|---|---|---|
| schema | Yes | ||
| to_year | No | ||
| from_year | No | ||
| series_id | Yes | ||
| transform | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover the read-only/safe profile, and the description layers substantial operational detail on top: a hard 50-point cap with a `truncated` flag, null cells where prior-year data is absent, a `transform.periods_without_prior` list, 4-decimal rounding, and mandatory disclosure behavior when `coverage_note`/`missing_periods` appear. It further documents SEC `row_sources` provenance and IMF projection semantics with citation obligations — far beyond what the 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?
Front-loaded with purpose and the transform rationale before edge cases, and nearly every paragraph carries actionable instruction. It is on the long side and the rounding sentence ("round it once more only when you write the final figure") is slightly convoluted, but no block is 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?
An output schema exists, yet the description still explains the fields that change agent behavior (truncation, coverage notes, provenance, projections) rather than restating the shape. The remaining gap is the allowed `schema` values and series_id discovery, which forces the agent to consult search_series or the catalog.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must carry parameter meaning. It does this well for `transform` (both enum values, purpose, null behavior, rounding) and adequately for `from_year`/`to_year` (narrowing a truncated range), but `series_id` and `schema` are barely specified — only `imf` is named as a schema value, with no enumeration of the rest or any hint of series_id 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?
Opens with a specific verb and resource ("Fetch one series' data") and scopes the accepted series shapes (timeseries, tabular, COMPOUND). It also enumerates the returned payload (title, units, frequency, notes, data points, source metadata), so an agent can distinguish it from search_series and run_sql without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit routing for the two decisions that matter: use `transform="yoy_pct"`/`"yoy_diff"` instead of a `LAG(value, 12)` query, and use `from_year`/`to_year` or `run_sql` with `date_trunc` when the 50-point cap truncates. What it does not state is when to reach for this versus sibling retrievers like search_series, get_market_data, or get_geo_data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch FactIQ's house-style authoring guides so anything you build matches FactIQ's conventions and look. Call this before producing a chart, a report, or written analysis from FactIQ data, and follow what it returns. By default, use FactIQ's style for all FactIQ work unless the user asks otherwise.
You can fetch several at once. Pass any combination of:
"chart" — how to build and style a FactIQ chart: which chart type, finding- style titles, data hygiene, the FactIQ colour palette and plot surface, and sourcing
"report" — report structure, voice, and per-chart sourcing
"sql" — query idioms and pitfalls for FactIQ's tables
"earnings" — quoting discipline, spoken-vs-filed sourcing, guidance tables, and claim-verification patterns for anything built from search_earnings_transcripts
"all" — every guide
Returns each requested guide's markdown text, keyed by name. This is free — it does not count against your tool quota.
| Name | Required | Description | Default |
|---|---|---|---|
| guides | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/destructive/idempotent profile, but the description adds real behavioral context: the return is markdown keyed by guide name, multiple guides can be fetched in one call, and the call is free (does not count against quota). The quota note is a genuinely useful operational trait not present in structured fields.
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 purpose and the when-to-call rule before the bulleted value list, and every bullet earns its place by defining a distinct option. The multi-line quoting/indentation of the bullets is slightly noisy but not wasteful.
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 purpose, timing, default policy, all valid parameter values, and the shape of the return (markdown keyed by name) plus the quota implication. With an output schema present, nothing further is needed for an agent to invoke this 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 0% and the array items have no enum, so the description carries the full burden — and it does: it enumerates all five valid values (chart, report, sql, earnings, all) and explains what each guide covers, including which sibling tool the 'earnings' guide relates to.
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 (fetch FactIQ's house-style authoring guides) plus the reason (so output matches FactIQ conventions). Clearly distinguishable from siblings like run_sql or search_news, which fetch data rather than authoring conventions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use: 'Call this before producing a chart, a report, or written analysis from FactIQ data.' It also gives a default policy ('use FactIQ's style for all FactIQ work unless the user asks otherwise') and tells the agent to follow the returned content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a read-only SELECT against the FactIQ data warehouse, scoped to one schema — the power tool for joins, pivots and aggregation.
Read-only role, 30s statement timeout, with FactIQ's query transforms and
series-metadata enrichment. Resolve ids from series before filtering
data_points. auto_retry=true opts into a server-side reviser on zero
rows. See the factiq://guide/sql resource.
Returns at most 50 rows. If the query matches more, the result is flagged
"truncated": true — that is your cue to aggregate or compute in SQL
(GROUP BY, date_trunc, a SUM/AVG/rank/ratio) and return that, NOT to try
to fetch the raw rows. A chart or a summary needs the aggregated result, and
large raw results don't fit in context anyway.
Year-over-year and other period comparisons must join on the calendar
period (date_trunc('month', prior.time) = date_trunc('month', cur.time) - interval '1 year' — the stored day of the month varies by source, so never
compare exact dates), never on a row offset such as
LAG(value, 12) OVER (ORDER BY time): a series with one missing month
compares the wrong periods for the twelve rows after the gap (LEAD: the
twelve before it) and the numbers still look plausible. For one series prefer get_series with transform. When
the result carries a coverage_note, the rows have periods with no
observation (listed in missing_periods, per series): name them in the
answer, do not interpolate, and label any aggregate that spans them as
partial.
page is the one exception and works only on the nasa_fires schema, where
a row is a single fire detection that belongs to no series and so cannot be
aggregated into one. Each page holds 50 rows; the answer carries page and
has_more, and you read the next block with page=2, page=3 and so on.
Give the query an ORDER BY, otherwise Postgres may return the same row on
two pages and never return another. Still prefer a count or a total when
that answers the question — paging through thousands of detections does not.
Runs through FactIQ's read-only database role, which rejects any attempt to modify data (INSERT/UPDATE/DELETE/DROP/…).
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | ||
| page | No | ||
| schema | Yes | ||
| explore | No | ||
| question | No | ||
| auto_retry | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/destructiveHint=false, but the description adds substantial behavioral context: the read-only role that rejects INSERT/UPDATE/DELETE/DROP, a 30s statement timeout, query transforms and series-metadata enrichment, the 50-row cap with `truncated`, and coverage_note/missing_periods semantics. Slight deduction only because the treatment is encyclopedic rather than focused.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The opening sentence front-loads purpose and the paragraphs are organized by concern (limits, period comparison, pagination, safety). It is long and includes some redundancy (the read-only role is stated at the top and restated at the bottom), but nearly every sentence carries actionable content.
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 complex power tool with six parameters, an output schema, and truncation/pagination/coverage behaviors, the description covers the failure modes an agent must anticipate. An output schema exists, so return-value enumeration isn't required, and the description still flags the fields that change how the agent must respond.
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 0%, so the description carries the full burden. It documents `page` (nasa_fires only, 50 rows per page), `auto_retry` (server-side reviser on zero rows), and scoping via `schema`, but never explains `explore` or `question` — two of six parameters are left undocumented in both schema and description.
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 ('Run a read-only SELECT against the FactIQ data warehouse, scoped to one schema') and positions itself as 'the power tool for joins, pivots and aggregation', which differentiates it from the sibling get_series it later names for single-series work.
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: prefer get_series with transform for one series, aggregate in SQL rather than fetch raw rows on truncation, use `page` only on the nasa_fires schema, and use auto_retry on zero rows. Also describes the required join idiom for period comparisons and warns against LAG offsets — real when-to-use guidance, not just an implied context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
This is FactIQ's central tool for company filings. It searches structured facts and report metadata from one company's filed reports, for every company in the filings store: US SEC filers (10-K, 10-Q, 8-K, plus 20-F, 40-F, 6-K for foreign filers, and the IPO registration statements S-1 and F-1 with the final prospectus, 424B4 or 424B1) and companies listed in Germany, the UK, France and Switzerland (annual, half-year, Q1, and Q3 reports; for example company="BAS" for BASF SE from German issuer reports in EUR, company="ULVR" for Unilever plc from the FCA National Storage Mechanism, company="MC.PA" for LVMH from the AMF via info-financiere.gouv.fr, and company="NESN" for Nestlé from the reports on the company's own website; UK values are in the issuer's reporting currency, GBP, USD or EUR, French values in EUR, and Swiss values in the issuer's reporting currency, CHF, USD or EUR). A UK, French or Swiss company whose symbol is also a US ticker is stored with its exchange suffix (.L London, .PA Paris, .SW Zurich); the bare symbol goes to the SEC filer, so company="MC" is Moelis & Company and company="MC.PA" is LVMH. It also covers the Nifty 50 companies listed in India, from the quarterly financial results they file with the National Stock Exchange (Q1 to Q4; the Q4 results also carry the audited full-year figures; values in INR; for example company="RELIANCE" for Reliance Industries). It also covers large companies listed in Japan, from the securities reports they file on EDINET, and in South Korea, from the business reports they file on DART (annual, half-year, Q1, and Q3 reports; values in JPY or KRW as filed; for example company="7203.T" for Toyota Motor and company="005930.KS" for Samsung Electronics). The search is deterministic and does not call a language model. Every successful response is a tree and does not expose database row IDs. Set format="json" for the structured tree field. Set format="pretty" for only a human-readable rendered_tree text. The two formats are never returned together. JSON filing and fact nodes retain source_url and add a standardized source_link object for the original filing/report; the pretty rendering ends with a "Source documents" list mapping each cited filing to its URL. When using a returned figure, place its source URL beside the claim as a Markdown link, for example: FY2025 revenue was $40.0B (Visa Inc. FY2025 10-K). A sources line that names the filing without linking its URL is not sufficient. Do not make a second call solely to find a citation or substitute a related press release. source_precision="document" means the URL opens the source document, not an exact passage.
Use an exact ticker when possible. A company name is accepted only when it identifies one issuer. A share-class sibling ticker resolves to the same SEC filer (for example GOOGL resolves to the stored GOOG). If a ticker has several exact matches, possible_matches lists every tied company and its identifiers. When nothing matches, possible_matches lists the closest stored companies. When a bare ticker resolves to one company and other companies are stored under that ticker plus an exchange suffix (MC resolves to Moelis & Company; MC.PA is LVMH), the result is still the bare-ticker company and possible_matches lists the suffixed companies.
concept selects one registered financial concept and returns it over time. For example, concept="revenue" selects the best revenue concept stored for that company. The response states the selected concept. Use query instead for a broad search across several concepts.
search_target controls the tree content. coverage shows available report types and dates. filings shows report records and source URLs. metrics shows available concepts, dimensions, units, and period coverage. facts shows reported numeric values. An empty facts browse is filing-first. A facts search with query or concept is concept-first so that values across reporting periods stay together. For a US-listed company that went public recently, statement facts for the periods before its first periodic report come from the financial statement pages of its IPO registration statement, and single quarters also come from the quarterly results table that many prospectuses print in their MD&A (report_type="quarterly" returns them); a figure that a later report states for the same period replaces it. metric_class="offering_terms" returns the offering price, shares offered and proceeds printed in the registration statement.
commentary and risk_changes return qualitative statements extracted from SEC filings when each filing was processed; every statement carries a verbatim quote from the filing. commentary returns management's explanatory statements from MD&A sections and earnings press releases: growth drivers, demand and pricing commentary, capacity and execution milestones, strategy changes, and vaguely quantified statements such as "grew mid-teens" with a numeric range attached. risk_changes returns year-over-year changes in the stated risk factors of annual reports (Item 1A or Item 3.D): new, modified, and removed risks, with the changed passage quoted. A period with no risk_changes rows means the risk factors were unchanged from the prior year only when the result's annual_report_years lists that year as compared; other years were never compared. A year also listed in compared_with_prospectus was compared with the IPO prospectus, so no rows means unchanged from the prospectus. It never means that the company reported no risks. commentary also returns the MD&A statements of a company's final IPO prospectus; set report_type="424B4" (or "424B1") to read only those. Both targets cover US SEC filers only; commentary and risk_changes remain SEC-only and return no rows for German, UK, French, Swiss, Indian, Japanese, or Korean issuer reports.
query searches concept names, source labels, source codes, XBRL concepts, aliases, definitions, and segment names. For commentary and risk_changes it searches topics, statements, and quotes. Filters are applied before search. report_type accepts a common report type (annual, quarterly, half_year) or a source form such as 10-K or 10-Q. For German, UK, and French filers, quarterly covers the Q1, half-year, and Q3 reports; their source forms are the document codes of the source (FCA ACS, FR, IR; AMF AMF-RFA, AMF-RFS, AMF-IT, AMF-URD, AMF-RES). An Indian company files no separate annual report: its Q4 results hold the audited full-year statements. For Indian filers, quarterly covers the Q1, Q2, and Q3 results plus the fourth-quarter values of the Q4 results; annual covers the Q4 results; the source forms are "Financial Results" and "Integrated Filing (Financials)". fiscal_period="FY" returns the full-year values of the Q4 results. For Japanese and Korean filers, quarterly covers the Q1, half-year, and Q3 reports. Japan ended the quarterly securities report for quarters that start on or after 1 April 2024, so later Japanese periods have no Q1 or Q3 report. The Korean source forms are the DART report codes 11011 (annual), 11012 (half-year), 11013 (Q1), and 11014 (Q3). fiscal_year and fiscal_period accept company reporting labels such as 2026 and Q3. Earnings 8-Ks take their quarter from the 10-Q or 10-K whose period ended within the 80 days before the 8-K, and keep the 8-K filing date as the reported date. A freshly announced 8-K whose periodic filing has not arrived yet carries a quarter estimated from the company's fiscal calendar, replaced by the exact period when the filing lands. If neither is available, the tool omits the fiscal label instead of guessing.
Some companies file the same concept twice for one period and segment — for example a gross segment total next to a net-of-eliminations figure. Both are served: the extra line is its own series node whose name ends in "(reported line 2)", and its evidence_note says so. The two lines are alternative statements of the same item. Never add a "reported line 2" series to its ordinary counterpart — that double-counts.
A fact's value is served as stored, and the tool never changes its sign. Figures read from the report pages of companies in Germany, the UK, France, Switzerland, and India carry the sign the page prints, so a figure printed in brackets is negative. A few older rows from these markets were stored with another sign, and their evidence_note says so. SEC XBRL, Japanese, and Korean figures, and other figures taken from XBRL tags, carry the sign of the XBRL tag, which can differ from the page: Apple's 2024 cash flow statement prints its share buybacks as (94,949) million, and the stored value is a positive 94,949,000,000. Where FactIQ has stored what the sign stands for, the fact carries sign_meaning, a short text such as "Total expenses shown in brackets in the income statement.", and sign_meaning_kind, one of money_paid_out (cash that left the company in the period, for example "Tax paid"), money_received (cash that came into the company in the period, for example "Proceeds from sale of shares"), expense (a cost or loss that lowers profit), income (revenue, a gain, or a profit item that raises profit), liability (a balance the company owes at a date), asset (a balance the company owns or is owed at a date), deduction (an amount taken off another line to reach a subtotal, for example treasury shares in equity), increase (the balance of the item in the label went up in the period; it never means "adds to cash" or "adds to profit"), decrease (the balance of the item in the label went down in the period), net_amount (the result of pluses and minuses, for example profit or loss, an operating margin, or net cash flow), change_in_balance (a movement line in a table that rolls a balance from the start to the end of the period, for example additions or disposals), as_reported (the sign has no meaning beyond the printed number, for example total equity or a share count), or other (none of the 12 fits; the sign_meaning text says what the sign means). Read the value's sign together with them before adding or subtracting figures. A fact without them has no stored meaning; SEC XBRL and Japanese figures carry none, and most Korean figures carry them. The pretty rendering prints the meaning after the value.
When a company states one per-share figure with two values, both are served as is, and the series name ends with the reason: "on the share count before/after the 2-for-1 share split of 2025-04-01" for earnings per share counted before or after a share split, or "as stated in an earlier report" / "as restated in a later report" when a later report changed the value.
A figure whose value a later, amended or restated report changed carries revision_note, for example "revised: 1,942 in the report of 2026-02-10, now 1,950 (restated, report of 2026-05-04)", or "revised 2 times; last: ..." when the value changed more than once. The note also appears when a still later report repeated the revised value. The pretty rendering prints it after the value.
For non-admin callers, active_only is always enforced by the tool endpoint. With active_only enabled, every target is limited to facts currently marked active and serving; coverage and filings omit reports with no such facts.
If an exact-ticker metrics or facts request has no matching serving data, the tool falls back to Twelve Data standardized consolidated statements. A resolved issuer listed in Germany, the UK, France, Switzerland, India, Japan, or South Korea is sent to the vendor with its exchange suffix (.DE, .L, .PA, .SW, .NS, .T, .KS, .KQ) appended to a bare stored ticker; a stored ticker that already carries the suffix (MC.PA, RELIANCE.NS, 7203.T, 005930.KS) is sent as is, and the bare symbol (RELIANCE, 7203) is sent with the stored suffix. Company names and bare tickers without a resolved issuer remain filings-database-only so vendor data cannot be attributed to a different issuer with the same ticker. A request that names no report_type or fiscal_period tries quarterly statements and then annual, so annual-only vendor coverage still answers. A concept the filings database already holds is never answered from the vendor, even when the other filters leave no rows. Fallback values carry no filing-document, source-page, or segment evidence. coverage, filings, and segment-filtered requests remain filings-database-only.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum matched rows before tree grouping. For facts, each numeric observation is one row, so one series with many periods uses many rows — filter by period, metric class, or segment instead of raising the limit. The range is 1 to 50 and the default is 20. For coverage, it limits the latest filing records. | |
| query | No | Broad lexical search across concept names, labels, codes, aliases, definitions, and segment names. For commentary and risk_changes it searches statement topics, summaries, and verbatim quotes. It applies to every target except coverage. Normally leave it empty when concept is set. | |
| format | No | Response form for a successful tree result. json returns only the JSON tree. pretty returns only readable rendered_tree text. The forms are never combined. | json |
| company | Yes | Required company identifier. Use an exact ticker, full company name, LEI, or another stored identifier. A share-class sibling ticker such as GOOGL resolves to the same SEC filer as the stored GOOG. A company listed in Germany, the UK, France, or Switzerland resolves by its local ticker (BAS for BASF SE, ULVR for Unilever plc, MC.PA for LVMH, NESN for Nestlé), full name, or LEI. When a UK, French or Swiss symbol is also a US ticker, the company is stored with its exchange suffix (.L London, .PA Paris, .SW Zurich: MC.PA, BA.L, ROP.SW) and the bare symbol (MC, BA, ROP) goes to the SEC filer; the response then lists the suffixed company under possible_matches. A Nifty 50 company listed in India resolves by its NSE symbol (RELIANCE, M&M), the same symbol with .NS, its BSE scrip code, or its full name. A company listed in Japan or South Korea resolves by its stock code with the exchange suffix (7203.T for Toyota Motor, 005930.KS for Samsung Electronics, .KQ for KOSDAQ), the bare stock code (7203, 005930), its EDINET or DART code, or its full name. A tied ticker match returns every possible company instead of selecting one. | |
| concept | No | One requested metric, such as Revenue. The tool selects the best stored concept for this company, reports what it selected, and returns that concept across periods. Valid only for metrics or facts. | |
| date_to | No | Optional inclusive latest period-end date for filings, metrics, or facts. | |
| segment | No | Optional case-insensitive filter for a business segment, product, region, dimension member, dimension axis, or source label. It applies to metrics and facts. | |
| date_from | No | Optional inclusive earliest period-end date for filings, metrics, or facts. | |
| active_only | No | Return only current serving facts. This is always enforced for non-admin users; admins may set false to inspect inactive rows. When true, coverage and filings also omit reports with no serving facts. | |
| fiscal_year | No | Optional company fiscal-year label, such as 2026. It applies to filings, metrics, and facts. For metrics and facts it selects the fiscal year of the period a value covers, even when a later report stated the value. | |
| report_type | No | Optional report filter for every target except coverage. Accepts a common type such as annual, quarterly, or half_year, or a source form such as 10-K or 10-Q (or a source document code such as ACS, FR, IR, AMF-RFA, AMF-RES). For German, UK, and French filers, quarterly covers Q1, half-year, and Q3 reports. For Indian filers, quarterly covers the Q1, Q2, and Q3 results, and annual covers the Q4 results, which hold the audited full-year statements. For Japanese and Korean filers, quarterly covers Q1, half-year, and Q3 reports, and the Korean source forms are the DART codes 11011 to 11014. For metrics and facts, quarterly also returns every quarter-length value from other reports, including the fourth quarter, which is stored on the annual report. For commentary and risk_changes, annual covers 10-K and 20-F, quarterly covers 10-Q, current covers 8-K, and 424B4 or 424B1 selects the final IPO prospectus. | |
| metric_class | No | Optional metric class for metrics or facts, such as financial, ifrs, segment, kpi, apm, or offering_terms (the price, shares and proceeds of an offering in a registration statement). Matching ignores letter case, so Product and product select the same facts. | |
| fiscal_period | No | Optional company fiscal-period label, such as Q1, Q2, Q3, Q4, or FY. It applies to filings, metrics, and facts. For metrics and facts it selects the fiscal period a value covers; Q4 returns the fourth-quarter values stored on the annual report. | |
| search_target | No | Result type. coverage shows available report dates, types, and metric classes. filings shows report records and source URLs. metrics shows available concepts and series. facts shows numeric reported values. commentary shows management's qualitative statements from MD&A sections and earnings press releases. risk_changes shows year-over-year risk-factor changes from annual reports; no rows for a year means unchanged risk factors only when annual_report_years lists that year as compared (unchanged from the IPO prospectus when the year is in compared_with_prospectus), and never means no risks. | facts |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly and openWorld annotations, the description discloses important behavior: the search is deterministic and does not call a language model, results are trees without database row IDs, JSON and pretty formats are never combined, source links are included, and sign/revision caveats are explained. It also covers active_only enforcement and the Twelve Data fallback, which are material operational details.
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, but the description is extremely long and dense, with extensive restatement of schema details and long digressions into sign_meaning categories, revision notes, duplicate reported lines, and vendor fallback. For a search tool, it is substantially over-sized and would benefit from trimming.
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 the 14 parameters, multi-market scope, and complex output behavior, the description is complete. It covers coverage, formats, source citations, company resolution, report-type nuances, commentary and risk_changes limitations, and fallback behavior. An output schema exists, but the extra contextual detail is still sufficient and relevant.
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 useful meaning about parameter combinations and market-specific behavior. It explains concept selection versus query, search_target semantics, report_type mappings for each market, and fiscal-period handling. Much of this repeats the schema and becomes verbose, but it still adds practical invocation guidance.
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 verb and resource: it 'searches structured facts and report metadata from one company's filed reports.' It also scopes the covered issuers (US SEC, Germany, UK, France, Switzerland, India, Japan, South Korea), so an agent can immediately distinguish it from general search, news, transcript, or market-data 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?
It gives strong internal guidance: use an exact ticker when possible, choose concept for a single metric versus query for broad search, and use search_target to select coverage, filings, metrics, facts, commentary, or risk_changes. It does not explicitly compare this tool against sibling tools such as search_series or get_market_data, so sibling routing is implied 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.
Find datasets by keyword across every schema — the first discovery step.
Keyword ranking (not semantic) over dataset titles and topics. Returns ranked
{schema, dataset_code, title, topic}. Follow up with describe_dataset for
detail, or run_sql on the series/dimensions tables for exact series.
latest_data_date, when present, is the period start date of the newest
stored value in the whole dataset (left out when unknown); one part of a
dataset can stop earlier, so check the end dates of the series you use.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| schemas | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, destructiveHint=false), so the bar is lower, and the description still adds real behavior: keyword rather than semantic ranking, the returned fields, and the important caveat that `latest_data_date` is the dataset-wide newest period and that individual parts can end earlier. That caveat is non-obvious and prevents misuse.
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 and the discovery-step framing, then follows with ranking behavior, return shape, next steps, and a caveat. Every sentence carries information; the `latest_data_date` aside is the only slightly tangential element but it is genuinely non-obvious and useful.
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 values need not be fully explained, and the description still sketches the ranked result shape. Combined with ranking behavior, follow-up routing, and the date caveat, an agent has enough to call this correctly; only the parameter semantics remain under-specified.
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 0% and the description does not document any of the three parameters. 'Across every schema' loosely gestures at the `schemas` filter, but `limit` and the actual semantics of `schemas` (default null = all schemas) are left entirely to the schema, which lacks descriptions — a significant gap for a search tool where result-set control matters.
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 gives a specific verb and resource ('Find datasets by keyword across every schema') plus a clear scope statement, and it frames itself as 'the first discovery step', which separates it from sibling search tools like search_series or describe_dataset. The ranking mechanism (keyword, not semantic) further pins down what kind of search this is.
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 explicitly states the workflow position ('first discovery step') and names concrete follow-ups (`describe_dataset` for detail, `run_sql` on series/dimension tables for exact values). What's missing is an explicit contrast with the closest alternative, `search_series` — the agent must infer datasets-vs-series itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search earnings-call intelligence from live calls, decomposed into atomic, quote-anchored claims and Q&A pressure points — never a raw transcript dump.
Retrieval for "claims" and "pressure_points" is lexical, not semantic. A nonempty query uses an OR-of-tokens full-text candidate set; strict websearch_to_tsquery matches receive a fixed ranking boost, so strict matches rank ahead of loose partial-term matches. Lower-ranked rows may match only some query terms. If that filtered full-text search returns no rows, a trigram fallback handles typos and sub-word variants. Quoted phrases use websearch syntax, but synonyms are not inferred: try the company's own vocabulary ("capex" and "capital expenditure", segment names, abbreviations). Word forms are matched by their English stem, so "lock" also finds "locked" and "locking", and a hyphen counts as a space, so "lock-in" also finds "locked in" and "locked into". For a broad screen, prefer this tool over run_sql regular expressions, which match only the exact spelling. An empty or partial result is not proof that management did not discuss a topic; coverage and vocabulary both matter.
Target and filter semantics:
"claims" (default) searches or browses normalized management/analyst claim rows. ticker, quarter_filter, claim_family, section, detail, and limit apply. claim_family matches primary or secondary families; section is "prepared_remarks" or "qa". Base rows include direction/value/unit where checkable, assertion_status, canonical_statement, verbatim_quote, speaker, speaker_role, section, transcript_id, source_block_index, qa_turn_id, and a source_link object. detail=true rows also carry entity_refs: the companies, products and bodies the claim names, each with raw_name, ref_type (competitor, customer, supplier, partner, product, regulatory_body, other, none), is_implied, entity_name, and entity_ticker.
"pressure_points" searches or browses what analysts pressed for and whether management confirmed, declined, deflected, or partially answered. ticker, quarter_filter, claim_family (the linked family), detail, and limit apply. section is ignored because every pressure point is from Q&A. Base rows include specific_ask, response_quality, refused_number, linked_family, linked_claim_id, verbatim_quote, speakers, transcript_id, source_block_index, qa_turn_id, and a source_link object. speakers lists every transcript turn the quote draws on, in spoken order, each with block_index, speaker, role (analyst, ceo, cfo, ...) and firm as stored for that turn; one quote usually spans an analyst's question and a manager's answer, so attribute each part of the quote to its own speaker.
"disclosure_profile" is a direct company lookup, not text search. The ticker is the first ticker value, or query when ticker is empty. Profiles are curated separately from transcript coverage, so a covered company may not have one; availability is "available" or "unavailable" accordingly. quarter_filter, claim_family, section, detail, and limit do not narrow it.
"coverage" is corpus inventory, not text search. ticker and limit apply; query, quarter_filter, claim_family, section, and detail do not narrow it. Rows report calls_covered, earliest_period, latest_period, latest_call_date (the call date of latest_period), claims, pressure_points, and recent_calls (the newest stored calls, each as its fiscal_period and call date).
Fiscal period labels follow each company's own fiscal year, and they are not always the calendar year of the call: a retailer's March 2026 call can be FY2025Q4. Before you pin quarter_filter, read the fiscal_period of the call you want from recent_calls. When a quarter_filter matches no call of the requested tickers, the result note lists the periods and call dates that are stored for them.
An empty query is a capped browse, not a completeness guarantee. Rows are
ordered by newest fiscal period/call and then source-block (spoken) order
within one call. Every response is limited to at most 50 rows, and a browse
that reaches its limit may omit additional rows even if no truncation flag is
present. For a latest-call note: (1) call "coverage" with one ticker, (2) read
latest_period, (3) call "claims" with that ticker, quarter_filter=latest_period,
query="", detail=true, and a deliberate limit, then (4) call
"pressure_points" with the same ticker and quarter. Treat both browses as
capped evidence, not a complete transcript. Narrow large result sets with
ticker, quarter, target, claim_family, and (for claims) section. For media
quotes, run_sql can read transcripts.appearance_claims.verbatim_quote;
other transcript tables remain restricted.
Evidence rules: canonical_statement is normalized and must not be quoted as
verbatim. Quote only verbatim_quote, with its speaker, role, ticker, and fiscal
period. A […] inside verbatim_quote marks omitted transcript sentences between
non-adjacent evidence spans: preserve it exactly when quoting, and never
present text on either side of it as one continuous statement. When a quote is used, render source_link.source_label as the Markdown
link text for source_link.source_url beside the claim. The label names the
company, fiscal period, and earnings call transcript; never replace it with an
ingestion vendor. Do not make a second call just to find a citation, do not
invent a replacement when source_url is null, and do not call a document-level
link exact context. source_locator still identifies the stored transcript block
or Q&A turn. assertion_status is load-bearing: analyst_hypothesized is the
analyst's framing, while mgmt_declined_to_confirm is a refusal, not a management
assertion. Spoken call claims are a different source class from filed XBRL
actuals (run_sql on the sec schema) and formally issued targets (the
sec_guidance dataset); label them separately.
Examples:
Latest call: search_earnings_transcripts(query="", search_target="coverage", ticker="MU"), then repeat with search_target="claims", quarter_filter=<latest_period>, detail=true, limit=50, and finally with search_target="pressure_points" for the same ticker and quarter.
Cross-company theme: search_earnings_transcripts(query="capital expenditure capacity", search_target="claims", ticker="MU,NVDA", detail=true); inspect each returned row for topical support, do not assume every term matched, and retry vocabulary as needed.
Disclosure habits: search_earnings_transcripts(query="", search_target="disclosure_profile", ticker="MU").
claim_family codes: driver_attribution, forward_conviction, prior_view_revision, strategic_agreement, pricing_mechanics, demand_magnitude, capacity_milestone, competitive_positioning, cohort_behavior, cost_margin_bridge, capital_allocation, stated_risk_constraint, qa_dynamics, regulatory_policy, pipeline_backlog, commodity_hedging, ma_deal, labor_org. Topic paths (topic_path column) are rooted at: demand, supply_capacity, pricing, cost_margin, capital, competition, customer, product_roadmap, risk, governance.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum 1-50 rows (default 15). This is a hard cap, not proof the result is complete; narrow by ticker, quarter, target, family, and claims section. | |
| query | No | For claims/pressure_points: lexical websearch text; strict matches rank above loose partial-term matches, with trigram fallback only when FTS returns no rows. Empty text browses capped rows. For disclosure_profile, it can supply the ticker when ticker is empty. Ignored by coverage. | |
| detail | No | For claims, add structured_fields, secondary_families, period, time_horizon, conviction_qualifier, denominator, falsifiable, and entity_refs (the companies, products and bodies the claim names: raw_name as spoken, ref_type such as competitor/customer/supplier, is_implied for an unnamed reference, and the matched entity_name/entity_ticker when known); for pressure_points, add tone_note. Ignored by disclosure_profile and coverage. The extractor's quantified flag is not published: it only records that the extractor wrote something into value, which the caller can already see in value itself. | |
| ticker | No | Ticker, or a comma-separated list of tickers, for claims, pressure_points, and coverage; case-insensitive. Company names belong in company_name; pass only one of the two. A name passed here is still read as a name when it fits a stored company, and the response says so. Companies listed in India carry the NSE suffix ('RELIANCE.NS', 'INFY.NS') and companies listed in Switzerland carry '.SW' ('NESN.SW', 'ROP.SW'); a plain NSE or Swiss symbol is also accepted, but a symbol that is a US ticker ('INFY', 'ROP') selects the US listing. The response lists possible matches for a value that is not in the transcript corpus. disclosure_profile uses only the first ticker. | |
| section | No | prepared_remarks or qa; applies only to claims. Ignored for pressure_points because those rows are all Q&A, and ignored by lookup/inventory targets. | |
| claim_family | No | Claim-family code. Matches primary/secondary families on claims and the linked family on pressure_points; ignored by disclosure_profile and coverage. | |
| company_name | No | Company name, or a comma-separated list of names, for claims, pressure_points, and coverage; case-insensitive ('nvidia', 'HP Inc', 'Ford Motor'). Each name resolves to the stored ticker(s) that match it best; the response reports the resolution and lists possible matches for a name that resolved to nothing. Pass either company_name or ticker, not both. disclosure_profile uses only the first resolved ticker. | |
| search_target | No | claims or pressure_points perform lexical retrieval/browse; disclosure_profile is a direct company lookup; coverage is corpus inventory. | claims |
| company_filter | No | Deprecated alias of ticker, kept for clients installed before the parameter was renamed. Pass ticker instead. | |
| quarter_filter | No | Exact fiscal period such as FY2026Q3; applies to claims and pressure_points. Ignored by disclosure_profile and coverage. Pin this after coverage for a single-call browse. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/openWorld=false/destructive=false, and the description still adds substantial behavioral context: lexical OR-of-tokens retrieval with strict-match ranking boosts, trigram fallback on zero hits, stem and hyphen handling, a hard 50-row cap that may silently omit rows, and fiscal-period labeling pitfalls. It also discloses evidence rules (canonical_statement must not be quoted, […] span markers, citation rendering, assertion_status semantics) that annotations cannot convey.
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 and retrieval semantics are front-loaded, and the target-by-target bullet structure plus worked examples make a long description navigable. It is nonetheless very long for a tool definition, with some duplication of the schema's own parameter notes and a claim_family code list buried at the end.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description needn't explain return shapes, and it instead covers the things that matter: per-target row contents, cap/truncation caveats, fiscal-period resolution steps, entity_refs detail expansion, and citation/quoting obligations. An agent has everything needed to call it correctly and interpret capped results.
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 real meaning beyond it: the full claim_family code list, topic_path roots, the warning to pin quarter_filter from coverage's recent_calls because fiscal labels diverge from calendar years, and per-target applicability of ticker/section/detail. Some of this (target-specific ignoring of parameters) restates the schema, keeping it from a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb and resource ('Search earnings-call intelligence') and immediately scopes it as atomic, quote-anchored claims and Q&A pressure points rather than raw transcripts. It explicitly differentiates itself from run_sql regex and, via the evidence rules, from filed XBRL actuals and sec_guidance targets, so an agent can place it among siblings without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use rules (broad screens prefer this over run_sql regex; empty query is a capped browse), when-not signals ('an empty or partial result is not proof that management did not discuss a topic'), and worked multi-step recipes for latest-call, cross-company theme, and disclosure-habit workflows. Alternatives and preconditions are named rather than inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search what people said outside earnings calls, in two kinds of source:
Interviews: podcasts, TV interviews and conference talks by company executives, investors, fund managers, analysts, economists, journalists and other guests.
Central-bank documents: speeches, testimony, policy statements, minutes, press-conference transcripts, projections and reports from the Federal Reserve Board and regional Reserve Banks, the European Central Bank and euro-area national central banks, the Bank of England, the Bank of Japan, the Reserve Bank of India, the People's Bank of China, the Bank of Korea, the Hong Kong Monetary Authority, Taiwan's central bank and others. Documents in other languages yield English paraphrases, and each claim's verbatim_quote keeps the original language. A query in Chinese, Japanese, Korean or Thai also finds claims whose original-language quote holds every query word, such as 关税 for a Chinese episode about tariffs.
Use it for questions about what a named person or institution said: "what has Waller said about rate cuts", "what did the ECB say about inflation at its last meeting", "what did Jensen Huang say about export controls". Claims cover listed and unlisted companies (OpenAI, DeepSeek, MiniMax), institutions (the Federal Reserve, the European Central Bank, regulators), and whole markets and industries, not only the speaker's own employer.
How to search: put one to three key words in query, and put the speaker in person, the publisher in institution and the kind of document in appearance_type. A returned row must contain most of the query words, so a long question returns fewer rows than its key words alone. Retry with the speaker's own vocabulary or a synonym before concluding there is no coverage. No serving-time model interprets or expands the query: retrieval is lexical, not semantic. It tries strict full-text matching first, loose any-term full-text matching only when strict matching returns no candidates, then trigram matching only when both full-text stages are empty.
Canonical search_target values:
"search" (default): blended structured claims and broad passage cards.
"claims": normalized decision-relevant claims only.
"passages": broad substantive paraphrase cards only.
"pressure_points": stored refusal and declined-to-confirm claim rows.
"appearances": video-level catalog rows.
"coverage": company-level structured-corpus inventory.
"episodes": every episode the podcast feeds listed, newest first, transcribed or not (result_kind "feed_episode"): show, title, published date, link, transcribed, and status, which says why an episode was not transcribed. Use it for the newest episode of a show. A feed_episode row has no paraphrase and no quote. show narrows it to one show, and every query word must be in the title; date_from, date_to, limit and offset apply, and the other filters do not. A search with show that finds no transcribed row also returns the matching feed episodes under feed_episodes, next to the empty results.
"all" maps to "search", "videos" to "appearances", and "companies" to "coverage" for older clients; "search" is the primary blended target, not a legacy alias.
Result contracts:
search/claims/passages/pressure_points return result_kind, canonical_paraphrase, speaker, primary ticker, topic labels, video/channel/publication metadata, lexical relevance, and source_url (a timestamped YouTube deep link, the audio file with a #t= start time for a podcast whose stored link is an audio file, otherwise the episode page for a podcast, the document page for an official document, or the PDF page of a press-conference transcript). start_s is the second of the recording at which the row starts (null for official documents, which have no recording time); give it as the time when the podcast link opens an episode page. Claim and pressure_point rows also return verbatim_quote, the speaker's exact words in the original language, at most 1,000 characters (a longer quote is cut at a sentence end or a space, never inside a number), and quote_truncated, true when the quote was cut (both null on passage rows). detail=true adds normalized claim and attribution fields plus institution, document_kind and event_date (null for interviews), but never raw transcript text or evidence spans.
appearances returns video metadata, primary ticker, attribution metadata, matching claim count, URL, and relevance score. detail has no effect.
coverage returns company-level appearance, publication-date-span, channel, claim, and low-confidence-attribution counts. It is structured coverage, not a per-person acquired-video/hour inventory; query, sort, and detail have no effect.
Filter and ordering semantics:
company is comma-separated tickers and company names, mixed freely. A stored ticker matches the appearance's company or a section subject with that ticker; any other value is read as the name of a company, institution, or organisation a podcast section is about, matched after dropping punctuation, a leading "The", and corporate suffixes. Every ticker attached to a matched name joins the ticker filter, so "Alphabet" also reaches GOOGL rows. The result records company_tickers, company_names, company_matched, and company_unmatched (a value that matched nothing, with up to five possible matches); an unmatched value returns no rows, not an error. company_filter is the old name of company and behaves the same; passing both is an error. The appearances and coverage targets also match every value, upper-cased, against the entity references of claims (products, rivals, partners such as "CUDA"); a value found only there is listed under company_references.
person is a case-insensitive substring over the finding speaker and/or appearance speaker metadata. appearance_type applies to every target: podcast, tv_interview, conference and other for interviews; speech, testimony, minutes, statement, press_conference and hearing for official documents. country ("US") restricts every target to official documents of that country; institution ("Federal Reserve") is described with show and channel below.
claim_family restricts structured claims. With blended search it suppresses passage cards; pairing it with search_target="passages" is an error. For appearances/coverage it requires videos with matching structured claims.
date_from/date_to are inclusive YYYY-MM-DD bounds on the video's stored publication/upload date, which can differ from the recording or event date.
show, channel, and institution are case-insensitive substrings of a podcast show name, a YouTube channel name, and a publishing institution; each returns only rows of its own kind, and when more than one is given rows matching any of them are returned. show also matches the YouTube uploads of a show whose YouTube channel is registered for it.
relevance orders lexical score first, then publication date (a relevance search of claims with a query gives its rows in turns by episode, see below); newest orders publication date first, then lexical score. Coverage has fixed inventory ordering by latest covered publication date.
limit is one page of 1-50 rows and offset skips that many ranked rows before the page, so limit=15 with offset=15 returns rows 16-30 of the same ranking. Every result carries has_more, plus next_offset when more rows follow; call again with that offset to read the next page.
A relevance search of claims (search or claims target, with a query) also returns episode_ranking: the episodes of the page's rows, best first. Each lists video_title, channel, published_at, episode_score, matching_claims, title_match and result_ids (the result_id of each of its rows in results). Its rows go in turns: the best row of each episode, then the second-best row of each, so one episode does not fill the page. Such a search ranks its best 400 rows; a note says when the pages stop there.
With an empty query, each target browses its most recent rows (search and claims show claims only).
Evidence safety: canonical_paraphrase is FactIQ's summary, not a transcript quotation. Quote only verbatim_quote, exactly as returned, and say so when quote_truncated is true. Cite source_url (timestamped for YouTube and podcast audio files, page-anchored for PDF transcripts) and start_s with the returned speaker, publication date, and video or document metadata. FOMC minutes describe the meeting of event_date and are published three weeks later; the Committee, not one person, is their speaker. Do not put canonical_paraphrase in quotation marks: passage rows have no verbatim_quote, so quote a passage only after you verify the wording at the source link. The tool never returns raw transcript turns.
Detail-field safety: internal audit flags are not published; judge a claim from value, assertion_status, and the timestamped source link. company_attribution_confidence and company_attribution_source concern only the video-to-company/ticker assignment; inferred attribution is not independent confirmation.
| Name | Required | Description | Default |
|---|---|---|---|
| show | No | Case-insensitive substring of a podcast show name, for example 'Odd Lots'. Returns podcast rows only: the show's feed episodes and its YouTube uploads when its YouTube channel is registered for it. With search_target='episodes' it names the show whose feed episodes are listed. Combine with channel or institution to also include YouTube or official-document rows that match those; rows matching any given name filter are returned. | |
| sort | No | "relevance" orders lexical score first and publication date second; a relevance search of claims with a query groups its rows by episode and gives them in turns (see episode_ranking). "newest" orders publication date first and lexical score second. Coverage uses its fixed company-inventory ordering. | relevance |
| limit | No | Maximum rows returned in one page, from 1 through 50. Use offset to read the pages after the first. | |
| query | No | Lexical search text: one to three key words, for example 'rate cuts' or 'export controls'. A returned row must contain most of the query words, so a long question returns fewer rows; after common words are dropped, the first eight words find rows and every word counts in the ranking. Put a phrase in double quotes to find it word for word: claims whose quote holds the phrase come first. Put the speaker in person and the publisher in institution instead of in the query. No serving-time model interprets the query. Retry synonyms or the speaker's own terminology if needed. Ignored by coverage; appearances matches only video title/channel metadata. | |
| detail | No | For search/claims/passages/pressure_points, add normalized claim and company-attribution fields. Internal audit flags use bounded public names and include field_semantics; raw transcript text and evidence spans remain excluded. Has no effect on appearances or coverage rows. | |
| offset | No | Number of ranked rows to skip before the returned page, so offset=15 with limit=15 gives rows 16 through 30 of the same ranking. Every result reports has_more, and adds next_offset when more rows follow; repeat the call with that value to read the next page. | |
| person | No | Case-insensitive name substring. Returns statements whose speaker matches, by the stored label or by the name the result shows for it (a label NADELLA shown as Satya Nadella). Only when no such statement matches does it return rows of episodes whose host or guest list holds the name; a note then says that the speaker of those rows can be someone else. | |
| channel | No | Case-insensitive substring of a YouTube channel name, for example 'Bloomberg Television'. Returns YouTube rows only. Combine with show or institution to also include podcast or official-document rows that match those; rows matching any given name filter are returned. | |
| company | No | Comma-separated tickers and company names, mixed freely (for example, 'NVDA,OpenAI' or 'Federal Reserve,Alphabet'). A value that is a stored ticker matches the appearance's company or a section subject with that ticker. Any other value is read as the name of a company, institution, or organisation the podcast section is about, so unlisted companies (OpenAI, MiniMax, Manycore Tech), central banks, and regulators are found by name. Names are matched after dropping punctuation, a leading 'The', and corporate suffixes ('NVIDIA Corp.' finds NVIDIA; 'Alphabet' also reaches GOOGL rows), and each result records how every value was read: company_tickers, company_names, company_matched, and company_unmatched (with up to five possible matches per value that matched nothing). The appearances and coverage targets also match every value, upper-cased, against the entity references of claims (products, rivals, partners such as 'CUDA' or 'ChatGPT'); a value found only there is listed under company_references. Alternate spellings can return different appearances or coverage rows because reference names are matched exactly ('open ai' and 'OpenAI' select the same subject but not the same references); the claims rows are the same. | |
| country | No | ISO country code of the institution that published an official document, for example 'US'. Restricts every target to official documents of that country. | |
| date_to | No | Inclusive YYYY-MM-DD upper bound on the video's stored publication/upload date, which may differ from its recording or event date. | |
| date_from | No | Inclusive YYYY-MM-DD lower bound on the video's stored publication/upload date, which may differ from its recording or event date. | |
| institution | No | Case-insensitive substring of the institution that published an official document, for example 'Federal Reserve'. Returns official-document rows only; podcast and YouTube rows have no institution. Combine with show or channel to also include podcast or YouTube rows that match those; rows matching any given name filter are returned. | |
| claim_family | No | Optional claim-ontology code. Blended search then returns structured claims only; appearances/coverage require matching claims. It is incompatible with search_target='passages'. Invalid codes return the valid vocabulary. | |
| search_target | No | Canonical targets: "search" (default blended claims + passages), "claims" (normalized decision-relevant claims), "passages" (broad substantive paraphrase cards), "pressure_points" (refusals and declined-to-confirm claims), "appearances" (video catalog), and "coverage" (company-level structured-corpus inventory), and "episodes" (every episode the podcast feeds listed, transcribed or not, with title, date, link and the reason it was not transcribed; no paraphrase, no quote). Compatibility aliases are "all" -> "search", "videos" -> "appearances", and "companies" -> "coverage"; new callers should use the canonical values. | search |
| company_filter | No | Old name of company. Accepted with the same behaviour; the response note asks the client to update its plugin. Do not pass both. | |
| appearance_type | No | Optional appearance-type filter. Interviews: podcast, tv_interview, conference, other. Official documents: speech, testimony, minutes, statement, press_conference, hearing. Applies to every canonical target. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds real behavioral context beyond them: retrieval is lexical with a strict full-text → loose any-term → trigram fallback, pagination via has_more/next_offset, the 400-row ranking cap, episode_ranking turn-taking, and explicit quote-safety rules. The only gap is that the long result-contract section largely duplicates what the existing output schema already exposes, which blunts its added value somewhat.
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?
It is front-loaded and sectioned, which helps, but at roughly 1,300 words it is far beyond what a search tool needs, and large blocks (result contracts, source_url/start_s formatting, per-target filter applicability) restate the very detailed schema and output schema almost verbatim. The duplication inflates prompt cost without adding decision-relevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 17-parameter, multi-target tool with an output schema, the description covers routing, filter interaction, error conditions, and citation safety — nothing an agent needs is missing. It is arguably over-complete, restating return-value detail the output schema already carries.
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 still earns credit for cross-parameter semantics the schema states only locally — e.g. that a matched company name pulls in every ticker attached to it, that show/channel/institution combine as an OR, that claim_family plus search_target='passages' is an error, and that unsupported filters silently no-op on the episodes target.
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?
Opens with a precise verb+scope ("Search what people said outside earnings calls") and enumerates the two source families, explicitly excluding earnings calls — which is exactly the sibling tool search_earnings_transcripts. An agent can route between this and the earnings tool 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 concrete example questions ("what has Waller said about rate cuts"), tells the caller how to decompose a question into query/person/institution/appearance_type, advises retrying with synonyms before concluding no coverage, and names which search_target to pick for newest-episode, coverage, or refusal queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search recent business, economics and health news from major financial
publishers and public-health agencies. Each row has the headline, the
publisher's short summary and a link (article bodies are never returned), plus
FactIQ metadata: tickers of listed companies named in the text and an
analysis block (keywords, geography, and a one-sentence investor angle).
Coverage starts between late 2024 and mid 2026, depending on the feed. All
arguments combine (AND).
query: lexical full-text search over headline, summary and analysis; every word must match. Start with ONE distinctive term ("Novartis", "copper"). If nothing matches, it retries matching ANY word (meta.query_mode = "any_term"). Supports "exact phrases" and -exclusion.
tickers: bare symbols (["NVDA", "RELIANCE"]). Share classes and cross-listings match automatically (GOOG = GOOGL, TSM = 2330).
topic: one of markets, economics, companies, technology, politics, world, energy, health, india, opinion. With a query it only boosts that topic's articles; without one it filters to them.
start_date / end_date: inclusive ISO dates on publication time.
sources: publisher slugs, as shown in the source field of results.
sort: "latest" (default) or "relevance" (needs a query).
limit: 1-50, default 20.
Returns {rows: [{id, published_at, source, feed, topics, title, summary, url,
tickers, analysis}], meta: {matched, returned, sort, query_mode?,
topic_mode?}}. analysis is null when an article has no business content
or is not yet analysed. Follow up macro stories with search_series / run_sql
and company stories with get_market_data / search_earnings_transcripts.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | latest | |
| limit | No | ||
| query | No | ||
| topic | No | ||
| sources | No | ||
| tickers | No | ||
| end_date | No | ||
| start_date | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover the safety profile (readOnly/openWorld/non-destructive/non-idempotent); the description adds genuinely non-obvious behavior: article bodies are never returned, coverage windows vary by feed (late 2024 to mid 2026), the query engine falls back to ANY-word matching reported via meta.query_mode, and analysis is null for non-business or unanalysed articles. That is well beyond what structured fields convey.
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 purpose, return shape and coverage caveat, then uses a bulleted list keyed one-to-one to parameters, ending with follow-up routing. Length is justified by 8 undocumented parameters, and no sentence is 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?
Covers the return envelope (rows/meta fields), the AND-combination rule, coverage limits, null-analysis cases, and next-step tools. Even though an output schema exists, the extra notes about query_mode/topic_mode and analysis nullability add value rather than duplicating it.
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 0% across 8 params, so the description carries the whole load and does so: query matching semantics (all words, exact phrases, -exclusion), bare-symbol tickers with automatic share-class/cross-listing equivalence, the boost-vs-filter distinction for topic, inclusive ISO dates, source slugs, sort='relevance' requiring a query, and limit bounds. Almost every parameter gains meaning not present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Search recent business, economics and health news from major financial publishers and public-health agencies') and scopes the corpus precisely. It also implicitly positions itself as the entry point versus siblings by naming which tools to follow up with for macro (search_series / run_sql) versus company (get_market_data / search_earnings_transcripts) stories.
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?
Strong operational guidance: 'Start with ONE distinctive term', note that arguments combine with AND, that topic boosts with a query but filters without one, and explicit routing of follow-up work to sibling tools. It stops short of stating when NOT to use search_news versus adjacent retrievers like search_company_filings or search_media_appearances.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find series in one schema by title terms (substring match, not semantic).
Supply already-decomposed terms; prefer short stems (e.g. "rare" over "rare
earth"). Includes active COMPOUND:: series. For anything this misses, fall
back to run_sql exploration on the series and dimensions tables.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| terms | Yes | ||
| schema | Yes | ||
| include_compound | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, non-destructive, closed-world behavior, and the description adds real value beyond them: substring (not semantic) matching, the need for pre-decomposed stems, and inclusion of COMPOUND:: series. It leaves the idempotentHint=false oddity for a read tool unexplained.
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 verb+scope, then the term-matching advice, then the fallback path. Dense but every sentence earns its place; 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?
An output schema exists so return values needn't be described, and the match behavior and fallback are well covered. The gaps are the undocumented `schema` and `limit` params, which matter given 0% schema coverage.
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 0%, so the description must carry the load. It explains `terms` well (decomposed, substring, short stems) and hints at include_compound via COMPOUND:: series, but says nothing about `schema` or `limit`, leaving half the parameters undocumented anywhere.
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 ('Find') and resource ('series') scoped to one schema, and clarifies the matching mode as substring, not semantic. It does not explicitly contrast with the sibling get_series, so sibling differentiation is only implied rather than stated.
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 concrete usage guidance: supply already-decomposed terms with short stems, and fall back to run_sql on the series/dimensions tables when this misses. It does not say when to prefer this over get_series, so the exclusion set is incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report a problem with FactIQ's data or tools to the FactIQ team.
Call this when a tool result looks broken:
"data_issue" — a value that contradicts the official source, wrong units or scale, duplicated or missing periods, an obviously wrong label.
"tool_error" — a tool that errors, times out repeatedly, or returns malformed or self-contradictory results.
"missing_data" — a dataset or series the catalog advertises but that returns nothing, or coverage that ends far earlier than the source's.
"other" — a concrete defect in the published tool contract, such as the documented arguments or result shape contradicting actual behavior.
Write one short, specific message with the concrete identifiers: the schema, dataset_code or series_id, the SQL you ran, and what you expected vs. what you got (with the official source's value or URL if you have one). Do not include the user's personal details or your conversation.
Do not call this for intentional capability boundaries or simply because a user requested an unsupported action. FactIQ cannot mutate warehouse data, return complete raw transcripts, or publicly publish charts/reports; those limits are expected behavior, not defects. A concrete tool result must show the reported malfunction or data problem.
This is one-way: the FactIQ team reviews every report, but nothing comes back to you. File it and continue with the user's task — never block on it.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | ||
| category | No | other |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare non-readOnly, non-idempotent, openWorld, destructive; the description adds meaningful context beyond them: the report is one-way, the team reviews it, and the agent must not block on it. It also warns against including personal details. Minor remaining gaps (rate limits, dedup of repeat reports) are not covered.
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 organized into scannable bullets for categories, message guidance, exclusions, and one-way behavior. Length is justified by the number of distinct rules and no sentence 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?
An output schema exists so return values need no explanation, and the description nonetheless clarifies the one-way (no-response) nature. Combined with category semantics and content required for the message, an agent has everything needed to file a well-formed report.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the schema carries no descriptions, so the description must compensate — and it does, defining each enum value of 'category' with examples and specifying what the 'message' should contain (identifiers, SQL run, expected vs. actual). Only the 4000-char bound goes unmentioned.
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 specific verb+resource ('Report a problem with FactIQ's data or tools to the FactIQ team') and pins the scope precisely to broken tool results. An agent can immediately distinguish it from all data-retrieval siblings.
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 enumerates when to call it (four defect categories with concrete examples) and, more valuably, when NOT to call it (intentional capability boundaries, user-requested unsupported actions). It also states the non-blocking behavior, so the agent knows how to sequence this relative to the user's task.
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.
search_media_appearances6 fields changedInput schema / properties / person / descriptionPrevious value: -"Case-insensitive name substring matched against the result speaker and/or the appearance speaker metadata."New value: +"Case-insensitive name substring. Returns statements whose speaker matches, by the stored label or by the name the result shows for it (a label NADELLA shown as Satya Nadella). Only when no such statement matches does it return rows of episodes whose host or guest list holds the name; a note then says that the speaker of those rows can be someone else."Input schema / properties / query / descriptionPrevious value: -"Lexical search text: one to three key words, for example 'rate cuts' or 'export controls'. A returned row must contain most of the query words, so a long question returns fewer rows; put the speaker in person and the publisher in institution instead of in the query. No serving-time model interprets the query. Retry synonyms or the speaker's own terminology if needed. Ignored by coverage; appearances matches only video title/channel metadata."New value: +"Lexical search text: one to three key words, for example 'rate cuts' or 'export controls'. A returned row must contain most of the query words, so a long question returns fewer rows; after common words are dropped, the first eight words find rows and every word counts in the ranking. Put a phrase in double quotes to find it word for word: claims whose quote holds the phrase come first. Put the speaker in person and the publisher in institution instead of in the query. No serving-time model interprets the query. Retry synonyms or the speaker's own terminology if needed. Ignored by coverage; appearances matches only video title/channel metadata."Input schema / properties / search_target / descriptionPrevious value: -"Canonical targets: \"search\" (default blended claims + passages), \"claims\" (normalized decision-relevant claims), \"passages\" (broad substantive paraphrase cards), \"pressure_points\" (refusals and declined-to-confirm claims), \"appearances\" (video catalog), and \"coverage\" (company-level structured-corpus inventory). Compatibility aliases are \"all\" -> \"search\", \"videos\" -> \"appearances\", and \"companies\" -> \"coverage\"; new callers should use the canonical values."New value: +"Canonical targets: \"search\" (default blended claims + passages), \"claims\" (normalized decision-relevant claims), \"passages\" (broad substantive paraphrase cards), \"pressure_points\" (refusals and declined-to-confirm claims), \"appearances\" (video catalog), and \"coverage\" (company-level structured-corpus inventory), and \"episodes\" (every episode the podcast feeds listed, transcribed or not, with title, date, link and the reason it was not transcribed; no paraphrase, no quote). Compatibility aliases are \"all\" -> \"search\", \"videos\" -> \"appearances\", and \"companies\" -> \"coverage\"; new callers should use the canonical values."Input schema / properties / search_target / enumPrevious value: -[
- "search",
- "claims",
- "passages",
- "pressure_points",
- "appearances",
- "coverage",
- "all",
- "videos",
- "companies"
-]New value: +[
+ "search",
+ "claims",
+ "passages",
+ "pressure_points",
+ "appearances",
+ "coverage",
+ "all",
+ "videos",
+ "companies",
+ "episodes"
+]Input schema / properties / show / descriptionPrevious value: -"Case-insensitive substring of a podcast show name, for example 'Odd Lots'. Returns podcast rows only. Combine with channel or institution to also include YouTube or official-document rows that match those; rows matching any given name filter are returned."New value: +"Case-insensitive substring of a podcast show name, for example 'Odd Lots'. Returns podcast rows only: the show's feed episodes and its YouTube uploads when its YouTube channel is registered for it. With search_target='episodes' it names the show whose feed episodes are listed. Combine with channel or institution to also include YouTube or official-document rows that match those; rows matching any given name filter are returned."Input schema / properties / sort / descriptionPrevious value: -"\"relevance\" orders lexical score first and publication date second; \"newest\" orders publication date first and lexical score second. Coverage uses its fixed company-inventory ordering."New value: +"\"relevance\" orders lexical score first and publication date second; a relevance search of claims with a query groups its rows by episode and gives them in turns (see episode_ranking). \"newest\" orders publication date first and lexical score second. Coverage uses its fixed company-inventory ordering."search_earnings_transcripts1 field changedInput schema / properties / detail / descriptionPrevious value: -"For claims, add structured_fields, secondary_families, period, time_horizon, conviction_qualifier, denominator, and falsifiable; for pressure_points, add tone_note. Ignored by disclosure_profile and coverage. The extractor's quantified flag is not published: it only records that the extractor wrote something into value, which the caller can already see in value itself."New value: +"For claims, add structured_fields, secondary_families, period, time_horizon, conviction_qualifier, denominator, falsifiable, and entity_refs (the companies, products and bodies the claim names: raw_name as spoken, ref_type such as competitor/customer/supplier, is_implied for an unnamed reference, and the matched entity_name/entity_ticker when known); for pressure_points, add tone_note. Ignored by disclosure_profile and coverage. The extractor's quantified flag is not published: it only records that the extractor wrote something into value, which the caller can already see in value itself."search_media_appearances1 field changedInput schema / properties / query / descriptionPrevious value: -"Lexical search text. Natural-language questions are accepted because person/question scaffolding is normalized, not because a serving-time model interprets them. Use concise topical vocabulary and retry synonyms or the speaker's own terminology if needed. Ignored by coverage; appearances matches only video title/channel metadata."New value: +"Lexical search text: one to three key words, for example 'rate cuts' or 'export controls'. A returned row must contain most of the query words, so a long question returns fewer rows; put the speaker in person and the publisher in institution instead of in the query. No serving-time model interprets the query. Retry synonyms or the speaker's own terminology if needed. Ignored by coverage; appearances matches only video title/channel metadata."search_company_filings1 field changedInput schema / properties / report_type / descriptionPrevious value: -"Optional report filter for every target except coverage. Accepts a common type such as annual, quarterly, or half_year, or a source form such as 10-K or 10-Q (or a source document code such as ACS, FR, IR, AMF-RFA, AMF-RES). For German, UK, and French filers, quarterly covers Q1, half-year, and Q3 reports. For Indian filers, quarterly covers the Q1, Q2, and Q3 results, and annual covers the Q4 results, which hold the audited full-year statements. For Japanese and Korean filers, quarterly covers Q1, half-year, and Q3 reports, and the Korean source forms are the DART codes 11011 to 11014. For metrics and facts, quarterly also returns every quarter-length value from other reports, including the fourth quarter, which is stored on the annual report. For commentary and risk_changes, annual covers 10-K and 20-F, quarterly covers 10-Q, and current covers 8-K."New value: +"Optional report filter for every target except coverage. Accepts a common type such as annual, quarterly, or half_year, or a source form such as 10-K or 10-Q (or a source document code such as ACS, FR, IR, AMF-RFA, AMF-RES). For German, UK, and French filers, quarterly covers Q1, half-year, and Q3 reports. For Indian filers, quarterly covers the Q1, Q2, and Q3 results, and annual covers the Q4 results, which hold the audited full-year statements. For Japanese and Korean filers, quarterly covers Q1, half-year, and Q3 reports, and the Korean source forms are the DART codes 11011 to 11014. For metrics and facts, quarterly also returns every quarter-length value from other reports, including the fourth quarter, which is stored on the annual report. For commentary and risk_changes, annual covers 10-K and 20-F, quarterly covers 10-Q, current covers 8-K, and 424B4 or 424B1 selects the final IPO prospectus."search_company_filings1 field changedInput schema / properties / search_target / descriptionPrevious value: -"Result type. coverage shows available report dates, types, and metric classes. filings shows report records and source URLs. metrics shows available concepts and series. facts shows numeric reported values. commentary shows management's qualitative statements from MD&A sections and earnings press releases. risk_changes shows year-over-year risk-factor changes from annual reports; no rows for a year means unchanged risk factors only when annual_report_years lists that year as compared, and never means no risks."New value: +"Result type. coverage shows available report dates, types, and metric classes. filings shows report records and source URLs. metrics shows available concepts and series. facts shows numeric reported values. commentary shows management's qualitative statements from MD&A sections and earnings press releases. risk_changes shows year-over-year risk-factor changes from annual reports; no rows for a year means unchanged risk factors only when annual_report_years lists that year as compared (unchanged from the IPO prospectus when the year is in compared_with_prospectus), and never means no risks."search_company_filings1 field changedInput schema / properties / metric_class / descriptionPrevious value: -"Optional metric class for metrics or facts, such as financial, ifrs, segment, kpi, or apm. Matching ignores letter case, so Product and product select the same facts."New value: +"Optional metric class for metrics or facts, such as financial, ifrs, segment, kpi, apm, or offering_terms (the price, shares and proceeds of an offering in a registration statement). Matching ignores letter case, so Product and product select the same facts."get_geo_data1 field changedInput schema / properties / dataset / descriptionPrevious value: -"Satellite dataset. One of:\n- \"fires_viirs\": active fire detections and fire radiative power (NASA FIRMS, 2012->, one day behind). Covers crop-residue burning, forest fires, and flaring.\n- \"no2_tropomi\": tropospheric NO2 column (Sentinel-5P, 2018->, ~3 days), an industrial/traffic activity proxy. Check valid_obs_share; cloudy intervals below 0.2 are weakly supported.\n- \"so2_tropomi\": SO2 column (Sentinel-5P, 2018->, ~3 days) for coal power, smelting, refining, and volcanoes. Noisy away from strong sources; track trends rather than absolute background levels.\n- \"co_tropomi\": CO column (Sentinel-5P, 2018->, ~3 days) for biomass/crop burning and industrial combustion. CO drifts across borders and is seasonal, so compare the same season across years.\n- \"aerosol_index_tropomi\": UV aerosol index (Sentinel-5P, 2018->, ~3 days) for smoke, dust, and haze. It is dimensionless; sustained values above ~1 indicate heavy smoke or dust, and it works over clouds.\n- \"ndvi_s2\": cloud-masked vegetation NDVI (Sentinel-2, 2017->, ~2-5 days), a crop-condition signal. Check valid_obs_share and compare the same season across years.\n- \"precip_chirps\": gauge-calibrated rainfall (CHIRPS, 1981->, ~2 days, 50S-50N) for monsoon, drought, and flood risk.\n- \"precip_imerg\": rainfall totals (NASA IMERG V07 Late, 2000->, ~1-2 days, global at 0.1 degree). Use where CHIRPS has no coverage; daily and monthly values are rainfall totals.\n- \"temperature_power\": mean/max/min 2m air temperature (NASA POWER, 1981->, ~3 days) for heatwaves and energy demand.\n- \"soil_moisture_power\": root-zone soil wetness from 0 to 1 (NASA POWER, 1981->, ~3 days) for agricultural drought.\n- \"wind_power\": 10m wind speed, daily maximum, eastward and northward components, the direction the wind blows from, and a 0-1 steadiness score (NASA POWER, 1981->, ~3 days). Use it to separate weather from emission changes in air-pollution data and to trace where smoke comes from.\n- \"humidity_power\": 2m relative humidity in % (NASA POWER, 1981->, ~3 days), a weather control for haze and fine particles."New value: +"Satellite dataset. One of:\n- \"fires_viirs\": active fire detections and fire radiative power (NASA FIRMS, 2012->, one day behind). Covers crop-residue burning, forest fires, and flaring.\n- \"no2_tropomi\": tropospheric NO2 column (Sentinel-5P, 2018->, ~3 days), an industrial/traffic activity proxy. Check valid_obs_share; cloudy intervals below 0.2 are weakly supported.\n- \"so2_tropomi\": SO2 column (Sentinel-5P, 2018->, ~3 days) for coal power, smelting, refining, and volcanoes. Noisy away from strong sources; track trends rather than absolute background levels.\n- \"co_tropomi\": CO column (Sentinel-5P, 2018->, ~3 days) for biomass/crop burning and industrial combustion. CO drifts across borders and is seasonal, so compare the same season across years.\n- \"aerosol_index_tropomi\": UV aerosol index (Sentinel-5P, 2018->, ~3 days) for smoke, dust, and haze. It is dimensionless; sustained values above ~1 indicate heavy smoke or dust, and it works over clouds.\n- \"ndvi_s2\": cloud-masked vegetation NDVI (Sentinel-2, 2017->, ~2-5 days), a crop-condition signal. Check valid_obs_share and compare the same season across years.\n- \"precip_chirps\": gauge-calibrated rainfall (CHIRPS, 1981->, ~2 days, 50S-50N) for monsoon, drought, and flood risk.\n- \"precip_imerg\": rainfall totals (NASA IMERG V07 Late, 2000->, ~1-2 days, global at 0.1 degree). Use where CHIRPS has no coverage; daily and monthly values are rainfall totals.\n- \"temperature_power\": mean/max/min 2m air temperature (NASA POWER, 1981->, ~3 days) for heatwaves and energy demand.\n- \"soil_moisture_power\": root-zone soil wetness from 0 to 1 (NASA POWER, 1981->, ~3 days) for agricultural drought.\n- \"wind_power\": 10m wind speed, daily maximum, eastward and northward components, the direction the wind blows from, and a 0-1 steadiness score (NASA POWER, 1981->, ~3 days). Use it to separate weather from emission changes in air-pollution data and to trace where smoke comes from.\n- \"humidity_power\": 2m relative humidity in % (NASA POWER, 1981->, ~3 days), a weather control for haze and fine particles.\nNASA POWER serves MERRA-2 up to a cut-off date (2026-08-31 at the time of writing) and the GEOS-IT system after it. The two models sit at different levels, so a one-day step across that date in a POWER dataset is a model change, not weather."search_company_filings1 field changedInput schema / properties / search_target / descriptionPrevious value: -"Result type. coverage shows available report dates, types, and metric classes. filings shows report records and source URLs. metrics shows available concepts and series. facts shows numeric reported values. commentary shows management's qualitative statements from MD&A sections and earnings press releases. risk_changes shows year-over-year risk-factor changes from annual reports; no rows for a year means unchanged risk factors, not no risks."New value: +"Result type. coverage shows available report dates, types, and metric classes. filings shows report records and source URLs. metrics shows available concepts and series. facts shows numeric reported values. commentary shows management's qualitative statements from MD&A sections and earnings press releases. risk_changes shows year-over-year risk-factor changes from annual reports; no rows for a year means unchanged risk factors only when annual_report_years lists that year as compared, and never means no risks."describe_datasetget_data_catalogget_geo_dataget_market_dataget_seriesget_style_guidesrun_sqlsearch_company_filingssearch_datasetssearch_earnings_transcriptssearch_media_appearancessearch_newssearch_seriessend_feedback
Add one secure layer between your agents and this server.