**Financial Data Natural Language Retrieval Tool**
**What it is:**
A single-pass, multi-agent search across S&P's specialized data retrieval agents.
A router dispatches the query to the relevant data agents in parallel and merges their results.
There is a search tool — call it multiple times for multi-step questions (see below).
**Capabilities:**
- Routes natural-language queries across multiple specialized data agents in a single pass
- Aggregates structured (tabular) and unstructured (filings/transcripts) data with citations
- Supports filtering by timeframe, company, dataset, etc. expressed in natural language
<REASONING>
## CRITICAL: Break down multi-step queries
Grounding does NOT support questions that require sequential reasoning inside a single call.
Each call is independent; the tool cannot use the result of one sub-query to drive another.
**You** must do the sequencing by issuing multiple calls.
If a query has the shape "find X, then for each of those find Y", split it:
Example user query: "Top 10 oil and gas companies by market capitalization with their P/E ratios"
Step 1 — Call Grounding: "Top 10 oil and gas companies by market capitalization"
Step 2 — Grounding returns: [list of 10 companies]
Step 3 — Call Grounding: "P/E ratios for [list of 10 companies]"
Step 4 — Combine the two result sets in your final answer.
Other shapes that require sequencing:
- "Top N <entities> by <metric>, then <other metric> for each"
- "Companies that did X last year, and their <attribute>"
- "<Person>'s current employer's <financials>"
When in doubt, split. Do NOT submit a compound sequential query and hope the router handles it.
When a query is NOT sequential (single fact, single comparison, single filter, multiple parallel facts), submit the user's
exact words. Only rephrase when you are constructing a follow-up step from a prior result.
</REASONING>
<RESPONSE FORMAT>
## Response schema
Every Grounding response is a list of `response` items. Each item is a self-contained "table"
with this shape:
{
"schema": { "fields": [ {name, type}, ... ] }, // column definitions
"data": [ { col1: val, col2: val, ... }, ... ], // flat tabular rows
"sources": [ ...Source objects... ], // see below
"problems": [ ... ], // any issues encountered
"metadata": { ... }
}
**`data` is a flat table.** Even when results "feel" like prose (a transcript snippet, a news
headline, a filing excerpt), they are returned as rows in a table whose columns are defined by
`schema`. Do not round any numeric values that come back as part of data.
**One table can correspond to MANY sources.** Sources are attached at four granularities, and a
single `response` item commonly has a different source per row:
- `TableSource` — applies to the entire table (one source covers all rows)
- `ColumnSource` — applies to every value in a named column (e.g., a column sourced from one feed)
- `RowSource` — applies to a specific row by `index` (typical for transcripts/filings/news,
where each row = one document and has its own deep link)
- `CellSource` — applies to one specific (row, column) cell
Each Source carries a `SourceInfo` of `{ uri, name, provider }`. Treat `uri` as the canonical
clickable link for that scope. the `name` is what should be the display name of the `uri`.
When rendering a row to the user, attach the **most specific** source that covers it
(cell > row > column > table). For row-per-document tables, this means each row gets its own link.
</RESPONSE FORMAT>
<CITATIONS>
## CRITICAL: How to cite — inline markdown links, web_search style
This tool's results render in MCP Client Desktop like Claude Desktop/Gemini Enterprise.
The Desktop citation chip UI (numbered badges, hover cards) is reserved for the built-in `web_search` tool
and is NOT available to MCP tools. You must replicate its *functionality* using plain inline markdown links — placed in the same
positions, with the same density, that web_search citations would occupy.
The goal: the user should never have to scroll to a "Sources" footer to find what backs a claim.
Every fact, quote, number, and entity should have its supporting link directly adjacent to it
in the prose or table cell.
**The format:**
[Source Name](exact source uri)
Place this link **immediately after** the claim or entity it supports — same sentence, same
table cell, same bullet — exactly as web_search citations appear inline next to the text they
back. If a single claim is supported by multiple sources, emit multiple links back-to-back:
`...claim ([Source A](uriA)) ([Source B](uriB)).`
**Mapping Grounding sources to inline links:**
For each `response` item, walk the `data` rows and pick the most-specific source covering each
fact (cell > row > column > table — see RESPONSE FORMAT). A single response item commonly
produces many distinct inline links because most rows have their own `RowSource`. Render those
per-row links inside the row (in the table cell or right after the row's prose), not collapsed
into a single table-level link.
**URI integrity — DO NOT TRUNCATE.**
Many URIs (especially `docviewer` / `capitaliq` deep links) carry query parameters like
`start`, `end`, `chunk`, `docId`, fragments, etc. that anchor the link to a specific span of
highlighted text in the document viewer. These parameters are load-bearing: stripping them
breaks the deep link and the user loses the highlight. **Emit every URI exactly as returned by
the tool — character-for-character, including all query parameters and fragments. No
shortening, no encoding changes, no "..." in the middle.**
**Entities AND claim evidence both use inline links.**
- Entities (company, person, security, ticker) with a profile/landing `uri` → wrap the entity
name itself: `[Accenture](https://...)`.
- Claim evidence (a quote, a metric, a paraphrase from a filing or transcript) → put the link
right after the claim: `... revenue grew 12% ([Q4 2024 10-Q](https://...)).`
- Both can coexist in one sentence.
**Visually cue lifted text.**
When the claim is a direct quote or close paraphrase from an unstructured source, mark the
lifted text with quotation marks, italics, or bold so the user can spot what came from the
document vs. your synthesis. Then put the link right after.
**Worked example.**
Given a transcripts/filings row with `RowSource.uri =
https://...capitaliq.../docviewer?docId=ABC&start=12345&end=12890&chunk=7` and
`RowSource.name = "Accenture Q4 2024 Earnings Call"`:
[Accenture](https://...capitaliq.../company/...) said it expects
*"high-single-digit revenue growth"* in FY25 ([Accenture Q4 2024 Earnings Call](https://...capitaliq.../docviewer?docId=ABC&start=12345&end=12890&chunk=7)).
The entity name is a clickable link; the quoted phrase is italicized; the source link sits
immediately after the quote with the full deep-link URI preserved verbatim.
**In tables**, put the row's source link inside the row — either as a trailing column ("Source")
whose cell is `[Name](uri)`, or appended to the most relevant cell. Do NOT collect row links
into a footer.
**Do NOT:**
- Drop sources into a trailing "Sources:" section instead of inlining them next to claims
- Truncate, shorten, or strip query parameters / fragments from any returned URI
- Emit a single table-level link when each row has its own `RowSource` / `CellSource`
- Show a bare entity name when a `uri` for that entity was returned
**Do:**
- Inline `[Name](uri)` for every fact and every entity, placed directly adjacent to the text
it supports — exactly how web_search citations appear
- Preserve URIs character-for-character
- Emit per-row links when `RowSource` / `CellSource` are present
- Mark quoted/paraphrased text with quotes, italics, or bold
</CITATIONS>
<AGENT_SELECTION>
You can use the related "agents" tool to find out all of the data agents you are entitled to use. The "allowed_datasets"
parameter takes in agent names, which can be found in the "name" field from the /agents tool.
Note that using the "allowed_datasets" parameter for a single agent short circuits the routing and automatically goes to that
agent. When multiple agents are specified, the routing only happens between those agents. This can be used when the user specifically
wants data from a particular dataset, but default to not using it. The router is optimized to route queries, so you should only use
this parameter when actually required.
</AGENT_SELECTION>
**Example use cases (single-call):**
- Financial data: "Show me AAPL's Q3 2024 revenue trends"
- Earnings commentary: "What did Accenture say their goals are in their last earnings call?"
- Filings lookup: "AAPL's last income statement"
- Corporate governance: "2023 salary and bonus for Walmart executives"
**Best practices:**
- Pass through the user's exact wording for the first call; rephrase only for derived follow-ups.
- Include explicit timeframes and entity identifiers (tickers, full company names) when you have them.
- If the question is sequential, plan the call sequence before issuing the first call.
- Data formatting: Make sure to keep numbers as accurate as possible from the response. Minimize rounding.
**REMEMBER: Break down sequential queries. Inline a `[Name](uri)` markdown link directly next
to every entity AND every claim — the same way web_search citations appear inline — and never
truncate the returned URI.**
retrieve_data
View in the ChatGPT registry
Agent DiscoverabilityChatGPT Plugin Discovery Score
