Skip to main content
Glama
deenesjakoruzh
paulieb89

GOV UK Search

by paulieb89
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

govuk-mcp

PyPI Glama Install in VS Code Install in VS Code Insiders Install in Cursor Install in VS Code (local)

MCP server for GOV.UK — search, content retrieval, organisation lookup, and postcode resolution.

Tools

Tool

Description

govuk_search

Full-text search across 700k+ GOV.UK pages, with format and organisation filters

govuk_get_content

Page metadata and navigable section index for any GOV.UK page by base path

govuk_get_section

Body HTML for a single named section (anchor) of a GOV.UK page

govuk_grep_content

Regex/substring search within the body of a specific GOV.UK page

govuk_get_organisation

Get details for a UK government organisation (type, parent, children, contacts)

govuk_list_organisations

Paginated list of all government organisations registered on GOV.UK

govuk_lookup_postcode

Resolve a UK postcode to local authority, region, constituency, and NHS board

All data is sourced from official public GOV.UK APIs and postcodes.io. No API keys required.

Related MCP server: @mountainpass/addressr-mcp

Resources

For protocol-aware clients (Claude, Cursor, Inspector), the server also exposes govuk:// resource templates:

URI

Returns

govuk://content/{base_path*}/header

Page metadata (title, doc type, dates)

govuk://content/{base_path*}/index

Section anchor:heading list

govuk://content/{base_path*}/section/{anchor}

Bounded HTML for one section

govuk://content/{base_path*}/details/{field}

Schema-specific details field

govuk://content/{base_path*}/links/{rel}

Related content by link type

govuk://organisation/{slug}

Organisation profile

Connect

Hosted (no install)

{
  "mcpServers": {
    "govuk": {
      "type": "http",
      "url": "https://govuk-mcp.fly.dev/mcp"
    }
  }
}

Local (uvx)

{
  "mcpServers": {
    "govuk": {
      "type": "stdio",
      "command": "uvx",
      "args": ["govuk-mcp"]
    }
  }
}

APIs used

API

Base URL

Auth

GOV.UK Search

https://www.gov.uk/api/search.json

None

GOV.UK Content

https://www.gov.uk/api/content{path}

None

GOV.UK Organisations

https://www.gov.uk/api/organisations

None

postcodes.io

https://api.postcodes.io

None

License

MIT

Available Tools

7 tools
govuk_get_contentGet GOV.UK PageA
Read-onlyIdempotent

Get metadata and navigable section index for a GOV.UK page.

Returns the page title, document type, publication dates, and a list of sections with their anchor IDs and headings. Use govuk_get_section to read the body of a specific section, or govuk_grep_content to search within the page body.

ParametersJSON Schema
NameRequiredDescriptionDefault
base_pathYesGOV.UK base_path, e.g. '/universal-credit' or 'universal-credit'

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is known. The description adds valuable context beyond annotations by specifying exactly what is returned (title, document type, dates, section list) and what is not returned (body content), which helps manage expectations.

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 concise and well-structured: the first sentence states the purpose, the second lists return values, and the third gives usage guidance. Every sentence earns its place with no redundant information.

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?

With only one parameter and an output schema present, the description provides sufficient context: it explains what the tool returns, what it does not return (body content), and directs users to alternative tools for other needs. This fully equips an agent to decide when and how to use the tool.

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 schema covers 100% of the parameter information, providing the name, type, and example format for base_path. The description does not add further parameter semantics, so a baseline score of 3 is appropriate since the schema already does the heavy lifting.

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 retrieves metadata and a navigable section index for a GOV.UK page, specifying the resource and the exact data returned. It also differentiates from sibling tools by explicitly naming govuk_get_section and govuk_grep_content for body content, making its unique role clear.

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 guidance on when to use this tool versus alternatives: it says to use govuk_get_section to read a section's body and govuk_grep_content to search within the page body. This gives the agent clear decision criteria and directly addresses alternative tools.

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

govuk_get_organisationGet GOV.UK OrganisationA
Read-onlyIdempotent

Get the profile of a UK government organisation by its slug.

