UK Parliament MCP Server

get_bill_committees

Find the committees that examined a bill and get their committee stages, sitting dates, and related select committee reports or evidence.

Instructions

Find the committees that examined a bill | which committee scrutinised this bill, legislative scrutiny, committee stage, select committee reports on a bill | Use when asked which committees looked at a bill, or to find committee evidence and reports on it | Returns the bill's committee stages (with sitting dates) and select committee business on it with the examining committee; items whose linked_bill_ids include the bill are confirmed links. Combines: get_bill_by_id, get_bill_stages, get_committee_business, get_committee_business_by_id, get_publications. See also: get_committee_bills (the reverse), get_bill_overview.

    Args:
        bill_id: Bill ID. Get from search_bills or get_bill_overview. Example: 3764

    Returns:
        Committee stages and committee business for the bill.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`bill_id`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 6, 2026

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations, the description carries the behavioral burden and does well: it discloses that this is an aggregator ('Combines: get_bill_by_id, get_bill_stages, ...'), what the return contains (committee stages with sitting dates, select committee business with the examining committee), and a data-quality caveat ('items whose linked_bill_ids include the bill are confirmed links'). It does not mention permissions, rate limits, or pagination, so it falls short of a 5.

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 purpose and trigger before the pipe-separated synonym keywords and the aggregation notes. The keyword list is somewhat stuffed and the separate 'Returns' section partly duplicates the body, but nothing is disorganized or buried.

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?

An output schema exists, so return values needn't be spelled out, yet the description still summarizes the shape usefully. For an aggregator of five underlying tools, it explains the combined provenance and the confirmed-link caveat; only auth/limits and the merged-item ordering are left unaddressed.

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 0% (the only param has a bare title and no description), so the description must compensate, and it does: 'Bill ID. Get from search_bills or get_bill_overview. Example: 3764' supplies both provenance and format. It adds real value beyond the schema, though it doesn't state the type or invalid-ID behavior.

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?

Specific verb ('Find') plus resource ('the committees that examined a bill'), with a synonym line and an explicit sibling disambiguation ('See also: get_committee_bills (the reverse)'). An agent can separate this from the reverse lookup and from get_bill_overview without opening a 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?

States the trigger explicitly ('Use when asked which committees looked at a bill, or to find committee evidence and reports on it') and names the complementary/alternative tools (get_committee_bills as the reverse, get_bill_overview). Both when-to-use and the alternative routing are covered.

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

Deploy Server