UK Business Tools - Ledgerhall

Search Hansard Debates

law_parliament_search_hansard

Read-onlyIdempotent

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

Name	Required	Description	Default
`house`	No	Restrict to one House. Default 'both' returns Commons + Lords contributions.	both
`limit`	No	Max contributions per call (1–100). Default 20. Paginate further with offset; total corpus size is in total_corpus on the response.
`query`	Yes	Phrase 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.
`offset`	No	Skip this many contributions before the page. Default 0. Re-call with offset=offset+returned to paginate; has_more flags whether more remain.
`to_date`	No	End date (YYYY-MM-DD)
`from_date`	No	Start date (YYYY-MM-DD)
`member_id`	No	Filter 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_mode`	No	'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_type`	No	Which 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

Output Schema

TableJSON Schema

Name	Required	Description	Default
`house`	No	House filter applied	both
`limit`	No	Page size requested
`query`	Yes	The phrase that was searched in Hansard
`total`	Yes	Number of contributions returned in this call
`offset`	No	Skip applied to this page (Hansard API: skip)
`to_date`	No	End date filter applied, if any
`has_more`	No	True if a full page was returned (more may exist; re-call with offset=offset+limit)
`from_date`	No	Start date filter applied, if any
`member_id`	No	Members API integer ID filter applied, if any (echoed from input).
`text_mode`	No	Whether contribution `text` carries the upstream preview or full body (still capped).	preview
`date_range`	No	(min, max) SittingDate of returned contributions, or None if empty
`top_debates`	No	Top-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.
`total_corpus`	No	Total contributions in Hansard matching this query (TotalContributions). Use to decide whether to paginate further or escalate to parliament_policy_position_summary.
`contributions`	No	Matching Hansard contributions with full citation metadata.
`top_divisions`	No	Top-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.
`total_debates`	No	TotalDebates — distinct debates touching this topic.
`total_members`	No	TotalMembers — member-name matches in the corpus.
`house_breakdown`	No	Counts by house across the returned page
`party_breakdown`	No	Counts by party across the returned page
`total_divisions`	No	TotalDivisions. Non-zero → consider `top_divisions` previews below or chain to votes_search_divisions.
`total_petitions`	No	TotalPetitions.
`total_committees`	No	TotalCommittees.
`total_corrections`	No	TotalCorrections — published corrections to the Hansard record.
`total_written_answers`	No	TotalWrittenAnswers.
`total_written_statements`	No	TotalWrittenStatements.

TDQS

A4.7/5.0

Behavior5/5

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

Despite annotations already indicating read-only, idempotent, and non-destructive behavior, the description adds substantial behavioral detail: tokenised matching based on speech text (not titles), bill titles often failing to match, upstream pagination behavior, the member_id parameter replacing a silently ignored name field, and drill-down paths to read_resource or parliament_get_debate_contributions. No contradiction 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear labels (USE THIS TOOL WHEN, AFTER calling, DO NOT, Pagination) and every sentence earns its place. It is longer but appropriately so given the complexity of the tool and the need to convey usage nuances, follow-up actions, and exclusions.

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 9 parameters, an output schema, and rich annotations, the description is complete. It covers when to use, when not to use, how to chain with other tools, pagination details, and post-call drill-down options. The output schema and description together provide sufficient context for an agent to select and invoke the tool correctly.

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

Parameters3/5

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

The input schema has 100% parameter description coverage, so the baseline is 3. The main description adds no new parameter semantics beyond the schema; it merely reinforces pagination behavior and suggests an alternative tool for topic breadth. The schema itself provides rich context for query, member_id, text_mode, and contribution_type.

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 clearly states the tool searches Hansard by topic, bill title, or text phrase and returns contributions with citation-grade metadata. It distinguishes itself from sibling tools like parliament_get_debate_contributions and parliament_policy_position_summary, and explicitly warns against using it for member-name searches.

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 opens with 'USE THIS TOOL WHEN' and provides explicit DO NOT guidance for member-name searches, pointing to a canonical alternative chain (parliament_find_member → parliament_get_debate_contributions). It also directs to parliament_policy_position_summary for breadth and advises 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.

All UK Business Tools - Ledgerhall tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0

Disambiguation4/5

Tools are well-grouped by domain prefixes (dd_, gov_, law_, prop_) with clear descriptions that differentiate them. However, there is minor overlap, e.g., dd_search could be used instead of individual searches, and dd_fetch versus dedicated profile tools might cause confusion.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern with domain-specific prefixes (dd_, gov_, law_, prop_). Names are descriptive and predictable, e.g., dd_charity_search, gov_govuk_search, law_bills_search_bills.

Tool Count4/5

70 tools is high but justified by the broad scope covering due diligence, government, legal, and property domains. Each domain has a reasonable number of tools (about 15-20 each). The count is on the upper end but still manageable.

Completeness5/5

The tool set is comprehensive across all domains: full CRUD for companies and charities, detailed legal research (cases, legislation, parliament, citations), property data (EPC, planning, price paid, rentals), and government information. No obvious gaps for the intended use cases.

Resources

Need Help?