Returns name, acronym, type, status, web URL, and parent/child organisations. Use govuk_list_organisations to browse all organisations and discover slugs.

ParametersJSON Schema
NameRequiredDescriptionDefault
slugYesOrganisation slug, e.g. 'hm-revenue-customs'. Find slugs via govuk_list_organisations.

Output Schema

ParametersJSON Schema
NameRequiredDescription
titleNoFull organisation title.
acronymNoOrganisation acronym, if set.
slugNoOrganisation slug, e.g. 'hm-revenue-customs'. Usable with govuk_search filters.
typeNoOrganisation type, e.g. 'ministerial_department', 'executive_agency', 'non_ministerial_department', 'public_corporation'.
stateNoGOV.UK status, e.g. 'live', 'closed', 'transitioning'.
web_urlNoAbsolute https://www.gov.uk URL for the organisation page.
parent_organisationsNoTitles of parent organisations this body reports into.
child_organisationsNoTitles of child organisations / agencies under this body.
contact_detailsNoContact details block from GOV.UK (phone, email, address) when available.

TDQS

A4.1/5.0
Behavior3/5

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

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the return fields (name, acronym, type, status, web URL, parent/child organisations), which is useful context, but does not disclose error behavior, authentication needs, or rate limits. This is a modest addition beyond the annotations, consistent with a simple read-only tool.

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 exceptionally concise: two sentences, with the first stating purpose and the second summarizing return data and pointing to a sibling tool. Every word earns its place, with no redundancy or filler.

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?

For a single-parameter, read-only tool with rich annotations and an output schema, this description is complete. It explains what the tool does, what information is returned, and how to find the required parameter value. No critical information is missing for this low-complexity tool.

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 provides 100% coverage of the single parameter 'slug', including a description with an example and guidance on finding slugs via govuk_list_organisations. The description's phrase 'by its slug' adds no new semantics beyond what the schema already documents, 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.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function with a specific verb ('Get') and resource ('profile of a UK government organisation'), and identifies the input method ('by its slug'). It distinguishes itself from sibling tools like govuk_list_organisations by focusing on fetching a single organisation's profile rather than browsing all organisations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context by indicating this tool is used when you have a slug and need details, and explicitly points to govuk_list_organisations as the alternative for discovering slugs. It does not explicitly state when not to use this tool, but the guidance provided is sufficient for the tool's simple use case.

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

govuk_get_sectionGet GOV.UK Page SectionA
Read-onlyIdempotent

Get the HTML content of one named section of a GOV.UK page.

Use govuk_get_content first to get the list of available section anchors, then call this with the anchor of the section you want to read.

ParametersJSON Schema
NameRequiredDescriptionDefault
base_pathYesGOV.UK base_path, e.g. '/universal-credit'
anchorYesSection anchor ID from govuk_get_content sections list

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, reducing the burden on the description. The description adds context beyond annotations by noting the dependency on govuk_get_content and clarifying that the tool returns HTML content. It does not cover error behavior or rate limits, but with strong annotations and an output schema, this level of additional context is sufficient.

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 two short sentences, immediately stating the core function and then providing the workflow. It is front-loaded, contains no redundant phrases, and every clause contributes to understanding how to use the tool. This is a model of concise, structured documentation.

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 simplicity (2 required parameters), strong annotation coverage, and the presence of an output schema, the description is complete. It covers the purpose, the prerequisite call, and the source of the anchor parameter. There are no significant gaps that would leave an agent uncertain about how to 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 provides 100% coverage with descriptions for both parameters: 'anchor' and 'base_path'. The description does not add further meaning beyond what the schema already states; it merely echoes the workflow. Therefore, the schema does the heavy lifting, and the description offers no additional parameter-level insight, earning the baseline score of 3.

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 opens with 'Get the HTML content of one named section of a GOV.UK page,' which uses a specific verb ('Get'), a precise resource ('HTML content of one named section'), and clear scope ('one named section'). It distinguishes from sibling tools by tying the anchor to govuk_get_content, making the tool's niche unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly instructs to 'Use govuk_get_content first to get the list of available section anchors, then call this with the anchor of the section you want to read.' This provides a clear workflow and prerequisite. It does not explicitly state when not to use this tool, but the phrase 'one named section' implies alternatives for whole-page content, so it is useful but not exhaustive.

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

