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.

`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

TableJSON 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

TableJSON 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?

Goes well beyond the single readOnlyHint: discloses auth requirement and the 403/422 error semantics, that tokens are minted server-side and must never be edited, the server default of 50 documents, the 20-passage cap on resolve_passages, and the `traceable` row/cohort/none contract including the `no_keys` failure mode. This is rich operational context the annotations cannot carry.

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 front-loaded and headed (CITATION rung, TWO WAYS IN, THREE CITATION GRAINS, READ traceable), so an agent can skim to the decision it needs. It is long for a tool description and partly duplicates the schema, e.g. the keys example and the 'never pass SQL' warning appear in both, which costs a little against 'every sentence earns its place'.

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?

Even though an output schema exists, the description supplies the interpretation an agent actually needs: the three citation grains and their precedence, the meaning of `traceable`, and the per-column vs per-row split. Combined with auth and error-code coverage, nothing needed to call it correctly is missing.

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 100%, so the baseline is 3, but the description adds substantial meaning: pass EVERY identifying column, extra columns ignored, a missing one is fatal, grain alone is insufficient (with a concrete view example), `column` is required for YoY/change relations, and `values`/`prompt` re-aim a token without changing which documents return. That is genuine value beyond the schema.

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+resource — resolving numbers back to the documents they were read from — and immediately differentiates from the row-returning siblings (`explore_data_catalogue`, `run_saved_query`, `get_signed_sql_drilldown`). An agent can tell exactly what this does and does not do 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.

Usage Guidelines5/5

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

Gives explicit trigger phrases ("where does that come from", "can you cite that"), prescribes unprompted use before publishing actionable figures, names the two entry paths and declares `relation`+`keys` preferred with the fallback condition for tokens. It also routes the agent away from misuse (don't construct tokens, don't trace the whole result set, read `traceable` before writing).

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