Skip to main content
Glama
ChrisBrooksbank

UK Parliament MCP Server

by ChrisBrooksbank
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

search_hansard_petitions

Search Hansard petitions by house, date, or keyword to find those presented in Parliament. Returns matching records with pagination.

Instructions

Search petitions in Hansard | Hansard, petitions, parliamentary petitions | Use to find petitions presented in Parliament | Returns petitions matching the search criteria

    Args:
        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).
        skip: Number of results to skip for pagination (default 0).
        take: Number of results to return (default 20).

    Returns:
        Petitions matching the search criteria.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
skipNo
takeNo
houseNo
end_dateNo
start_dateNo
search_termNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.2/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden. It implies a read-only search and mentions pagination via skip/take defaults, but says nothing about auth requirements, rate limits, result ordering, or how house/date filters interact. For a zero-annotation tool this is thin.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

The Args block is well-structured, but the header repeats itself ('Returns petitions matching the search criteria' appears both in the first line and the Returns section) and the keyword-style tag list 'Hansard, petitions, parliamentary petitions' is redundant filler rather than information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 6 optional params and an output schema present, return values needn't be explained, and the Args section covers all parameters. The gap is the absence of any differentiation from the many sibling petition/Hansard search tools, which is the main thing an agent needs to route correctly.

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 description coverage is 0%, so the description must compensate, and it largely does: it documents the house value mapping (1 or 'Commons', 2 or 'Lords'), the YYYY-MM-DD date format, and the skip/take defaults. This adds real meaning the bare schema lacks, though it doesn't explain filtering interaction or search_term matching semantics.

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+resource ('Search petitions in Hansard') and clarifies scope as 'petitions presented in Parliament', so an agent knows what it returns. However, it does not distinguish itself from close siblings like search_bill_petitions or get_bill_petition_by_id, which an agent could easily confuse with this one.

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 petitions presented in Parliament' implies the usage context but gives no explicit when/when-not, no prerequisites, and no routing to alternative petition tools. The pipe-delimited keyword list adds no selection guidance.

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

Deploy Server

Other Tools