Point-in-time amendment history for 506 UK legislation provisions.
Scored across 4 tools
The four tools are generally distinct: search finds provisions by keyword, history drills into one provision, and the two list tools are separated by recency vs. frequency. There is slight potential for confusion between get_most_amended and get_recent_amendments, but their ordering criteria are clearly stated.
All tool names use lowercase snake_case and mostly follow a get_/search_ verb-first pattern. Minor inconsistency comes from get_most_amended being an adjective/past-participle rather than a noun object, but the pattern is still predictable.
Four tools is a well-scoped size for a legislation-change tracking server. Each tool covers a distinct core query: search, history, recent changes, and high-churn provisions, with no redundant tools.
The set covers the main change-tracking workflows: keyword discovery, detailed point-in-time history, recent amendments, and high-churn provisions. A minor gap is the lack of a way to filter recent amendments by legal area or date range, but agents can work around this via search and history.
List the provisions that have changed most often — the least stable areas of UK law.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It conveys that results are ordered by frequency of change but does not disclose the time scope, whether the full history is counted, result formatting, or pagination behavior. This is a meaningful gap for a no-annotation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence expresses both the core action and the intuitive intent ('least stable areas') with zero wasted words. The structure is clean and immediately scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple single-parameter list tool with no output schema, so the description covers the essential purpose. However, it omits any guidance about result ordering details, scope, or distinctions from sibling tools, leaving the tool adequate but not fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 100%, the limit parameter is already fully documented. The description adds no further semantics to the parameter, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource, 'List provisions that have changed most often', and adds the clarifying gloss 'least stable areas of UK law'. This makes the distinct focus on amendment frequency unambiguous and clearly differentiates it from the sibling tools get_recent_amendments, get_provision_history, and search_uk_legislation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The use case is implied – to find unstable areas of UK law – but the description gives no explicit guidance on when to prefer this over get_recent_amendments or get_provision_history. There are no exclusions or alternative selection criteria, leaving the agent to infer when this tool is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full point-in-time amendment history for one provision: every version boundary date and what changed at each.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Provision id, e.g. 'ukpga/1996/18/section/94' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does a good job: it tells the agent the getter returns complete point-in-time history, including version boundaries and per-change details. It doesn't state read-only explicitly or mention failure modes, but 'Get' plus the returned contents makes the behavior clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the action and scope. The result content follows immediately. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read tool, the description plus schema is almost complete: it states exactly what history is returned unique to one provision. It doesn't mention ordering or boundaries, but those are not likely critical for invoking correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%; the schema already describes the provision id with an example. The phrase 'for one provision' reinforces id's role but adds no new syntax or semantics. Baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: retrieving the full point-in-time amendment history for one provision. The phrase 'for one provision' clearly distinguishes it from siblings that search or return recent/most-amended provisions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly scopes the tool to a single provision, providing clear context for when it is appropriate. It doesn't explicitly name alternatives or exclusion conditions, so it doesn't reach the 5-level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the most recent amendments across all tracked UK provisions. Useful for answering 'what changed in UK employment law recently?'
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 50) | |
| since | No | ISO date, e.g. '2026-01-01' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It signals a safe list operation via 'List' and the read-only nature, but does not mention pagination, side effects, auth requirements, or what 'tracked' means. It is adequate but does not go beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words; the primary action is stated first, and the example query is a short useful illustration. It is easy to scan and directly informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read tool with full schema coverage, the description is mostly complete. However, there is no output schema and the description does not indicate the result shape or ordering guarantee beyond 'most recent', so the agent still has some leftover ambiguity about what will be returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers both parameters at 100% with clear descriptions, so the baseline is 3. The description does not add depth about how 'since' filters or how 'limit' behaves beyond what the schema already states, so it neither deducts nor enhances.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('List') and precise scope ('most recent amendments across all tracked UK provisions'). It also gives an example user question, making the tool's purpose immediately clear and distinguishable from siblings like get_most_amended or get_provision_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tool is tied to a concrete use case ('what changed in UK employment law recently?'), which gives clear context. It does not explicitly mention siblings or when not to use it, but the all-provisions scope is sufficiently explicit for an agent to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search UK legislation provisions (employment, equality, consumer, data protection, company, health & safety law) by keyword. Returns provisions with their amendment history.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 20) | |
| query | Yes | Keywords, e.g. 'unfair dismissal' or 'disability' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations provided, so the description carries the full burden of behavioral disclosure. It mentions that results include amendment history, which is useful, but it does not clarify important behaviors such as jurisdiction scope (UK vs. specific nations), search semantics (exact vs. fuzzy), or whether the tool is an expensive/complex operation. The lack of annotation coverage and minimal behavioral detail leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two sentences that pack the core purpose and key output (amendment history). The key verb and resource are front-loaded, and there is no wasted fluff. It is well-structured for quick parsing by an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (legal search), the absence of an output schema and annotations places more burden on the description. It does not explain result structure, pagination (though limit param hints at it), or edge cases like no results or jurisdiction limits. The description is too sparse to fully enable correct invocation in varied contexts, especially since sibling tools deal with amendments and could lead to misuse.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage of both parameters with examples ('unfair dismissal' or 'disability'), so the baseline is 3. The description adds the context that queries are for legal areas, but it does not add syntax details, advanced query options, or constraints beyond what the schema states. Thus, it barely adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches UK legislation provisions by keyword and specifies several legal areas (employment, equality, etc.). It also mentions that it returns provisions with amendment history. However, it does not explicitly distinguish itself from sibling tools that deal with amendments, such as get_provision_history or get_recent_amendments, so some ambiguity remains about the unique scope of this tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly suggests it is for keyword-based searches, but it provides no explicit when-to-use or when-not-to-use guidance. Since siblings handle amendment history, an agent might wonder whether to use this tool for amendment-specific queries or those siblings. There is no mention of alternatives or exclusions, leaving usage context somewhat vague.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_most_amendedget_provision_historyget_recent_amendmentssearch_uk_legislationUK legal research — case law, legislation, Hansard, bills, votes, committees, HMRC, citations
legislation.gov.uk MCP — the UK's official legislation database.
Verified EU law: verbatim, signed provisions with EUR-Lex links. Read-only, not legal advice.
Search UK Acts, Statutory Instruments, and legislation with full text retrieval
Add one secure layer between your agents and this server.
