Skip to main content
Glama

trace_data_sources

Read-only

Resolve numbers you are holding back to the documents they were read from — the filing, the section, or the verified quote.

The CITATION rung of the chain. `explore_data_catalogue`, `run_saved_query` and
`get_signed_sql_drilldown` hand back rows; this says where each number CAME FROM.
Reach for it whenever the user asks "where does that come from", "which filing",
"can you cite that", "how do you know" — and unprompted before you publish a figure
they are going to act on.

TWO WAYS IN, and the FIRST is preferred:
  1. `relation` + `keys` — `relation` is a name off the result's
     `sources.relations[].relation`; `keys` is one JSON object per row you want
     traced. Pass EVERY identifying column the row carries — the reported grain
     AND the period/date — e.g. [{"symbol": "SNOW", "cik": "0001273087",
     "date": "2026-06-30"}]. Extra columns are ignored; a missing one is fatal.
     Grain alone is NOT always enough: the join behind a view can need a column
     its `grain` does not list (current_institutional_holders_v reports grain
     [symbol, cik] but joins on `date` too, and keys without it resolve nothing).
     No token and no SQL, so this is the form
     that works when you assembled a table across several calls (`run_saved_query`
     issues one call per saved token, so a token only ever describes a fragment of
     what you ended up with) or filtered the rows yourself. Trace the rows you will
     actually cite — a few dozen — not the whole result set.
  2. `encrypted_query_token` — a `trace_token` from a `sources` block, or the
     original `query_token` / `signed_query_url`, for the "I have a link and
     nothing else" case. The URL form is unwrapped automatically. Tokens are minted
     server-side only: never construct, guess or edit one, and never pass SQL here.

THREE CITATION GRAINS come back, finest first. Which one answers depends on the
relation and you do not choose it — one surface over several stacks:
  - `citations` carrying `quotes` — the passages an analysis row was actually
    WRITTEN from, with quotes machine-verified against the section text. The
    strongest evidence in the system; quote these verbatim.
  - `citations` of kind `transcript_section` — a link to ONE numbered speaker turn
    of an earnings call. `get_document_section` fetches that turn's text.
  - `documents` — the whole source document (SEC 13F / Form 4 / 8-K / 10-Q / 10-K,
    an earnings-call transcript, an IR PDF) a number was read from. The fallback,
    and available wherever lineage reaches a document at all.
`providers` names which of those answered, and every relation's traceability is
derived from the live data model — a redefined view re-derives its own on the next
refresh, so trust this response over anything remembered.

READ `traceable` BEFORE YOU WRITE. "row" means each row maps to one document and
may be cited that way. "cohort" means the number is a sum over a SET of filings:
the response carries `cohort` instead of `documents`, only the set can honestly be
cited, and writing "per this filing, hedge funds own 4.1%" off a cohort row is the
exact failure this field exists to prevent. "none" means the lineage reaches no
document — say the number cannot be sourced rather than reaching for a plausible
filing. A `reason` of "no_keys" means a column the join needs was missing
from every key object — nearly always the period/date — not that the number is
unsourced. Add the date and any other identifying column on the row, and re-call.

`company_financials` rows: relation = the row's financial_type; keys = symbol, date,
statement, line_item for the standardized tables, symbol, line_item, current_period
for edgar_financials_yoy_change_m. Which keys the as-filed edgar_10q / edgar_10k /
edgar_eight_k tables need is unresolved (whole rows return no_keys) — cite the
standardized row instead, or quote the as-filed row's own filing_url.

`column` traces ONE column instead of the whole row — necessary for a YoY or
change relation, where each value column resolves to a DIFFERENT filing (the
result's `sources.relations[].per_column` says which columns work this way).

`resolve_passages=True` fetches the speaker turn or filing section text instead of
just a link — a link is already a citation. `values` and `prompt` re-aim a
placeholder-twin token but cannot change WHICH documents come back for a given set
of rows.

Requires auth (your MCP client attaches the OAuth bearer automatically). A 403 means
the token is invalid or tampered — re-fetch the link rather than retrying an altered
one; a 422 means neither `relation`+`keys` nor `t` arrived in a usable form.

Input Schema

NameRequiredDescriptionDefault
keysNoWith `relation`: one object per row to trace, carrying EVERY identifying column (the grain AND the period/date), e.g. [{"symbol": "SNOW", "cik": "0001273087", "date": "2026-06-30"}]. A few dozen rows, not the whole set.
columnNoWith `relation`: trace ONE value column instead of the row — needed for YoY/change relations (see `sources.relations[].per_column`).
promptNoToken form, placeholder twins only: natural-language fill for slots `values` did not cover.
valuesNoToken form, placeholder twins only: {slot name: typed value} that re-aims the token deterministically.
relationNoPreferred form: a relation name from the result's `sources.relations[].relation`. Pass with `keys`.
max_documentsNoCap on documents returned (server default 50).
resolve_passagesNorelation+keys form: also fetch the passage TEXT behind each citation (capped at 20). Ask for it when you intend to quote, not by reflex.
encrypted_query_tokenNoFallback form: a `trace_token` from a sources block, or the original `query_token` / `signed_query_url`, verbatim. Never construct or edit one; never pass SQL.

Output Schema

NameRequiredDescriptionDefault
modeNo"documents" when resolved; "recipe"/"none" otherwise.
cohortNoThe SET of filings a cohort number sums over.
reasonNoWhy nothing resolved, e.g. "no_keys" (a join column, usually the date, was missing).
relationNo
citationsNoFiner citations: verified quotes or transcript speaker turns.
documentsNoWhole source documents (SEC filings, transcripts, IR PDFs).
providersNoCitation providers that answered.
traceableNo"row", "cohort" or "none" — read before writing.
trace_tokenNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare readOnlyHint, so the description carries most of the burden and does so richly: three citation grains, the traceable row/cohort/none semantics with the concrete failure mode each prevents, the no_keys reason, token-minting rules, auth behavior, and 403/422 error meanings. This is exactly the behavioral context annotations omit.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well structured and front-loaded — purpose first, then TWO WAYS IN, THREE CITATION GRAINS, and a READ traceable section. It is long, and a few clauses (e.g. the re-derivation note, the repeated trace-a-few-dozen-rows advice) could be trimmed, but nearly every sentence earns its place for a tool of this complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite an output schema existing, the description still supplies the interconnections an agent needs: which grain answers, what providers means, the per-relation key requirements including the unresolved as-filed tables, and the fallback guidance to cite the standardized row. No decision-relevant gap remains.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, but the description still adds real meaning beyond it: how to build keys (include the period/date, extra columns ignored, missing fatal, with the current_institutional_holders_v example), what column does for YoY relations, when resolve_passages is warranted ("not by reflex"), and that values/prompt cannot change which documents return.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Resolve numbers ... back to the documents they were read from") and immediately distinguishes itself from the row-returning siblings (explore_data_catalogue, run_saved_query, get_signed_sql_drilldown) by framing itself as "where each number CAME FROM." An agent can select this over its siblings 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.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit triggers are given ("where does that come from", "which filing", "can you cite that", "how do you know"), plus a proactive condition (before publishing a figure the user will act on). It also routes between the two input forms, naming relation+keys as preferred and explaining the specific cases that select the token form.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources