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). A
not-authenticated error means the sign-in lapsed; the fix is signing in, never a
different token.

Input 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

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?

Beyond readOnlyHint, it discloses the response shape (`format`/`count`/`rows`, never the SQL), the `is_new_record` flagging for contextual drilldowns, `_source_*` provenance columns plus a `sources` block with grain/traceability, the 403 and 422 meanings, and the fan-out stall risk. That is far more than the annotation carries.

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?

Front-loads the core action and the token source before routing, errors, and provenance. The all-caps citation block and the saved-row repetition are a bit heavy, but every paragraph carries information an agent needs to call this correctly.

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 with an output schema present, it explains the return envelope, provenance semantics, and truncation. Combined with auth, 403/422 handling and the downstream trace_data_sources handoff, nothing material about invoking this tool is left unanswered.

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; the description still adds real meaning by saying the URL or just its `t` is accepted and unwrapped, that `values`/`prompt` only apply to placeholder-twin tokens and that substituted `parameters` should be echoed, and that `max_rows` should be used on fan-out drilldowns.

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: fetching the rows behind an event-web drilldown from a server-minted query token. It immediately separates itself from siblings by naming run_saved_query (saved-request tokens) and get_company_event_web (the source of signed_query_url).

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 routing rules: use this when the node carries `signed_query_url`, use `run_saved_query` for saved-row tokens, use `get_document_section` to open a cited speaker turn. It also states when-not behavior (403 = do not retry with an altered token; not-authenticated = sign in again).

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