us-lobbying-mcp-server

Query disclosure tables

uslobbying_dataframe_query

Run one read-only SELECT over staged disclosure tables, materialize the complete result, then retrieve whole rows by result_table and next_offset without rerunning SQL. Inspect columns with uslobbying_dataframe_describe first.

Input Schema

Name	Required	Description
`sql`	No	One read-only SELECT; exclusive with result_table and offset.
`offset`	No	Canonical row offset for result_table, default zero.
`canvas_id`	Yes	Canvas token returned by a disclosure analytical tool.
`row_limit`	No	Maximum whole rows in this response; positive integers clamp to 100, then to any lower provider ceiling.
`register_as`	No	Fresh result table name for a new SQL call; omit for a generated name.
`result_table`	No	Previously materialized result table; exclusive with sql and register_as.

Output Schema

Name	Required	Description
`rows`	No	Whole JSON-safe rows.
`error`	No	Present when the call failed. Absent on success.
`offset`	No	Canonical-order starting row offset.
`columns`	No	Complete result schema.
`dataset`	No	Materialized dataset and routing.
`guidance`	No	Table names and dataframe instructions.
`canvas_id`	No	Tenant-scoped canvas access token.
`row_count`	No	Exact materialized result count.
`row_order`	No	Delivery orders by all materialized values.
`truncated`	No	More materialized rows remain; continue with next_offset.
`query_tool`	No	Query or retrieve materialized table rows.
`next_offset`	No	Next undelivered row offset.
`result_table`	No	Stable materialized result table.
`describe_tool`	No	Inspect exact table schemas before SQL.
`rows_returned`	No	Rows actually delivered.
`delivery_limits`	No	Clamped controls for this call; an empty map means no clamp. Immediate cursor replay retains its original values.
`output_complete`	No	Whether this result has no remaining delivery rows.
`effective_row_limit`	No	Effective row limit when a delivery or provider ceiling lowers the requested limit.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 26, 2026

TDQS

A4.4/5.0

Behavior4/5

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

The description adds important behavior beyond the annotations: one SELECT is executed, the complete result is materialized, and subsequent row retrieval does not rerun SQL. This clarifies the stateful materialization step, which is consistent with readOnlyHint=false, while annotations already cover destructive and idempotent characteristics.

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

Conciseness5/5

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

Two sentences, front-loaded with the primary action, and no wasted text. The prerequisite follows naturally after the workflow description.

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

Completeness4/5

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

The description covers the core workflow, materialization behavior, retrieval path, and the describe-first prerequisite. With a full output schema and complete parameter descriptions, the remaining details are adequately handled by structured fields, though the next_offset/offset wording could be tightened.

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 adds useful mode semantics around sql, result_table, and offset-based row retrieval, though it refers to 'next_offset' while the schema parameter is 'offset', creating a minor terminology mismatch.

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?

The description states a specific verb and resource: run one read-only SELECT over staged disclosure tables, materialize results, and retrieve rows by result table. It clearly distinguishes the SQL path from the retrieval path, and points to the sibling describe tool for column inspection.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

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

It gives a clear workflow prerequisite: inspect columns with uslobbying_dataframe_describe first. It also explains the two operating modes, SQL versus result_table retrieval, though it does not explicitly compare when to use this tool instead of the other search-oriented siblings.

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

All us-lobbying-mcp-server tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.