Dapper

List Bill Updates

list_bill_updates

Read-onlyIdempotent

Legislative updates (tramitaciones) for a bill, or a cross-bill feed of recent ones — one tool, two modes depending on whether bill_id is set.

With bill_id: the ordered sequence of tramitaciones for that one bill (committee review, floor vote, promulgation, etc.), sorted by orden (tramitación sequence number). Ignores country_code/commission_id/since/until. Tip: list_bills(id=...) already includes up to 200 of these inline — use this tool directly only if you need more than 200 or want to page through them independently.

Without bill_id: cross-bill feed — 'what moved' across a country's whole docket, newest first, for 'what bills moved yesterday/this week' or 'what did commission X decide this week' type questions where you don't already have a bill_id. Defaults to the last 7 days when since is omitted. country_code is comma-separated (e.g. BR,CO); omit for every accessible/your default country. since/until filter on created_at (when the update was ingested), a close but not exact proxy for the real tramitación date.

Input Schema

Name	Required	Description
`limit`	No	Rows per page (1-100, default 20). The response's `meta.has_more` and `meta.next_cursor` tell you whether there are more. `meta.total`, when it is not null, is the full count without paging; some lists return null rather than pay for a count. Raise the limit when you genuinely need a whole list in one call rather than the most relevant few.
`since`	No	Feed mode only. Filters created_at (when the update was ingested), a close but not exact proxy for the tramitación's own date. Defaults to 7 days ago when omitted.
`until`	No	Feed mode only; defaults to now, so future-dated rows never surface unless you ask for them.
`cursor`	No	Opaque pagination cursor from a previous response's `meta.next_cursor`. Pass every other filter unchanged when paging. Only ever use a cursor this API handed you — never build one. With `q`, a cursor continues the keyword listing (`meta.mode: "keyword_fallback"`): relevance-ranked results are a single page of at most 20 rows and report `has_more: false`, so if you got one there is no next page to ask for, and a `limit` above 20 adds nothing to it. Narrow `q` instead of paging.
`bill_id`	No	Set it for one bill's ordered tramitaciones; omit it for the cross-bill feed of what moved recently. The two modes ignore each other's filters.
`country_code`	No	ISO alpha-2 country codes, comma-separated or as a list: 'BR,CO' or ['BR','CO']. Pass 'all' for every country you can access. Omitting it is NOT the same as 'all': logged in via OAuth it falls back to your own default country, and the response says so in `meta.country_scope`.
`commission_id`	No	Feed mode only: narrow to updates on bills in this commission — the way to answer 'what did commission X decide this week'.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already establish read-only/idempotent safety, so the description spends its space on non-obvious behavior: default 7-day window in feed mode, `since`/`until` filtering on created_at as 'a close but not exact proxy' for the real tramitación date, and the country fallback where omitting is not the same as 'all' and reports `meta.country_scope`. These are failure modes an agent would otherwise hit blindly.

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-loaded with a one-sentence mode summary before the bolded per-mode blocks, which is exactly the right structure. It is on the long side and restates some schema parameter text (e.g. since/until proxying), so a little could be trimmed without losing meaning.

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?

With an output schema present, the description needn't describe return shapes, and it covers everything else an agent needs: both modes, filter interactions, defaults, paging caveats, and the country-scope fallback. Nothing material is left to inference.

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 schema already documents each parameter; the description's added value is cross-parameter semantics — which filters each mode ignores, the default window, and the comma-separated/all/omit distinction for country_code. It slightly overlaps the schema text rather than adding wholly new per-parameter detail, so 4 rather than 5.

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 ('Legislative updates (tramitaciones) for a bill') and immediately states the dual-mode nature keyed on `bill_id`. It also distinguishes itself from sibling `list_bills`, noting that tool already returns up to 200 of these inline, so an agent can pick correctly without opening either 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 when-to-use for both modes: bill_id mode for one bill's ordered sequence, feed mode for 'what moved yesterday/this week' or 'what did commission X decide this week'. It goes further and names the alternative (`list_bills`) plus the exact condition for preferring it (need >200 or independent paging).

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

All Dapper 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.

Resources

Need Help?