govuk_grep_contentSearch within a GOV.UK content bodyA
Read-onlyIdempotent

Find body sections in a GOV.UK content item matching a pattern.

Returns a list of {anchor, heading, snippet, match} hits — small per-section snippets centred on the match — so the LLM can decide which full sections to read via govuk_get_section.

Use this when answering content-based questions ("what does this guide say about X?", "find the bit about eligibility") rather than navigating by section number.

Pattern is regex; if it doesn't compile, falls back to literal substring.

ParametersJSON Schema
NameRequiredDescriptionDefault
base_pathYesGOV.UK base_path, e.g. '/guidance/register-for-vat' or '/universal-credit'
patternYesRegex or literal substring to search for within the page body, e.g. 'payment' or 'eligible.*income'
case_insensitiveNoIf true (default), match case-insensitively
max_hitsNoMaximum number of matching sections to return (1–100)

Output Schema

ParametersJSON Schema
NameRequiredDescription
base_pathYesThe content item that was searched
patternYesThe pattern that was searched for
hitsYesMatching sections in document order
truncatedYesTrue if hit count reached max_hits and more matches may exist

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare readOnlyHint/idempotentHint, so the description adds value by detailing the return structure (`{anchor, heading, snippet, match}`) and the fallback behavior: 'Pattern is regex; if it doesn't compile, falls back to literal substring.' This discloses edge-case behavior beyond the 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?

Four short paragraphs, each with a distinct purpose: purpose, return format, usage guidance, and pattern behavior. No redundant sentences; front-loaded with the core action.

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?

The description covers what the tool returns, when to use it, how it relates to sibling tools, and the regex fallback. Given the output schema exists, it doesn't need to enumerate return fields, but it does anyway for clarity. The tool's complexity is well handled.

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 the fallback semantics for `pattern` and explains that hits are per-section snippets, giving extra meaning to `max_hits` and `pattern` beyond the schema. This additional nuance raises it to 4.

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 opens with a clear verb+resource+scope: 'Find body sections in a GOV.UK content item matching a pattern.' It distinguishes itself from siblings by referencing govuk_get_section and contrasting with 'navigating by section number,' making its purpose unambiguous.

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?

Explicit usage guidance is provided: 'Use this when answering content-based questions ... rather than navigating by section number.' It also prescribes a workflow: 'so the LLM can decide which full sections to read via govuk_get_section,' naming an alternative tool and the condition for its use.

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

govuk_list_organisationsList GOV.UK OrganisationsA
Read-onlyIdempotent

List all UK government organisations registered on GOV.UK.

Returns a paginated list of organisations including their slug, acronym, type, and status. Use this to browse the full government structure or discover slugs for use with govuk_get_organisation or govuk_search filters.

ParametersJSON Schema
NameRequiredDescriptionDefault
pageNoPage number (1-based)
per_pageNoResults per page (1–50)

Output Schema

ParametersJSON Schema
NameRequiredDescription
pageYes1-based page number requested.
per_pageYesMax organisations requested per page.
totalNoTotal number of organisations across all pages, if reported by GOV.UK.
total_pagesNoTotal number of pages available, if reported by GOV.UK.
returnedYesNumber of organisations returned in this response.
has_moreYesTrue if more organisations exist beyond this page. Re-call with page=page+1 to fetch the next page.
organisationsNoOrganisations on this page, in the order returned by GOV.UK.

TDQS

A4.3/5.0
Behavior4/5

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

The annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, establishing a safe read-only operation. The description adds behavioral context by noting the paginated nature of the response and listing included fields (slug, acronym, type, status). This goes beyond the annotations, though it doesn't cover every potential behavior like rate limits.

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 concise: two sentences that front-load the main purpose, then efficiently explain return contents and usage. Every sentence provides useful information with no filler or redundancy.

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 simplicity (2 optional parameters, read-only, no side effects), the description covers what users need to know: what the tool lists, what fields are included, and how the result integrates with other tools. The output schema exists, so the description doesn't need to detail all return fields. Annotations cover the safety profile, making this complete.

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 schema provides 100% coverage for both parameters (page and per_page), including descriptions, defaults, and constraints. The description only refers to pagination generically and adds no syntax or format details beyond what the schema already documents. Therefore, it meets the baseline for schema-covered parameters.

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's function: 'List all UK government organisations registered on GOV.UK.' It names the specific resource (organisations) and distinguishes it from siblings by noting that it can be used to 'discover slugs for use with govuk_get_organisation or govuk_search filters.' This makes the purpose unambiguous and differentiates it from related tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear guidance on when to use the tool: 'Use this to browse the full government structure or discover slugs.' It also implies alternative tools (govuk_get_organisation, govuk_search) for other purposes. However, it doesn't explicitly state when not to use it, so it falls short of a perfect 5.

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

govuk_lookup_postcodeLook Up UK PostcodeA
Read-onlyIdempotent

Look up a UK postcode to retrieve its local authority, region, constituency, and other administrative geography.

Useful for determining which council area, parliamentary constituency, or NHS region a postcode falls within. Commonly used to direct users to the correct local service on GOV.UK (e.g. council tax, planning, waste).

Uses the postcodes.io public API (no key required).

ParametersJSON Schema
NameRequiredDescriptionDefault
postcodeYesUK postcode, e.g. 'SW1A 2AA' or 'NG1 1AA'. Spaces optional.

Output Schema

ParametersJSON Schema
NameRequiredDescription
postcodeNoCanonicalised postcode as returned by postcodes.io.
latitudeNoLatitude in decimal degrees (WGS84).
longitudeNoLongitude in decimal degrees (WGS84).
countryNoCountry, e.g. 'England', 'Scotland', 'Wales', 'Northern Ireland'.
regionNoONS region, e.g. 'East Midlands'.
parliamentary_constituencyNoParliamentary constituency (pre-2025 boundary).
parliamentary_constituency_2025NoParliamentary constituency under the 2025 boundaries.
local_authorityNoLocal authority / council covering the postcode.
admin_countyNoAdministrative county, where applicable (null in unitary areas).
nhs_integrated_care_boardNoNHS Integrated Care Board, where available.
codesNoGSS codes for all administrative geographies covering this postcode.

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare read-only, idempotent, and non-destructive. The description adds valuable context that it uses the postcodes.io public API with no key required, but does not mention rate limits or invalid input handling. This is sufficient for a simple read-only lookup.

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?

Three short, focused paragraphs with no redundancy. The first sentence gives the core operation, the second adds usage context, and the third provides a technical detail. Every sentence earns its place.

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

Completeness4/5

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

