explore_data_coverage
Answer a question about WHAT THE PLATFORM COVERS — how many symbols a dataset holds, broken down any way you like.
===> THE TOOL for coverage COUNTS and BREAKDOWNS: "how many symbols are covered in
the investor relations dataset?", "what's that count by sector — how many tech
names?", "how many companies have earnings transcripts / 13F ownership / insider
activity / analyst estimates?", "how far back does the fundamentals history go?",
"what's your UK coverage by sector?". It plans queries over BOTH the catalogue's
own metadata and the datasets themselves, so it can count what no enumeration
endpoint knows: which symbols actually carry a PARTICULAR dataset, grouped by
sector, industry, country, market cap, or year.
PUBLIC at the backend — no account, plan, or entitlement is needed to answer a
coverage question, by design: a prospect evaluating the platform should be able to
ask what it covers. (The MCP connection itself still carries the client's OAuth
session — that gate is transport-wide, not this tool's.) Never treat a coverage
question as plan-gated or quota-gated, and never tell the user it needs an upgrade.
Pick between the three coverage-adjacent routes by what the answer looks like:
- a LIST of what exists ("which sectors / indicators are available?", "is X
covered?") -> `list_options`. Instant, no async job.
- a COUNT or breakdown of coverage -> THIS tool.
- the DATA itself (values, history, trends, comparisons) ->
`explore_data_catalogue`.
Do NOT answer a coverage count from memory, from the "2,900+ companies / ~420
indices" headline figures, or by eyeballing the length of a `list_options`
payload — those are universe-wide totals and say nothing about per-dataset
coverage. Run this tool.
There is no `delivery` argument: results always go to the dashboard so the user can
interact with them. Rate-limited to 20/hour server-side.
Asynchronous: returns {"task_id": "...", "status": "PENDING"}. Poll a SINGLE task
with `get_task_status` until SUCCESS (the result is a plain dict — there is NO
nested task to chase). Expect roughly 1-5 minutes depending on the tables queried —
a task still PENDING after a couple of minutes is normal, so keep polling. On
SUCCESS, `result` is:
{"user_query": "...", "delivery": "dashboard",
"results": {"<query name>": {"description": "...", "columns": [...],
"rows": [...the FULL result set...],
"row_count": N}, ...}}
`rows` is NOT sampled or truncated — every bucket of a breakdown comes back
(`row_count` matches len(rows)), so the totals you report are the real ones.
Render each entry as a chart/table for the user. If the request can't be served
from the platform's data, `result` instead carries a `validation_status` of
"REJECTED" (with a reason) — relay that rather than retrying blindly.
Input Schema
TableJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The coverage question in natural language, as asked — e.g. "count the distinct symbols in the investor relations dataset, broken out by sector". |
Output Schema
TableJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| queue | No | Worker queue the job was routed to. | |
| status | Yes | PENDING on dispatch. | |
| task_id | Yes | Poll this with get_task_status until SUCCESS. |