Skip to main content
Glama

get_signed_sql_drilldown

Read-only

Fetch the rows behind an event-web drilldown from its server-minted query token.

Some `get_company_event_web` nodes carry `signed_query_url` in their `fetch` hint —
an opaque, tamper-proof link the backend minted for exactly that node. This tool is
the zero-planning rung of the chain: no query to compose, the rows come back
directly. Pass either the full `signed_query_url` or just its `t` parameter; the
URL form is unwrapped automatically. A token that came from a
SAVED request rather than the event web belongs to `run_saved_query` instead — same
endpoint, but it replays every query in the saved row in one call.

Returns {"format": "table", "count": N, "rows": [...]} — rows only, never the
underlying SQL. For contextual drilldowns the NEW record is flagged
`is_new_record: true` and the remaining rows are the prior/context records to read
it against (the node's `signed_query_context` describes what they are).

CITE WHAT YOU PUBLISH: the rows may carry `_source_*` columns — `_source_url`,
`_source_filed_at`, `_source_document_id`, `_source_citations` — and the response a
`sources` block naming each relation, its grain, and whether it is `traceable` per
"row" or only as a "cohort". That is the provenance of the numbers, not padding:
quote `_source_url` when the user asks where a figure came from, and for anything
you are about to publish — or the moment they ask for the filing, the quote, or
"how do you know" — pass `sources.relations[].relation` plus each row's
identifying columns (the grain AND its date) to `trace_data_sources`, which
resolves them to the source document, the
section, or the verified quote behind the number. `get_document_section` then opens
the exact speaker turn a transcript citation points at.

HTTP 403 means the token is invalid or tampered — do not retry with an altered
token; re-fetch the event web for a fresh link instead.

`values` and `prompt` re-aim a token that is a PLACEHOLDER TWIN at other entities;
the response then carries `parameters` (what was substituted) alongside `rows`;
echo those to the user. A 422 means the request could not be
mapped onto the token's slots. The full slot vocabulary of a SAVED row lives in
`list_saved_queries` -> `metadata.parameters`, and replaying a saved row is
`run_saved_query`, not this tool.

An uncapped drilldown that fans out to constituents can return tens of thousands
of rows and stall the client for minutes — pass `max_rows`.

Requires auth (your MCP client attaches the OAuth bearer automatically) — unlike
`get_company_event_web`, which is public: the web hands out the LINK to anyone, but
following it to the underlying rows is for signed-in users. A signed-out caller gets
a not-authenticated error, not rows; the fix is signing in, never a different token.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
promptNoPlaceholder-twin tokens only: natural-language fill for slots `values` did not cover, e.g. "the same rows for KSS". Omit for a plain event-web link.
valuesNoPlaceholder-twin tokens only (preferred over prompt): {slot name: typed value}, filled deterministically, e.g. {"symbol": "KSS"}. Omit for a plain link.
max_rowsNoCap on rows returned, e.g. 500; the response then carries row_count and truncated: true. Pass it on any drilldown that can fan out to constituents.
encrypted_query_tokenYesA node's `signed_query_url` from get_company_event_web, or just its `t` parameter — verbatim. Never construct or edit one; never pass SQL.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
rowsNoResult rows (cell values are strings or null). May carry _source_* citation columns. Null on a replay entry whose token failed (see `error`).
countNoRows returned in `rows`.
formatNo"table".
sourcesNoProvenance block; present when the numbers trace to documents.
row_countNoFull row count when `truncated` (max_rows sliced the result).
truncatedNo
parametersNoValues substituted into a placeholder twin; echo them to the user.
ignored_valuesNoKeys in `values` this token does not use.
defaulted_parametersNoSlots that kept the saved example value.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only give readOnlyHint=true, and the description layers substantial extra behavior on top: HTTP 403 means invalid/tampered token with no-retry guidance, 422 means slot-mapping failure, auth is required (unlike the public get_company_event_web), and uncapped drilldowns can stall the client for minutes. These are exactly the operational facts 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.

Conciseness4/5

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

The critical routing facts (what it fetches, which token, which sibling to use instead) are front-loaded in the first two paragraphs. It is long and somewhat sprawling across provenance, error codes, and auth, but nearly every sentence carries distinct, load-bearing information rather than filler.

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?

Covers token provenance, the two value-fill paths, truncation via `max_rows`, 403/422 failure modes, auth requirements, and the `_source_*`/`sources` provenance contract with follow-on tools (trace_data_sources, get_document_section). Even though an output schema exists, the description goes further and explains the `is_new_record` flag and the `parameters` echo, leaving nothing an agent needs in order to call or interpret it.

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

Parameters4/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 real meaning: the URL form is auto-unwrapped so either the full `signed_query_url` or just its `t` works, and `values`/`prompt` only apply to PLACEHOLDER TWIN tokens and produce a `parameters` block to echo. It goes beyond restating the schema without fully exhausting token-slot vocabulary (which it delegates to list_saved_queries).

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?

Opens with a specific verb+resource+scope: 'Fetch the rows behind an event-web drilldown from its server-minted query token.' It explicitly distinguishes itself from the closest siblings — get_company_event_web, run_saved_query, list_saved_queries — so an agent can route correctly without opening any 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?

Names the exact precondition (a node carrying `signed_query_url` from get_company_event_web), the explicit exclusion (tokens from SAVED requests belong to `run_saved_query` instead, 'not this tool'), and the alternative-route vocabulary source (`list_saved_queries` -> `metadata.parameters`). When/when-not/alternatives are all covered.

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