Given the tool's simplicity (one parameter, full schema coverage, output schema present), the description adequately covers what, when, and external API details. It could mention edge cases like invalid postcodes, but for a direct lookup this is sufficient.

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 schema provides 100% coverage of the single parameter, including format, length, and examples. The description adds little beyond what the schema already states, so the baseline of 3 applies.

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 states the action 'Look up' and the resource 'UK postcode' with specific outputs like local authority, region, and constituency. This clearly distinguishes it from sibling tools focused on content, organisations, or search.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly states when to use the tool ('Useful for determining which council area...') and gives practical examples like directing users to local services. However, it does not mention alternative tools or when-not-to-use, though no sibling tool offers postcode lookup.

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.

  1. 9 tool updates
    • Addedgovuk_get_content
    • Addedgovuk_get_organisation
    • Addedgovuk_get_section
    • Changedgovuk_grep_content6 fields changed
      • addedInput schema / properties / base_path
        Added value: +{
+  "description": "GOV.UK base_path, e.g. '/guidance/register-for-vat' or '/universal-credit'",
+  "maxLength": 500,
+  "minLength": 1,
+  "type": "string"
+}
      • addedInput schema / properties / case_insensitive
        Added value: +{
+  "default": true,
+  "description": "If true (default), match case-insensitively",
+  "type": "boolean"
+}
      • addedInput schema / properties / max_hits
        Added value: +{
+  "default": 25,
+  "description": "Maximum number of matching sections to return (1–100)",
+  "maximum": 100,
+  "minimum": 1,
+  "type": "integer"
+}
      • removedInput schema / properties / params
        Removed value: -{
-  "additionalProperties": false,
-  "description": "Input schema for govuk_grep_content.",
-  "properties": {
-    "base_path": {
-      "description": "GOV.UK base_path of a content item, e.g. 'guidance/planning-guidance-letters-to-chief-planning-officers' (leading slash optional). Use govuk_search to discover base_paths.",
-      "maxLength": 500,
-      "minLength": 1,
-      "type": "string"
-    },
-    "case_insensitive": {
-      "default": true,
-      "description": "Default true.",
-      "type": "boolean"
-    },
-    "max_hits": {
-      "default": 25,
-      "description": "Cap on returned hits.",
-      "maximum": 100,
-      "minimum": 1,
-      "type": "integer"
-    },
-    "pattern": {
-      "description": "Regex pattern (or plain substring) to search within the body. If the pattern doesn't compile as regex, falls back to literal substring match.",
-      "maxLength": 200,
-      "minLength": 2,
-      "type": "string"
-    }
-  },
-  "required": [
-    "base_path",
-    "pattern"
-  ],
-  "type": "object"
-}
      • addedInput schema / properties / pattern
        Added value: +{
+  "description": "Regex or literal substring to search for within the page body, e.g. 'payment' or 'eligible.*income'",
+  "maxLength": 200,
+  "minLength": 1,
+  "type": "string"
+}
      • changedInput schema / required
        Previous value: -[
-  "params"
-]New value: +[
+  "base_path",
+  "pattern"
+]
    • Changedgovuk_list_organisations4 fields changed
      • addedInput schema / properties / page
        Added value: +{
+  "default": 1,
+  "description": "Page number (1-based)",
+  "minimum": 1,
+  "type": "integer"
+}
      • removedInput schema / properties / params
        Removed value: -{
-  "additionalProperties": false,
-  "description": "OrganisationsListInput with 1-based page and per_page (1–50).",
-  "properties": {
-    "page": {
-      "default": 1,
-      "description": "Page number (1-based)",
-      "minimum": 1,
-      "type": "integer"
-    },
-    "per_page": {
-      "default": 20,
-      "description": "Results per page (1–50)",
-      "maximum": 50,
-      "minimum": 1,
-      "type": "integer"
-    }
-  },
-  "type": "object"
-}
      • addedInput schema / properties / per_page
        Added value: +{
+  "default": 20,
+  "description": "Results per page (1–50)",
+  "maximum": 50,
+  "minimum": 1,
+  "type": "integer"
+}
      • removedInput schema / required
        Removed value: -[
-  "params"
-]
    • Changedgovuk_lookup_postcode3 fields changed
      • removedInput schema / properties / params
        Removed value: -{
-  "additionalProperties": false,
-  "description": "PostcodeInput with a UK postcode (e.g. 'NG1 1AA', 'SW1A 2AA').",
-  "properties": {
-    "postcode": {
-      "description": "UK postcode, e.g. 'SW1A 2AA' or 'NG1 1AA'. Spaces optional.",
-      "maxLength": 8,
-      "minLength": 5,
-      "type": "string"
-    }
-  },
-  "required": [
-    "postcode"
-  ],
-  "type": "object"
-}
      • addedInput schema / properties / postcode
        Added value: +{
+  "description": "UK postcode, e.g. 'SW1A 2AA' or 'NG1 1AA'. Spaces optional.",
+  "maxLength": 8,
+  "minLength": 5,
+  "type": "string"
+}
      • changedInput schema / required
        Previous value: -[
-  "params"
-]New value: +[
+  "postcode"
+]
    • Changedgovuk_search8 fields changed
      • addedInput schema / properties / count
        Added value: +{
+  "default": 10,
+  "description": "Number of results to return (1–50)",
+  "maximum": 50,
+  "minimum": 1,
+  "type": "integer"
+}
      • addedInput schema / properties / filter_format
        Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Filter by document format. Common values: 'guide', 'answer', 'transaction', 'publication', 'news_article', 'detailed_guide', 'hmrc_manual_section', 'travel_advice', 'organisation'. Leave blank to search all types."
