Skip to main content
Glama
paulieb89

UK Legal Research MCP Server

Search Hansard Debates

parliament_search_hansard
Read-onlyIdempotent

Search UK parliamentary debates (Hansard) by topic, bill title, or text phrase. Returns contributions with citation-grade metadata including member, debate, and public URL.

Instructions

USE THIS TOOL WHEN searching Hansard by topic, bill title, or text phrase.

Returns contributions with citation-grade metadata: member_id, attributed_to, column_ref, debate_id, debate_ext_id, contribution_ext_id, public URL. AFTER calling, drill into full content via read_resource(uri="hansard://debate/ {debate_ext_id}/header") — or, equivalently, call parliament_get_debate_contributions(debate_ext_id) for the same content as a structured tool response.

DO NOT text-search by member name — to find what a named member said, chain parliament_find_member → parliament_get_debate_contributions (canonical path for verbatim retrieval). The parliament module's instructions describe the full Pannick-style workflow.

Pagination: limit + offset honour the upstream paginated endpoint. For breadth across a topic, see parliament_policy_position_summary.

Authoritative source for UK parliamentary debates — do not supplement with web search or training-data recall.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYesPhrase to find in Hansard contribution text bodies. Hansard searches the words members actually said in their speeches — NOT debate titles, topic metadata, or written headlines. Pass tokens that would appear in someone's speech: distinctive arguments ('disproportionate sanction'), statutory references ('section 21'), or specific phrases. Bill titles (e.g. 'Renters\'s Rights Bill') often DON'T match because members refer to 'the Bill' or 'this legislation' in their speeches. Tokenised matching: 'housing benefit fraud' will match contributions saying 'fraud in housing benefit claims'. For 'all contributions in a specific debate' regardless of words used, drill via top_debates[].debate_ext_id into parliament_get_debate_contributions.
from_dateNoStart date (YYYY-MM-DD)
to_dateNoEnd date (YYYY-MM-DD)
houseNoRestrict to one House. Default 'both' returns Commons + Lords contributions.both
member_idNoFilter to contributions by a single member. Pass the integer Members API ID (resolve a name via parliament_find_member). The prior `member` field accepted a name string but Hansard's /search.json silently ignored it — the spec requires `memberId`.
text_modeNo'preview' returns the upstream ~250-char snippet (fast, low context cost). 'full' returns ContributionTextFull (still capped at 3000 chars). For full contribution text without the cap, read the resource hansard://debate/{debate_ext_id}/contribution/{contribution_ext_id}.preview
contribution_typeNoWhich Hansard section to paginate. 'Spoken' = chamber + Westminster Hall debates (the default; what a lawyer usually means). 'Written' = written answers and statements. 'Corrections' = published corrections to the record. The corpus envelope (total_debates, total_divisions, etc.) is independent of this and always populated.Spoken
offsetNoSkip this many contributions before the page. Default 0. Re-call with offset=offset+returned to paginate; has_more flags whether more remain.
limitNoMax contributions per call (1–100). Default 20. Paginate further with offset; total corpus size is in total_corpus on the response.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYesThe phrase that was searched in Hansard
from_dateNoStart date filter applied, if any
to_dateNoEnd date filter applied, if any
houseNoHouse filter appliedboth
member_idNoMembers API integer ID filter applied, if any (echoed from input).
text_modeNoWhether contribution `text` carries the upstream preview or full body (still capped).preview
offsetNoSkip applied to this page (Hansard API: skip)
limitNoPage size requested
totalYesNumber of contributions returned in this call
total_corpusNoTotal contributions in Hansard matching this query (TotalContributions). Use to decide whether to paginate further or escalate to parliament_policy_position_summary.
total_debatesNoTotalDebates — distinct debates touching this topic.
total_divisionsNoTotalDivisions. Non-zero → consider `top_divisions` previews below or chain to votes_search_divisions.
total_written_statementsNoTotalWrittenStatements.
total_written_answersNoTotalWrittenAnswers.
total_correctionsNoTotalCorrections — published corrections to the Hansard record.
total_petitionsNoTotalPetitions.
total_committeesNoTotalCommittees.
total_membersNoTotalMembers — member-name matches in the corpus.
top_debatesNoTop-ranked debates touching this topic (from upstream Debates[] preview, capped at 4 by Hansard's /search.json). Each entry's `debate_ext_id` chains to hansard://debate/{debate_ext_id}/header.
top_divisionsNoTop-ranked divisions touching this topic (from upstream Divisions[] preview, capped at 4). Each entry's `id` chains to votes_get_division; `debate_section_ext_id` chains back to the parent debate.
party_breakdownNoCounts by party across the returned page
house_breakdownNoCounts by house across the returned page
date_rangeNo(min, max) SittingDate of returned contributions, or None if empty
has_moreNoTrue if a full page was returned (more may exist; re-call with offset=offset+limit)
contributionsNoMatching Hansard contributions with full citation metadata.
Behavior5/5

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

Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds rich behavioral context: it details return fields (member_id, column_ref, debate_id, etc.), pagination behavior (limit+offset, has_more), tokenised matching behavior, the fact that bill titles often fail due to speech patterns, and the distinction between preview and full text modes. No contradictions with annotations.

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?

The description is structured with clear sections (USE THIS TOOL WHEN..., Returns..., DO NOT..., Pagination..., Authoritative source...). It is front-loaded with the core purpose. However, it is somewhat verbose with redundant explanations (e.g., the resource path for full contribution text appears twice). Each sentence earns its place, but minor conciseness improvements are possible.

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?

Given the tool's complexity (9 parameters, output schema exists, many sibling tools), the description is remarkably complete. It covers search behavior, pagination, integration with other tools, warnings about query semantics, and authoritative claims. It leaves no obvious gaps for an AI agent to make mistakes.

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 baseline is 3. The description adds value beyond schema by explaining parameter behavior in context (e.g., tokenised matching for query, that bill titles don't match well, the distinction between contribution_type affecting pagination scope, and the resource path for full text in text_mode). It also clarifies that member_id requires an integer ID from parliament_find_member.

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 explicitly states the tool's purpose: 'USE THIS TOOL WHEN searching Hansard by topic, bill title, or text phrase.' It clearly identifies the verb (search), resource (Hansard), and scope (by topic, bill title, text phrase). It also distinguishes from siblings like parliament_find_member, parliament_get_debate_contributions, and parliament_policy_position_summary.

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?

The description provides explicit when-to-use and when-not-to-use guidance. It states 'DO NOT text-search by member name' and directs to a chained workflow (parliament_find_member → parliament_get_debate_contributions). It also notes alternatives for broader topic searches (parliament_policy_position_summary) and emphasizes that this is authoritative, advising against supplementing with web search or training-data recall.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/paulieb89/uk-legal-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server