UK Parliament MCP Server

search_hansard

Search the official UK Parliament record to find speeches and debates on a topic, by a specific member, or within a date range.

Instructions

Search Hansard (official parliamentary record) for speeches and debates. Use when researching what was said in Parliament on specific topics, by specific members, or in specific time periods. House: 1 or "Commons", 2 or "Lords". See also: search_hansard_full, search_hansard_contributions, search_parliament.

    Args:
        house: House: 1 or 'Commons', 2 or 'Lords'.
        start_date: Start date in YYYY-MM-DD format.
        end_date: End date in YYYY-MM-DD format.
        search_term: Search term for speeches or debates (e.g. 'climate change', 'NHS').
        member_id: Optional member ID to filter results to a specific MP/Lord.
        skip: Number of results to skip for pagination (default 0).
        take: Number of results to return (default 20, max varies by endpoint).

    Returns:
        Hansard records matching the search criteria.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`skip`	No
`take`	No
`house`	Yes
`end_date`	Yes
`member_id`	No
`start_date`	Yes
`search_term`	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.2/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 burden. It conveys the pagination knobs (skip default 0, take default 20, 'max varies by endpoint') and a loose return statement, but never explicitly states this is a non-destructive read or describes rate/result limits, so behavioral disclosure is only partially complete for a search tool.

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, then usage, then Args, then Returns – a logical structure that scans well. It is slightly long with some redundancy (the house encoding is stated twice), but every block earns its place.

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?

With an output schema present, return values need not be re-explained, and the description adequately covers purpose, usage context, and every parameter. The only gap is the absence of explicit read-only/safety behavior for a mutation-free search tool, which is minor.

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%, so the description must compensate and does: it documents every parameter with meaning beyond the schema, including the house encoding ('1 or Commons, 2 or Lords'), the YYYY-MM-DD date format, what search_term matches, and the optional member_id filter, plus pagination defaults.

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?

States a specific verb and resource ('Search Hansard (official parliamentary record) for speeches and debates'), and immediately disambiguates from siblings with 'See also: search_hansard_full, search_hansard_contributions, search_parliament'. An agent can identify the tool's scope without opening any schema.

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?

Gives a clear when-to-use clause ('Use when researching what was said in Parliament on specific topics, by specific members, or in specific time periods') and names related alternatives. However, the 'See also' list does not explain the condition under which each alternative is preferred over this one, so routing remains partly inferential.

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

Deploy Server