+}
      • addedInput schema / properties / filter_organisations
        Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Filter by organisation slug, e.g. 'hm-revenue-customs', 'department-for-work-pensions', 'driver-and-vehicle-standards-agency'."
+}
      • addedInput schema / properties / order
        Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Sort order. Use '-public_timestamp' for newest-first (default relevance)."
+}
      • removedInput schema / properties / params
        Removed value: -{
-  "additionalProperties": false,
-  "description": "SearchInput with query, count, start, optional format/org\nfilters, and optional sort order.",
-  "properties": {
-    "count": {
-      "default": 10,
-      "description": "Number of results to return (1–50)",
-      "maximum": 50,
-      "minimum": 1,
-      "type": "integer"
-    },
-    "filter_format": {
-      "anyOf": [
-        {
-          "type": "string"
-        },
-        {
-          "type": "null"
-        }
-      ],
-      "default": null,
-      "description": "Filter by document format. Common values: 'guide', 'answer', 'transaction', 'publication', 'news_article', 'detailed_guide', 'hmrc_manual_section', 'travel_advice', 'organisation'. Leave blank to search all types."
-    },
-    "filter_organisations": {
-      "anyOf": [
-        {
-          "type": "string"
-        },
-        {
-          "type": "null"
-        }
-      ],
-      "default": null,
-      "description": "Filter by organisation slug, e.g. 'hm-revenue-customs', 'department-for-work-pensions', 'driver-and-vehicle-standards-agency'."
-    },
-    "order": {
-      "anyOf": [
-        {
-          "type": "string"
-        },
-        {
-          "type": "null"
-        }
-      ],
-      "default": null,
-      "description": "Sort order. Use '-public_timestamp' for newest-first (default relevance)."
-    },
-    "query": {
-      "description": "Free-text search query, e.g. 'universal credit eligibility' or 'MOT check'",
-      "maxLength": 500,
-      "minLength": 1,
-      "type": "string"
-    },
-    "start": {
-      "default": 0,
-      "description": "Offset for pagination, e.g. 10 for the second page of 10 results",
-      "minimum": 0,
-      "type": "integer"
-    }
-  },
-  "required": [
-    "query"
-  ],
-  "type": "object"
-}
      • addedInput schema / properties / query
        Added value: +{
+  "description": "Free-text search query, e.g. 'universal credit eligibility' or 'MOT check'",
+  "maxLength": 500,
+  "minLength": 1,
+  "type": "string"
+}
      • addedInput schema / properties / start
        Added value: +{
+  "default": 0,
+  "description": "Offset for pagination, e.g. 10 for the second page of 10 results",
+  "minimum": 0,
+  "type": "integer"
+}
      • changedInput schema / required
        Previous value: -[
-  "params"
-]New value: +[
+  "query"
+]
    • Removedlist_resources
    • Removedread_resource
  2. 6 tool updatesv0.2.0
    • First observedgovuk_grep_content
    • First observedgovuk_list_organisations
    • First observedgovuk_lookup_postcode
    • First observedgovuk_search
    • First observedlist_resources
    • First observedread_resource
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.5/5.0

Scored across 7 tools

Disambiguation5/5

Each tool has a clear, distinct purpose with no overlap. Tools like govuk_get_content, govuk_get_section, and govuk_grep_content are designed to work together in a chained manner, avoiding ambiguity.

Naming Consistency5/5

All tools follow a consistent 'govuk_verb_noun' pattern (e.g., govuk_get_content, govuk_list_organisations, govuk_lookup_postcode), making the naming predictable and easy to understand.

Tool Count5/5

Seven tools is an appropriate number for the server's purpose—searching and retrieving UK government information. Each tool earns its place by providing essential functionality without redundancy.

Completeness5/5

The tool set covers the core use cases: content search and retrieval, section navigation, organisation lookup, and postcode-based geographic information. No obvious gaps for a read-only government information server.

Maintenance

ActivityStale
ResponsivenessUnresponsive

Resources

Related MCP Connectors

Related MCP Servers