UK Parliament MCP Server

search_hansard_contributions

Find UK Parliament Hansard contributions by type—spoken, written, intervention, question, or answer—and filter by house, date range, member, or keyword.

Instructions

Search Hansard by contribution type | Hansard, spoken, written, interventions | Use to find specific types of parliamentary contributions. Returns contributions of the specified type. See also: get_member_contribution_summary, get_debate_by_id.

    Args:
        contribution_type: Type of contribution: 'Spoken', 'Written', 'Intervention', 'Question', 'Answer'.
        house: Optional: house - 1 or 'Commons', 2 or 'Lords'.
        start_date: Start date in YYYY-MM-DD format (optional).
        end_date: End date in YYYY-MM-DD format (optional).
        search_term: Search term (optional).
        member_id: Optional member ID to filter results.
        skip: Number of results to skip for pagination (default 0).
        take: Number of results to return (default 20).

    Returns:
        Contributions of the specified type.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`skip`	No
`take`	No
`house`	No
`end_date`	No
`member_id`	No
`start_date`	No
`search_term`	No
`contribution_type`	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

A3.8/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full disclosure burden. It does communicate that this is a read-style search returning contributions of a given type and exposes pagination defaults (skip=0, take=20), but it says nothing about result ordering, total counts, or permission/rate constraints.

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 purpose with a clean Args/Returns structure. Minor waste in the pipe-separated keyword list ("Hansard, spoken, written, interventions") and the Returns line restating the purpose, but overall tight and readable.

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-value detail is unnecessary, and all eight inputs are documented. The remaining gap is navigational: the description does not fully disambiguate this tool from the crowded set of other Hansard search endpoints.

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

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, yet the Args block documents all eight parameters: the contribution_type value set ('Spoken', 'Written', 'Intervention', 'Question', 'Answer'), house encoding (1/'Commons', 2/'Lords'), YYYY-MM-DD date format, and skip/take defaults. This fully compensates for the empty schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (search) plus resource (Hansard) and the discriminating dimension (contribution type), which is enough for an agent to understand the tool. It names two relatives (get_member_contribution_summary, get_debate_by_id), but does not differentiate itself from the many other search_hansard_* siblings (search_hansard, search_hansard_full, search_committee_debates), so differentiation is only partial.

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

Usage Guidelines3/5

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

"Use to find specific types of parliamentary contributions" implies a context, and two alternatives are named via "See also". But there is no explicit when-to-use/when-not guidance relative to the close siblings (e.g. search_hansard vs search_hansard_full), leaving the agent to infer routing.

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

Deploy Server