uk-legislation-mcp-server
Server Details
Search and read UK legislation at any date, resolve citations, list amendments, track changes.
- Status
- Healthy
- Uptime
- 99.9% over 20 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- Repository
- cyanheads/uk-legislation-mcp-server
- GitHub Stars
- 2
- Server Listing
- uk-legislation-mcp-server
TDQS
Scored across 6 tools
Each tool has a distinct role: search vs citation lookup vs document read vs amendment list vs publication log vs offline vocabulary reference. The only mild overlap is between uklaw_get_document (which also surfaces annotations and unapplied effects) and uklaw_get_amendments, but the descriptions explicitly delineate when to use each, so misselection risk is low.
All six tools use a uniform uklaw_ prefix followed by a consistent verb_noun snake_case pattern (get_amendments, get_document, list_reference, lookup_citation, search_legislation, track_changes). Verb choices are distinct and predictable.
Six tools is well-scoped for a read-only legislation server: each covers a distinct stage of the workflow (search, resolve, read, amendments, change monitoring, vocabulary decoding) with no redundant entries. The set is neither thin nor bloated.
The surface covers the full read-only lifecycle: discovery (search/lookup), retrieval (document at item and provision level, current/enacted/as-of), change tracking (amendments and publication log), and vocabulary decoding. Minor gaps exist — no bulk/structured export or multi-item batch retrieval — but the core research workflow has no dead ends.
Available Tools
6 toolsuklaw_get_amendmentsList amendments to or by legislationARead-onlyIdempotentInspect
List the effects — amendments, repeals, revocations, commencements, modifications — recorded against an item (direction affected) or made by an item (direction affecting), from legislation.gov.uk's changes feeds. Filter by the other item (counterpart), by applied status (unapplied = the outstanding work on the revised text), and by provision. item may be partial (ukpga/2018 = all effects on 2018 Acts). Each effect names both sides with provision links, in-force dates, and why it is not applied. For the applied history of one provision in prose, read its annotations with uklaw_get_document.
| Name | Required | Description | Default |
|---|---|---|---|
| item | Yes | Item path or legislation.gov.uk URI (ukpga/2018/12), or a partial path: a type (uksi) or type and year (ukpga/2018). Get a full path from uklaw_lookup_citation or uklaw_search_legislation. A pre-1963 Act takes its calendar year (ukpga/1925/20, not ukpga/Geo5/15-16/20); its effects name the regnal path, and two sessions in one year can share a number. Drafts (ukdsi, sdsi, nidsr) are not in the changes feeds. | |
| limit | No | Effects per page, or with provision the most matches returned (1–100, default 20). | |
| cursor | No | next_cursor from the previous call, passed with the other inputs unchanged; omit for the first page. | |
| status | No | unapplied: effects not yet applied to the revised text; applied: already applied; all: both. | all |
| direction | No | affected: changes made to item. affecting: changes item makes to other legislation. | affected |
| provision | No | Keep only effects touching this provision of item (path or shorthand, e.g. section/45 or s. 45), including effects on the whole item. Needs a full item path. legislation.gov.uk cannot filter by provision, so each call scans up to 1,500 effects; continue with next_cursor. | |
| counterpart | No | Restrict to effects involving this other item (full or partial item path, without a provision, e.g. uksi/2019/419 or uksi/2026) — the amending item for direction affected, the amended item for affecting. A pre-1963 Act takes its calendar year, not its regnal path; drafts are not in the changes feeds. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | No | The limit applied. |
| scan | No | Coverage of this call; present only when filtering by provision. |
| error | No | Present when the call failed. Absent on success. |
| query | No | The query as normalized. |
| shown | No | Effects returned. |
| total | No | Total effects legislation.gov.uk holds for this query (before any provision filter). |
| notice | No | Guidance when nothing matched or the list continues. |
| effects | No | Effects on this page, most recently modified first; empty when none matched. |
| has_more | No | True when more effects remain — call again with next_cursor. |
| truncated | No | True when the list was capped at limit. |
| attribution | No | Attribution lines the returned content requires (OGL always; EU and Westlaw credits when applicable). |
| next_cursor | No | Pass as cursor to continue; present only when has_more is true. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent/openWorld annotations it discloses real behavioral costs: legislation.gov.uk cannot filter by provision, so each provision call scans up to 1,500 effects, and cursor paging is required. It also names the response contents (both sides, provision links, in-force dates, non-application reasons) and the pre-1963 calendar-vs-regnal path pitfall — exactly the context annotations cannot carry.
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?
Purpose is front-loaded in the opening clause and every clause carries information (filters, partial paths, output content, the get_document escape hatch). The em-dash enumeration and the dense first sentence cost a little readability, but there is 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?
Output schema exists, so return shape needs no explanation, yet the description still tells the agent what an effect record contains and why it may not be applied. Pagination, expensive-filter behavior, draft exclusion and date-path caveats are all covered for a 7-parameter tool.
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 description coverage is 100%, so the baseline is 3. The prose largely restates the schema's own definitions of direction, status, counterpart and partial item paths rather than adding new syntax or format detail, so it does not earn above baseline despite being readable.
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?
Specific verb ('List') plus a precisely scoped resource: effects (amendments, repeals, revocations, commencements, modifications) recorded against or made by an item. It explicitly separates the two directions and names the sibling (uklaw_get_document) for the prose-history case, so an agent can distinguish it from neighbours 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear conditional alternative: 'For the applied history of one provision in prose, read its annotations with uklaw_get_document.' It also flags the partial-item shortcut and that drafts are absent from the feeds. It does not, however, contrast with uklaw_track_changes or state hard when-not cases beyond that single routing hint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
uklaw_get_documentRead UK legislation textARead-onlyIdempotentInspect
Read one item or one provision of UK legislation from legislation.gov.uk — as it stands now (revised), as enacted/made, or as it stood on a date — in Markdown, with its editorial status, annotations (the applied amendment history), the unapplied effects touching it, the versions available, and attribution. Provision-level reads are the main path; an item-level read returns the whole text only for small items and otherwise an outline of provision paths to read next. With match_text (item level), returns the provisions whose text matches. Revised text is an editorial consolidation that can lag: read editorial.caveat and unapplied_effects before relying on it, and use uklaw_get_amendments for every recorded effect on an item, applied or not.
| Name | Required | Description | Default |
|---|---|---|---|
| item | Yes | Item path {type}/{year}/{number} — ukpga/2018/12, uksi/2019/419, eur/2016/679, ukpga/Eliz2/3-4/19 — or any legislation.gov.uk URI (a URI carrying a provision, version, or /welsh is split into those parts; a version or /welsh in the URI applies unless the version or language input is set). Get it from uklaw_lookup_citation or uklaw_search_legislation. A path legislation.gov.uk serves at another path — a pre-1963 Act by calendar year (ukpga/1925/20 is ukpga/Geo5/15-16/20), a Welsh SI as uksi — is read there, and item.path reports the served path, with a notice. | |
| version | No | current (the latest revised text, or the original text for an item never revised), enacted (made, adopted and created are synonyms — the original text), or a date YYYY-MM-DD for the text as it stood then. Omitted: the version in an item URI, else current. A future date returns the latest version; a date before the earliest revised version (1991-02-01 for most primary legislation, 2006-01-01 for Northern Ireland) returns that version, with a notice; and a date on or after the made or enactment date of an item never revised returns its original text, with a notice. version.applied reports the version served. | |
| language | No | en, or cy for the Welsh text of Welsh legislation (asc, anaw, mwa, wsi). Omitted: cy when an item URI ends in /welsh, else en. English is returned, with a notice, when no Welsh text exists. | |
| provision | No | Provision path — section/45/2/f, regulation/5, article/28/3, schedule/2/paragraph/3, part/3/chapter/2, introduction — or citation shorthand (s. 45(2)(f), reg. 5, art. 28(3), Sch. 2 para. 3), normalized before the request. Omit to read the item; an item-level outline lists the paths. | |
| match_text | No | Item level only (omit provision): return the outline of provisions whose text contains this term, e.g. "processor" — 100 entries per call; outline_offset reaches the rest. | |
| outline_offset | No | Where a returned outline starts: 0 lists entries 1–100, 100 the next 100. Applies only when kind is outline (ignored when text is returned); a notice names the next offset while entries remain. |
Output Schema
| Name | Required | Description |
|---|---|---|
| item | No | The item read. |
| kind | No | full: text returned; outline: a list of provisions to read instead; pdf_only: the item is held as PDF only (see links.pdf). |
| text | No | The text as Markdown, present when kind is full; amendments are wrapped as [F1 …] keyed to annotations. A provision with no smaller child provisions that renders over 40,000 characters, counting its annotations, is cut to 40,000, and a notice gives its full size and the links to the full text. |
| error | No | Present when the call failed. Absent on success. |
| links | No | Links to the document. |
| notice | No | Notices: the path an item input is served at, Welsh fallback, original text served for a dated read, a later version served for a date before the earliest revised version, an omitted provision window, the unapplied effects an item outline or an outlined provision leaves out, unapplied effects on enclosing or contained provisions that could not be checked, how many effects of a multi-page unapplied changes feed were checked, truncated lists, an outline window with the outline_offset that continues it, an oversized provision with no smaller child provisions returned whole or cut (its full size, and the links to the full text), and how to continue. |
| outline | No | Provisions to read next, present when kind is outline: up to 100 entries from outline_offset; empty when outline_offset is past the end. |
| version | No | Version requested and served. |
| language | No | Language actually served (en or cy). |
| editorial | No | Editorial status — read before relying on revised text. |
| provision | No | The provision read — present for provision-level reads. |
| annotations | No | Annotations referenced by the text, present when kind is full — the applied amendment history of the version served. When the text is cut, only those the kept text references. |
| attribution | No | Attribution lines the returned content requires (OGL always; EU and Westlaw credits when applicable). |
| outline_notice | No | How to read a provision from the outline, naming one to start with; past the outline’s end, its entry count. |
| unapplied_effects | No | Recorded effects not yet applied to the revised text that touch this provision — whole-item effects, those on an element enclosing it (Part, Chapter, cross-heading), and when kind is full those on a provision inside it — or at item level the item’s: the first 20, outstanding first, with a notice when more exist; empty when none. An outlined provision does not list the effects inside it; a notice counts them. Absent on an item-level outline, where a notice gives the item’s count. uklaw_get_amendments with the item (for a pre-1963 Act, its calendar-year path, as the notices name it) and status "unapplied", without provision, lists them all. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, open-world behavior. The description adds substantial context beyond annotations: editorial status, applied amendment history, unapplied effects, available versions, attribution, caveats about revised text lagging, and the fallback behavior for dates outside revised coverage.
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 front-loaded with purpose and then layers in usage guidelines and caveats without wasted words. It is dense and information-rich, though the long opening sentence and several sub-clauses make it slightly harder to scan than ideal.
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?
With an output schema present and rich annotations, the description still covers the key behavioral nuances an agent needs: the primary read path, item-level fallback behavior, version semantics, caveats about revised text, and the existence of a sibling tool for amendments. Nothing essential is missing.
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%, so the schema already documents all six parameters in detail. The description does not add syntax or format details beyond what the schema provides; its parameter-related notes (e.g., match_text at item level, version behavior) largely restate schema content. 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 states a specific verb (Read) and resource (UK legislation item or provision) with its scope and formats. It explicitly distinguishes provision-level reads as the main path versus item-level reads as an outline for larger items, and names uklaw_get_amendments as the sibling for amendment 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?
It gives explicit when-to-use guidance: provision-level reads are primary, item-level reads return whole text only for small items and otherwise an outline, and match_text is item-level only. It also directs agents to read editorial.caveat and unapplied_effects before relying on revised text, and to use uklaw_get_amendments for every recorded effect.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
uklaw_list_referenceList legislation reference vocabularyARead-onlyIdempotentInspect
Decode the vocabulary the other uklaw_* tools take and return: legislation type codes (ukpga, uksi, eur, …) with their labels, categories and enacted keywords; type groups; extents; version keywords; document status; annotation letters (F, C, I, M, E, P, X); effect record fields; provision path forms and shorthand; accepted citation formats; Publication Log vocabulary and read modes; data coverage; and the attribution lines. Offline — no request to legislation.gov.uk.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | Which table to return: types, type_groups, extents, versions, document_status, annotation_types, effects, provision_paths, citation_formats, publication_log, coverage, or attribution. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| topic | No | The topic returned. |
| entries | No | Reference entries for the topic. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context by confirming the operation is offline with no network request to legislation.gov.uk, reinforcing the openWorld hint. It does not discuss output size or caching, but with an output schema present that omission is minor.
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 content is front-loaded with the core purpose ('decode the vocabulary') and then a dense, information-bearing enumeration of covered tables. It is a single long sentence, but every clause maps to a distinct table the caller can request, so little is wasted.
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?
With one enum parameter, full schema coverage, an output schema, and clear read-only/idempotent/offline annotations, the description covers everything an agent needs. It comprehensively enumerates the returnable tables and confirms the offline nature, leaving no material gap for a reference-lookup tool.
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% and the single enum parameter is fully documented in the schema, which sets a baseline of 3. The description earns above baseline by expanding each enum value into concrete content, e.g. naming the annotation letters (F, C, I, M, E, P, X) and clarifying that 'types' returns labels, categories, and enacted keywords.
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 (decode/list) and resource (the reference vocabulary that other uklaw_* tools consume and produce), and enumerates exactly which tables it exposes. An agent can immediately tell this apart from siblings like uk law_search_legislation or uklaw_get_document, which perform lookups rather than return the shared vocabulary.
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 framing 'Decode the vocabulary the other uklaw_* tools take and return' strongly implies the usage context: consult this before or alongside the other tools to interpret codes. The 'Offline — no request to legislation.gov.uk' note tells the agent it is a local reference call. However, it never states explicit when-not conditions or names a sibling alternative, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
uklaw_lookup_citationResolve a legislation citationARead-onlyIdempotentInspect
Resolve a citation or short title to the canonical legislation.gov.uk item and provision: "Data Protection Act 2018 s. 45", "2018 c. 12", "S.I. 2019/419", "S.S.I. 2020/123", "S.R. 2020/12", "2020 asp 13", "Regulation (EU) 2016/679 art. 28", a legislation.gov.uk URI, or a short title. Returns the item path to pass to uklaw_get_document, and when a provision is given, whether it exists in the current version. A miss or an ambiguous title is a result with found false plus guidance or candidates, not an error. To find legislation by topic or by partial title words rather than a known citation, use uklaw_search_legislation.
| Name | Required | Description | Default |
|---|---|---|---|
| citation | Yes | A citation ("2018 c. 12", "S.I. 2019/419 reg. 5", "Regulation (EU) 2016/679 art. 28"), a short title ("Data Protection Act 2018 s. 45(2)(f)"), or a legislation.gov.uk URI. uklaw_list_reference topic citation_formats lists the accepted forms. |
Output Schema
| Name | Required | Description |
|---|---|---|
| item | No | Canonical item path, e.g. ukpga/2018/12 — pass to uklaw_get_document; present when found. |
| type | No | Canonical type code (a Welsh SI cited as uksi comes back as wsi); present when found. |
| year | No | Calendar year of the item; absent when not known, e.g. a regnal-year item resolved from its path. |
| error | No | Present when the call failed. Absent on success. |
| found | No | True when the citation resolved to exactly one item. |
| title | No | Item title; absent when it could not be fetched within the call. |
| id_uri | No | Canonical identifier URI of the item; present when found. |
| number | No | Item number within the year; present when found. |
| parsed | No | The citation as the parser read it. |
| guidance | No | What to do next after a miss, ambiguity, or a check that could not run. |
| title_cy | No | Welsh title, for bilingual items. |
| made_date | No | Date enacted or made (YYYY-MM-DD); absent when not fetched or not reported. |
| candidates | No | Candidate items (at most 20) when the citation is ambiguous. |
| type_label | No | Human label of the type; present when found. |
| attribution | No | Attribution lines the returned content requires (OGL always; EU and Westlaw credits when applicable). |
| document_uri | No | legislation.gov.uk page for the item; present when found. |
| provision_uri | No | Identifier URI of that provision, alongside provision_path. |
| provision_path | No | Provision path the citation named, when it named one and the item was found. |
| provision_found | No | Whether the provision exists in the current version; absent when the check could not run. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent/openWorld annotations, it discloses the failure contract that an agent most needs: a miss or ambiguous title returns a result with found=false plus guidance or candidates rather than an error, and provision lookups report whether the provision exists in the current version. This is genuine behavioral information not inferable from the structured fields.
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?
Front-loaded with the action and the accepted formats, then the return value, then the error semantics, then the routing alternative — a sensible order. The example list is long, but each example covers a distinct citation family rather than being 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 single-parameter, read-only public lookup with an output schema, the description supplies the accepted input grammar, the return shape (item path plus provision existence), the non-error failure behavior, and the sibling alternative. Nothing material is missing.
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 already 100% and the parameter is documented there, so the baseline is 3, but the description adds accepted citation families beyond the schema examples (S.S.I., S.R., asp) and cross-references uklaw_list_reference topic citation_formats for the full grammar.
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 opens with a specific verb and resource ("Resolve a citation or short title to the canonical legislation.gov.uk item and provision") and enumerates the exact input forms it accepts. It is clearly distinguishable from the sibling uklaw_search_legislation, which is named as the topic-based alternative.
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?
It states both the when-to-use condition (you already have a citation, short title, or URI) and the when-not-to-use condition ("To find legislation by topic or by partial title words rather than a known citation, use uklaw_search_legislation"). It also names the downstream step, passing the returned item path to uklaw_get_document.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
uklaw_search_legislationSearch UK legislationARead-onlyIdempotentInspect
Search the UK statute book on legislation.gov.uk by full text or title, or list legislation by type and year, filtered by geographical extent and point in time. Full-text search ranks by relevance; title searches and type/year listings run newest year first and carry type and year counts (facets) to narrow with. Each result gives the item path to pass to uklaw_get_document. For a known citation or short title, uklaw_lookup_citation is cheaper and exact.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (1–10,000). | |
| text | No | Full-text query. Supports AND/OR, "quoted phrases", and stemming. Omit for a title search or a listing. | |
| year | No | Calendar year (also for pre-1963 Acts numbered by regnal year). Not combinable with year_from/year_to. | |
| as_of | No | Point in time YYYY-MM-DD: only legislation as it stood on that date (items not yet enacted or made are excluded). Omit for current law. Cannot combine with extent. | |
| limit | No | Results per page (1–50). | |
| title | No | Words that must all occur in the title. For a known short title or citation, uklaw_lookup_citation is exact. | |
| types | No | Type codes (ukpga, uksi, asp, eur, …) and/or groups (all, primary, secondary, eu-origin, draft). "all" covers UK and EU-origin legislation, excluding drafts, and absorbs any other value. uklaw_list_reference topic types lists the codes. | |
| extent | No | Geographical extent: england, wales, scotland, ni. An item matches when one of its provisions extends there. Cannot combine with as_of. legislation.gov.uk has not recorded provision-level extent for many recent items, so an empty result does not prove nothing extends there. | |
| year_to | No | Latest calendar year of a range; the other bound may be omitted. | |
| year_from | No | Earliest calendar year of a range; the other bound may be omitted. | |
| extent_match | No | Used only with extent. applicable: a provision extends to any given extent; exact: a provision extends to exactly that set. | applicable |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | No | Page size that capped the list. |
| page | No | Page returned. |
| error | No | Present when the call failed. Absent on success. |
| limit | No | Page size applied. |
| scope | No | The scope applied, defaults included. |
| shown | No | Results on this page. |
| total | No | Total matches; present only when legislation.gov.uk reports it (often absent on large result sets). |
| facets | No | Type and year counts — title searches and listings only; absent on full-text searches and on a page past the last page. |
| notice | No | Guidance when nothing matched, or how to fetch the next page. |
| results | No | Matching items on this page. |
| has_more | No | True when a further page exists (call again with page + 1). |
| truncated | No | True when more results exist beyond this page. |
| attribution | No | Attribution lines the returned content requires (OGL always; EU and Westlaw credits when applicable). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/openWorld/idempotent, so the safety profile is covered. The description adds real behavioral context beyond that: full-text ranks by relevance, title and type/year listings are newest-year-first and carry type/year facet counts, and each result supplies a path for chaining. It omits rate limits, error/empty-result behavior, and page-traversal cost, which keeps it short of a 5.
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?
Four sentences, all load-bearing: mode description, ranking/ordering and facet behavior, result chaining, and sibling routing. Mode and scope are front-loaded, and there is no filler or restatement of the title.
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?
With an output schema present, the description needn't explain return values, and it still adds the useful fact that each result carries the path for uklaw_get_document. For an 11-parameter, zero-required search tool whose schema is fully documented, nothing an agent needs to call it correctly is missing.
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 description coverage is 100% and the schema already spells out text syntax, as_of semantics, type codes, extent caveats, and mutual exclusions (as_of vs extent, year vs year_from/to). The description only restates the filter categories at a high level ('filtered by geographical extent and point in time'), so the schema is doing essentially all of the parameter work — the 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?
The description names a specific verb (search/list) and resource (UK statute book on legislation.gov.uk), and explicitly distinguishes three modes: full-text search, title search, and type/year listing. It also names the sibling tools it hands off to (uklaw_get_document for the result path, uklaw_lookup_citation for known citations), so an agent can place it precisely among siblings.
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?
It gives explicit routing guidance: use full text for discovery, title/type/year for enumeration, and 'For a known citation or short title, uklaw_lookup_citation is cheaper and exact.' That is a clear when-to-use-this vs when-to-use-alternative statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
uklaw_track_changesTrack legislation.gov.uk publicationsARead-onlyIdempotentInspect
Read the legislation.gov.uk Publication Log for a date window of up to 31 days: new items, new revised versions, newly recorded effects, and withdrawals, newest first — the compliance-monitoring view of "what changed". Filter by content type, effect direction, category, an item or type/year, first-time items only, or event. With a full item path it reads that item's own log, usually in one call; otherwise it walks the window day by day, newest first, so a broad window may need several calls. A changes event carries no effect detail — uklaw_get_amendments with that item has it. Continue with next_cursor.
| Name | Required | Description | Default |
|---|---|---|---|
| item | No | A full item path (ukpga/2018/12) or legislation.gov.uk URI reads that item's own log; a type (uksi) or type and year (uksi/2026) narrows the day walk. Get a full path from uklaw_lookup_citation or uklaw_search_legislation. | |
| event | No | Only published or only withdrawn events. Omit for both. | |
| limit | No | Most events returned by this call (1–80). | |
| cursor | No | next_cursor from the previous call, passed with the other inputs unchanged; omit to start from end_date. | |
| category | No | Item category: primary, secondary, or eu-origin. With content_type legislation or associated-documents only. | |
| end_date | No | Last event date, YYYY-MM-DD; defaults to start_date. The window is at most 31 days. | |
| new_only | No | true: only events for items appearing on legislation.gov.uk for the first time. | |
| direction | No | With content_type changes only: effects recorded against (affected) or made by (affecting) the item. | |
| start_date | Yes | First event date of the window, YYYY-MM-DD (UK local time). | |
| content_type | No | legislation (documents published), changes (effects recorded), draft, or associated-documents. Omit for all. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | No | The limit applied. |
| days | No | Days touched by a day walk (empty in item-log mode). |
| mode | No | day_walk: per-day pages; item_log: one item's undated log. |
| error | No | Present when the call failed. Absent on success. |
| shown | No | Events returned. |
| events | No | Events, newest first. |
| notice | No | Guidance when the window is quiet or the list continues. |
| window | No | The window read. |
| filters | No | Filters applied. |
| has_more | No | True when more events remain in the window — call again with next_cursor. |
| truncated | No | True when the list was capped at limit. |
| attribution | No | Attribution lines the returned content requires (OGL always; EU and Westlaw credits when applicable). |
| next_cursor | No | Pass as cursor to continue; present only when has_more is true. |
| read_back_to | No | Item-log mode: date (YYYY-MM-DD) of the oldest event on the pages of the item's log this call has passed. The log is read newest first, jumping ahead by page to find an older window; a page checked beyond the window's start does not count. While it is after end_date, the read has not reached the window yet. Absent in a day walk and when no event read carries a calendar date. |
| item_log_total | No | Events in the item's whole log, all dates; present in item-log mode when reported. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, open-world behavior, and the description adds non-obvious operational traits: newest-first ordering, day-by-day walking that can require multiple calls, and cursor continuation. The main remaining gap is that it doesn't say how to detect the end of the window beyond next_cursor absence.
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?
Three dense sentences, front-loaded with the core purpose and followed by mode behavior and the sibling hand-off; nothing is padding. The middle sentence's filter list partly restates the schema enums, which is the only redundancy.
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?
With an output schema present, return-shape detail is unnecessary, and the description still covers ordering, pagination, multi-call cost, and the sibling hand-off for missing effect detail. An agent has everything needed to choose and invoke it 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%, so parameters are already well documented; the description adds meaning by explaining that `item` switches the tool between single-item log and windowed day-walk, and by summarizing the filter set. It does not add syntax or interaction detail beyond what the schema enums and conditional notes already provide.
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 ("Read the legislation.gov.uk Publication Log") plus the exact scope: a date window of up to 31 days covering new items, revised versions, effects, and withdrawals. It also frames the tool conceptually ("the compliance-monitoring view of 'what changed'"), which distinguishes it from sibling lookup/search tools.
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?
Explicitly routes between modes: a full item path reads that item's own log in one call, while anything else walks day by day and may need several calls. It also names the alternative for a gap ("A changes event carries no effect detail — uklaw_get_amendments with that item has it") and explains how to continue with next_cursor.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
3 tool updates
- Changed
uklaw_get_amendments1 field changed- changed
Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `invalid_item`: item or counterpart is not a (partial) item path or legislation.gov.uk URI, or its type code is unknown, or counterpart carries a provision. `regnal_item`: item or counterpart is a pre-1963 regnal path (ukpga/Geo5/15-16/20, aep/Ann/6): the changes feeds index effects by calendar year and chapter number only. `draft_item`: item or counterpart is draft legislation (ukdsi, sdsi, nidsr), which the changes feeds do not index. `invalid_provision`: provision cannot be normalized. `provision_needs_full_item`: provision is combined with a partial item. `invalid_cursor`: cursor does not decode, belongs to a different query, or holds a position no call over that query reaches (a page past 10,000, or an offset past the end of its page). `filter_refused`: legislation.gov.uk answered the changes feed with 404 or 400: a path or filter combination it does not accept. `upstream_refused`: legislation.gov.uk answered 403 or 429 (its fair use rate limit or a block). `pacer_shed`: The shared request queue cannot start this call within its deadline. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `invalid_item`: item or counterpart is not a (partial) item path or legislation.gov.uk URI, or its type code is unknown, or counterpart carries a provision. `regnal_item`: item or counterpart is a pre-1963 regnal path (ukpga/Geo5/15-16/20, aep/Ann/6): the changes feeds index effects by calendar year and chapter number only. `draft_item`: item or counterpart is draft legislation (ukdsi, sdsi, nidsr), which the changes feeds do not index. `invalid_provision`: provision cannot be normalized. `provision_needs_full_item`: provision is combined with a partial item. `invalid_cursor`: cursor does not decode, belongs to a different query, or holds a position no call over that query reaches (a page past 10,000, an offset past the end of its page, or a field only uklaw_track_changes writes). `filter_refused`: legislation.gov.uk answered the changes feed with 404 or 400: a path or filter combination it does not accept. `upstream_refused`: legislation.gov.uk answered 403 or 429 (its fair use rate limit or a block). `pacer_shed`: The shared request queue cannot start this call within its deadline. Other values are possible when a failure originates below the handler."
- Changed
uklaw_get_document8 fields changed- changed
Input schema / properties / item / descriptionPrevious value: -"Item path {type}/{year}/{number} — ukpga/2018/12, uksi/2019/419, eur/2016/679, ukpga/Eliz2/3-4/19 — or any legislation.gov.uk URI (a URI carrying a provision, version, or /welsh is split into those parts; a version or /welsh in the URI applies unless the version or language input is set). Get it from uklaw_lookup_citation or uklaw_search_legislation."New value: +"Item path {type}/{year}/{number} — ukpga/2018/12, uksi/2019/419, eur/2016/679, ukpga/Eliz2/3-4/19 — or any legislation.gov.uk URI (a URI carrying a provision, version, or /welsh is split into those parts; a version or /welsh in the URI applies unless the version or language input is set). Get it from uklaw_lookup_citation or uklaw_search_legislation. A path legislation.gov.uk serves at another path — a pre-1963 Act by calendar year (ukpga/1925/20 is ukpga/Geo5/15-16/20), a Welsh SI as uksi — is read there, and item.path reports the served path, with a notice." - changed
Input schema / properties / version / descriptionPrevious value: -"current (the latest revised text, or the original text for an item never revised), enacted (made, adopted and created are synonyms — the original text), or a date YYYY-MM-DD for the text as it stood then. Omitted: the version in an item URI, else current. A future date returns the latest version, and a date on or after the made or enactment date of an item never revised returns its original text, with a notice; version.applied reports the version served."New value: +"current (the latest revised text, or the original text for an item never revised), enacted (made, adopted and created are synonyms — the original text), or a date YYYY-MM-DD for the text as it stood then. Omitted: the version in an item URI, else current. A future date returns the latest version; a date before the earliest revised version (1991-02-01 for most primary legislation, 2006-01-01 for Northern Ireland) returns that version, with a notice; and a date on or after the made or enactment date of an item never revised returns its original text, with a notice. version.applied reports the version served." - changed
Output schema / properties / editorial / properties / outstanding_effects / descriptionPrevious value: -"Effects requiring a text change not yet applied that touch this provision, or at item level every such effect on the item: the full count, beyond the 20 unapplied_effects lists."New value: +"Effects requiring a text change not yet applied: at provision level those touching the provision, an element enclosing it (Part, Chapter, cross-heading) or a provision inside it; at item level every such effect on the item. The full count, beyond the 20 unapplied_effects lists and the effects inside an outlined provision, which it does not list." - changed
Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `invalid_item`: item is not a full {type}/{year}/{number} item path or legislation.gov.uk URI, its type code is unknown, or a URI carries an unreadable provision. `invalid_provision`: provision cannot be normalized, or conflicts with a provision embedded in item. `invalid_version`: version is shaped YYYY-MM-DD but is not a real calendar date, or a URI carried an unsupported version. `match_text_needs_item_level`: match_text is combined with provision. `document_not_found`: legislation.gov.uk has no such item, or the identifier check that would tell a missing item from a missing provision could not run in time. `provision_not_found`: The item exists but has no document at that provision path and version. `version_not_found`: Item level: the item exists but has no version at the requested date (the date precedes it). `upstream_refused`: legislation.gov.uk answered 403 or 429 (its fair use rate limit or a block). `pacer_shed`: The shared request queue cannot start this call within its deadline. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `invalid_item`: item is not a full {type}/{year}/{number} item path or legislation.gov.uk URI, its type code is unknown, or a URI carries an unreadable provision. `invalid_provision`: provision cannot be normalized, or conflicts with a provision embedded in item. `invalid_version`: version is shaped YYYY-MM-DD but is not a real calendar date, or a URI carried an unsupported version. `ambiguous_item`: item names more than one item on legislation.gov.uk (a 300), as a pre-1963 calendar year and chapter shared by two parliamentary sessions does: ukpga/1955/19. `match_text_needs_item_level`: match_text is combined with provision. `document_not_found`: legislation.gov.uk has no such item, or the identifier check that would tell a missing item from a missing provision could not run in time. `provision_not_found`: The item exists but has no document at that provision path and version. `version_not_found`: Item level: the item exists but has no version at the requested date (the date precedes it). `upstream_refused`: legislation.gov.uk answered 403 or 429 (its fair use rate limit or a block). `pacer_shed`: The shared request queue cannot start this call within its deadline. Other values are possible when a failure originates below the handler." - changed
Output schema / properties / error / properties / data / properties / reason / examplesPrevious value: -[ - "invalid_item", - "invalid_provision", - "invalid_version", - "match_text_needs_item_level", - "document_not_found", - "provision_not_found", - "version_not_found", - "upstream_refused", - "pacer_shed" -]New value: +[ + "invalid_item", + "invalid_provision", + "invalid_version", + "ambiguous_item", + "match_text_needs_item_level", + "document_not_found", + "provision_not_found", + "version_not_found", + "upstream_refused", + "pacer_shed" +] - changed
Output schema / properties / item / properties / path / descriptionPrevious value: -"Item path, e.g. ukpga/2018/12."New value: +"Item path legislation.gov.uk serves the item at, e.g. ukpga/2018/12; a redirected input (ukpga/1925/20 → ukpga/Geo5/15-16/20) reports the served path, with a notice." - changed
Output schema / properties / notice / descriptionPrevious value: -"Notices: Welsh fallback, original text served for a dated read, an omitted provision window, the unapplied effects an item outline leaves out, truncated lists, an outline window with the outline_offset that continues it, an oversized provision with no smaller child provisions returned whole or cut (its full size, and the links to the full text), and how to continue."New value: +"Notices: the path an item input is served at, Welsh fallback, original text served for a dated read, a later version served for a date before the earliest revised version, an omitted provision window, the unapplied effects an item outline or an outlined provision leaves out, unapplied effects on enclosing or contained provisions that could not be checked, how many effects of a multi-page unapplied changes feed were checked, truncated lists, an outline window with the outline_offset that continues it, an oversized provision with no smaller child provisions returned whole or cut (its full size, and the links to the full text), and how to continue." - changed
Output schema / properties / unapplied_effects / descriptionPrevious value: -"Recorded effects not yet applied to the revised text that touch this provision (at item level, the item’s): the first 20, outstanding first, with a notice when more exist; empty when none. Absent on an item-level outline, where a notice gives the item’s count and uklaw_get_amendments lists them."New value: +"Recorded effects not yet applied to the revised text that touch this provision — whole-item effects, those on an element enclosing it (Part, Chapter, cross-heading), and when kind is full those on a provision inside it — or at item level the item’s: the first 20, outstanding first, with a notice when more exist; empty when none. An outlined provision does not list the effects inside it; a notice counts them. Absent on an item-level outline, where a notice gives the item’s count. uklaw_get_amendments with the item (for a pre-1963 Act, its calendar-year path, as the notices name it) and status \"unapplied\", without provision, lists them all."
- Changed
uklaw_track_changes2 fields changed- changed
Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `invalid_date`: start_date or end_date is shaped YYYY-MM-DD but is not a real calendar date. `invalid_window`: end_date is before start_date, or the window is over 31 days. `direction_needs_changes`: direction is set without content_type changes. `category_needs_content_type`: category is set without content_type legislation or associated-documents. `invalid_item`: item is not a (partial) item path or legislation.gov.uk URI, its type code is unknown, or it carries a provision. `invalid_cursor`: cursor does not decode, belongs to a different window, or holds a position no call over that window reaches (a day outside the window or after today, a day in item-log mode, a page past 10,000, or an offset past the end of its page). `filter_refused`: legislation.gov.uk answered the Publication Log feed with 404 or 400: a filter combination it does not accept. `upstream_refused`: legislation.gov.uk answered 403 or 429 (its fair use rate limit or a block). `pacer_shed`: The shared request queue cannot start this call within its deadline. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `invalid_date`: start_date or end_date is shaped YYYY-MM-DD but is not a real calendar date. `invalid_window`: end_date is before start_date, or the window is over 31 days. `direction_needs_changes`: direction is set without content_type changes. `category_needs_content_type`: category is set without content_type legislation or associated-documents. `invalid_item`: item is not a (partial) item path or legislation.gov.uk URI, its type code is unknown, or it carries a provision. `invalid_cursor`: cursor does not decode, belongs to a different window, or holds a position no call over that window reaches (a day outside the window or after today, a day in item-log mode, a page past 10,000, an offset past the end of its page, a page-search bound outside item-log mode, at or below its page, or past 10,000, or an events-returned mark other than the one the server writes). `filter_refused`: legislation.gov.uk answered the Publication Log feed with 404 or 400: a filter combination it does not accept. `upstream_refused`: legislation.gov.uk answered 403 or 429 (its fair use rate limit or a block). `pacer_shed`: The shared request queue cannot start this call within its deadline. Other values are possible when a failure originates below the handler." - changed
Output schema / properties / read_back_to / descriptionPrevious value: -"Item-log mode: date (YYYY-MM-DD) of the oldest event this call read from the item's log, which is read newest first. While it is after end_date, the read has not reached the window yet. Absent in a day walk and when no event read carries a calendar date."New value: +"Item-log mode: date (YYYY-MM-DD) of the oldest event on the pages of the item's log this call has passed. The log is read newest first, jumping ahead by page to find an older window; a page checked beyond the window's start does not count. While it is after end_date, the read has not reached the window yet. Absent in a day walk and when no event read carries a calendar date."
6 tool updates
- First observed
uklaw_get_amendments - First observed
uklaw_get_document - First observed
uklaw_list_reference - First observed
uklaw_lookup_citation - First observed
uklaw_search_legislation - First observed
uklaw_track_changes
Related MCP Connectors
Search UK Acts, Statutory Instruments, and legislation with full text retrieval
Point-in-time amendment history for 528 UK law provisions: search, version history, changes.
Resolve, search and verify legal citations against the official sources, with provenance.
UK legal research — case law, legislation, Hansard, bills, votes, committees, HMRC, citations
Related MCP Servers
- AlicenseAqualityAmaintenanceEnables searching and retrieval of UK legislation (Acts, Statutory Instruments) from legislation.gov.uk with persistent identifiers and verifiable citations.9123 PyPIApache 2.0
- AlicenseNot gradedqualityCmaintenanceEnables querying point-in-time amendment history for UK law, including searching provisions, viewing provision histories, listing recent amendments, and identifying most-amended provisions.1MIT
- AlicenseAqualityBmaintenanceProvides comprehensive tools for searching UK case law, legislation, parliamentary Hansard debates, and HMRC tax guidance. It features a specialized OSCOLA citation parser to extract and resolve legal references directly from text.37418 PyPI20MIT

Legalizeofficial
AlicenseNot gradedqualityBmaintenanceEnables AI assistants to search and read consolidated legislation from multiple countries, retrieve exact law texts as of any historical date with citations and git commit SHAs, and create webhook or email subscriptions to track legal changes.2MIT
Glama MCP Gateway
Add one secure layer between your agents and this server.