What can you do with this server?

govuk-mcp is an MCP server providing access to official UK government (GOV.UK) data — no API keys required. * Search GOV.UK (govuk_search): Full-text search across 700,000+ pages, with optional filters for document format (e.g. guides, transactions) and organisation, plus pagination and sorting. * Get page content/metadata (govuk_get_content): Retrieve metadata (title, doc type, dates) and a navigable section index for any GOV.UK page by its base path. * Get a specific section (govuk_get_section): Fetch the body HTML for a single named section (anchor) of a GOV.UK page. * Search within a page (govuk_grep_content): Use regex or substring search within a page's body, returning matched snippets with context. * Get organisation details (govuk_get_organisation): Look up a UK government organisation by slug to get its type, parent bodies, child agencies, and contact details. * List all organisations (govuk_list_organisations): Browse a paginated list of all government organisations, including slugs, acronyms, types, and statuses. * Look up a postcode (govuk_lookup_postcode): Resolve a UK postcode to its local authority, region, parliamentary constituency (including 2025 boundaries), NHS Integrated Care Board, country, and coordinates. * Access structured resources (via govuk:// URIs): For protocol-aware clients, access page headers, section indexes, individual sections, schema-specific fields, related content links, and organisation profiles.

de en es ja ko ru zh

GOV UK Search

by paulieb89

Overview Schema Related Servers Score Discussions

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

Name	Required	Description	Default
`base_path`	Yes	GOV.UK base_path, e.g. '/universal-credit' or 'universal-credit'

Output Schema

ParametersJSON Schema

Name	Required	Description
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, idempotentHint, and destructiveHint, so the description does not need to repeat safety traits. The description adds value by detailing the output structure (title, dates, sections), which helps the agent understand what the tool does without needing to consult the output schema. No behavioral contradictions with annotations.

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

Conciseness5/5

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

Two sentences: first sentence states purpose, second enumerates return values and directs to alternatives. No wasted words; every sentence earns its place.

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 presence of an output schema (as indicated by context signals), the description adequately covers the return values and tool behavior. It also references sibling tools for further actions, making it self-contained for an agent to decide whether to use this tool or another.

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?

Schema coverage is 100% with a single parameter (base_path) already described in the schema. The description does not add any additional semantics or usage details for the parameter beyond what is in the schema, so baseline 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 retrieves metadata and a navigable section index for a GOV.UK page using the specific verb 'Get'. It distinguishes from siblings like govuk_get_section and govuk_grep_content by specifying the returned data (section index vs. body content).

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?

Explicitly tells when to use alternatives: 'Use govuk_get_section to read the body of a specific section, or govuk_grep_content to search within the page body.' This provides clear guidance on tool selection.

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

Name	Required	Description	Default
`slug`	Yes	Organisation slug, e.g. 'hm-revenue-customs'. Find slugs via govuk_list_organisations.

Output Schema

ParametersJSON Schema

Name	Required	Description
`title`	No	Full organisation title.
`acronym`	No	Organisation acronym, if set.
`slug`	No	Organisation slug, e.g. 'hm-revenue-customs'. Usable with govuk_search filters.
`type`	No	Organisation type, e.g. 'ministerial_department', 'executive_agency', 'non_ministerial_department', 'public_corporation'.
`state`	No	GOV.UK status, e.g. 'live', 'closed', 'transitioning'.
`web_url`	No	Absolute https://www.gov.uk URL for the organisation page.
`parent_organisations`	No	Titles of parent organisations this body reports into.
`child_organisations`	No	Titles of child organisations / agencies under this body.
`contact_details`	No	Contact 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?

Annotations already convey read-only, idempotent, and open-world behavior. The description adds that it returns specific fields like parent/child organisations, which is useful but does not reveal additional behavioral traits such as error handling or response size limits. With annotations covering the core safety profile, the description adds only moderate context.

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 sentences long, front-loaded with the tool's purpose, and contains no extraneous words. Every sentence adds value, making it highly efficient for an agent to parse.

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 (one required parameter, no enums, output schema present), the description provides adequate context: it lists return fields and references a sibling tool for slug discovery. No gaps remain for effective use.

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?

Input schema coverage is 100%, and the schema's description for the slug parameter already explains its purpose and how to find values. The description only mentions 'by its slug' without adding new semantic detail, so it meets the baseline but does not exceed it.

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 a GOV.UK organisation profile by slug, and lists specific return fields (name, acronym, type, etc.). It also distinguishes from sibling tool govuk_list_organisations by mentioning where to find slugs, thus helping the agent choose the correct tool.

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 directs users to use govuk_list_organisations to discover slugs, providing clear context for when to use this tool versus its sibling. No exclusions or when-not-to-use guidance is provided, but the purpose is straightforward.

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

Name	Required	Description	Default
`base_path`	Yes	GOV.UK base_path, e.g. '/universal-credit'
`anchor`	Yes	Section anchor ID from govuk_get_content sections list

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already convey read-only, idempotent, non-destructive behavior. The description adds the dependency on govuk_get_content for anchors, which is valuable behavioral context 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?

Two sentences with clear structure: first states purpose, second gives usage guidance. No extraneous content, highly efficient.

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 presence of an output schema and annotations, the description covers purpose, usage sequence, and output type. It could mention error handling but is sufficient for a simple 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 already provides full descriptions for both parameters (100% coverage). The description does not add new semantic information beyond what is in the schema, so baseline score 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 it gets 'the HTML content of one named section of a GOV.UK page'. The verb 'get' and resource 'HTML content of one named section' are specific, and it distinguishes itself from sibling tools like govuk_get_content by focusing on a single section.

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?

Explicitly instructs the agent to use govuk_get_content first to obtain section anchors, then call this tool. This provides a clear sequence and prerequisite, effectively guiding when and how to use the tool.

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

Name	Required	Description
`base_path`	Yes	GOV.UK base_path, e.g. '/guidance/register-for-vat' or '/universal-credit'
`pattern`	Yes	Regex or literal substring to search for within the page body, e.g. 'payment' or 'eligible.*income'
`case_insensitive`	No	If true (default), match case-insensitively
`max_hits`	No	Maximum number of matching sections to return (1–100)

Output Schema

ParametersJSON Schema

Name	Required	Description
`base_path`	Yes	The content item that was searched
`pattern`	Yes	The pattern that was searched for
`hits`	Yes	Matching sections in document order
`truncated`	Yes	True if hit count reached max_hits and more matches may exist

TDQS

A4.6/5.0

Behavior5/5

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

Describes return format (list of {anchor, heading, snippet, match}), that snippets are small and per-section, and pattern fallback. Annotations already provide readOnlyHint, destructiveHint, etc., and description adds context without contradiction.

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?

Description is concise, 4 sentences, front-loaded with purpose, then output format, usage hint, and pattern behavior. No wasted words, well-structured.

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 presence of an output schema and detailed input schema, description covers key behavioral aspects: output format, intended usage, pattern fallback. Could mention max_hits behavior but schema handles it.

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?

Schema coverage is 100%, so baseline is 3. Description adds minor value by noting pattern regex fallback, but schema already defines pattern as 'Regex or literal substring'. Other parameters are sufficiently described in schema.

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?

Description clearly states 'Find body sections in a GOV.UK content item matching a pattern.' Differentiates from siblings by contrasting with navigating by section number and referencing govuk_get_section for full sections.

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?

Explicitly states 'Use this when answering content-based questions... rather than navigating by section number.' Also explains pattern behavior (regex with fallback) and that results are snippets for LLM to decide next step.

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

Name	Required	Description	Default
`page`	No	Page number (1-based)
`per_page`	No	Results per page (1–50)

Output Schema

ParametersJSON Schema

Name	Required	Description
`page`	Yes	1-based page number requested.
`per_page`	Yes	Max organisations requested per page.
`total`	No	Total number of organisations across all pages, if reported by GOV.UK.
`total_pages`	No	Total number of pages available, if reported by GOV.UK.
`returned`	Yes	Number of organisations returned in this response.
`has_more`	Yes	True if more organisations exist beyond this page. Re-call with page=page+1 to fetch the next page.
`organisations`	No	Organisations on this page, in the order returned by GOV.UK.

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, indicating safe read-only behavior. The description adds further transparency by noting the paginated nature and the fields returned, which goes beyond the annotations. No contradictions.

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) and front-loaded with the essential purpose. Every sentence adds value: the first states what the tool does, the second provides usage guidance. No unnecessary words.

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 presence of an output schema (has output schema: true) and comprehensive annotations, the description is fairly complete. It explains the paginated list and the fields returned, which is sufficient for a list tool. Could mention the read-only nature, but annotations already cover that.

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

Parameters3/5

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

The input schema has 100% description coverage, with both parameters (page and per_page) already documented. The description does not add additional meaning or context beyond what the schema provides, so a baseline score 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 lists all UK government organisations on GOV.UK and specifies the returned fields (slug, acronym, type, status). It also distinguishes itself from siblings by mentioning that it helps discover slugs for use with govuk_get_organisation or govuk_search filters.

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 says 'Use this to browse the full government structure or discover slugs for use with govuk_get_organisation or govuk_search filters,' which provides clear context for when to use the tool. It does not explicitly list when not to use it, but the provided sibling tools imply alternatives.

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

Name	Required	Description	Default
`postcode`	Yes	UK postcode, e.g. 'SW1A 2AA' or 'NG1 1AA'. Spaces optional.

Output Schema

ParametersJSON Schema

Name	Required	Description
`postcode`	No	Canonicalised postcode as returned by postcodes.io.
`latitude`	No	Latitude in decimal degrees (WGS84).
`longitude`	No	Longitude in decimal degrees (WGS84).
`country`	No	Country, e.g. 'England', 'Scotland', 'Wales', 'Northern Ireland'.
`region`	No	ONS region, e.g. 'East Midlands'.
`parliamentary_constituency`	No	Parliamentary constituency (pre-2025 boundary).
`parliamentary_constituency_2025`	No	Parliamentary constituency under the 2025 boundaries.
`local_authority`	No	Local authority / council covering the postcode.
`admin_county`	No	Administrative county, where applicable (null in unitary areas).
`nhs_integrated_care_board`	No	NHS Integrated Care Board, where available.
`codes`	No	GSS codes for all administrative geographies covering this postcode.

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already provide readOnlyHint, idempotentHint, etc. Description adds valuable context: 'Uses the postcodes.io public API (no key required).' This discloses the external source and keyless access. No contradiction with annotations.

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

Conciseness5/5

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

Two brief paragraphs, first immediately states purpose, second adds usage and API info. No filler, every sentence adds value.

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?

Tool has output schema for return values. Description covers purpose, usage scenarios, and API source. Complete for a simple lookup tool with good annotations and schema.

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?

Input schema has 100% coverage with description, maxLength, minLength. Description adds practical details: 'Spaces optional', example formats (e.g., 'SW1A 2AA' or 'NG1 1AA'), which aids agent in constructing valid inputs.

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?

Description clearly states the tool's purpose: 'Look up a UK postcode to retrieve its local authority, region, constituency, and other administrative geography.' The verb 'look up' and resource 'UK postcode' are specific. Siblings are all about content, organisations, sections, etc., making this tool distinct.

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?

Description explains when to use: 'determining which council area, etc.' and usage context: 'direct users to the correct local service.' It does not explicitly state when not to use, but context is clear. Mentions the API used, but no alternative tools suggested.

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

govuk_searchSearch GOV.UKA

Read-onlyIdempotent

Search GOV.UK's 700k+ content items using the official Search API.

Returns a list of matching content items with title, description, link, format, owning organisation(s), and last updated timestamp.

Use filter_format to narrow to specific content types (e.g. 'transaction' for citizen-facing services, 'guide' for guidance, 'publication' for official documents). Use filter_organisations to restrict to a department.

ParametersJSON Schema

Name	Required	Description
`query`	Yes	Free-text search query, e.g. 'universal credit eligibility' or 'MOT check'
`count`	No	Number of results to return (1–50)
`start`	No	Offset for pagination, e.g. 10 for the second page of 10 results
`filter_format`	No	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`	No	Filter by organisation slug, e.g. 'hm-revenue-customs', 'department-for-work-pensions', 'driver-and-vehicle-standards-agency'.
`order`	No	Sort order. Use '-public_timestamp' for newest-first (default relevance).

Output Schema

ParametersJSON Schema

Name	Required	Description
`query`	Yes	The free-text query that was searched.
`total`	Yes	Total matching results across all pages on GOV.UK.
`start`	Yes	Offset used for this page (zero-based).
`count`	Yes	Max results requested for this page.
`returned`	Yes	Number of results actually returned in this response.
`has_more`	Yes	True if more results exist beyond this page. Re-call with start=start+returned to fetch the next page.
`results`	No	Matching pages. Use the `link` field of any result as the `base_path` input to govuk_get_content for the full item.

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds value by stating it returns 'title, description, link, format, owning organisation(s), and last updated timestamp,' and mentions pagination via start parameter. No contradiction.

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 paragraphs, front-loaded with main action. Every sentence adds value: what it searches, what it returns, how to filter. No redundancy or fluff.

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 6 parameters (1 required), 100% schema coverage, and an output schema (not shown but referenced), the description sufficiently covers search usage, output shape, and filtering. It is complete for an agent to select and invoke correctly.

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

Parameters4/5

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

Schema coverage is 100% with descriptions for all parameters. The description adds meaning beyond the schema by providing concrete examples for filter_format (e.g., 'transaction' for citizen-facing services) and filter_organisations (e.g., 'hm-revenue-customs'), and clarifying sort order syntax.

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 it searches GOV.UK's 700k+ content items using the official Search API. The title 'Search GOV.UK' and description explicitly distinguish this from sibling tools like govuk_get_content (for specific items) and govuk_grep_content (grep-like).

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 guidance on when to use filters: 'Use filter_format to narrow to specific content types' and 'Use filter_organisations to restrict to a department.' It does not explicitly exclude alternatives but implies this is for general search, while siblings serve different purposes.

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. Dates show when Glama detected each change.

9 tool updatesApr 29, 2026

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

6 tool updatesv0.2.0Apr 20, 2026
- First observedgovuk_grep_content
- First observedgovuk_list_organisations
- First observedgovuk_lookup_postcode
- First observedgovuk_search
- First observedlist_resources
- First observedread_resource

Install Server

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

TDQS

A4.5/5.0

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

ActivitySlowing

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Datagov Uk A
io.github.pipeworx-io
data.gov.uk MCP — UK national open-data portal (CKAN API).
Government Data Open Data
352
mcp A
ai.llmse
Public MCP server for the LLM Search Engine
Search RAG Systems Developer Tools
102
mcp-serpOAuth
io.github.AceDataCloud
MCP server for Google search results via SERP API
Search Browser Automation Web Scraping
21
Probe V0 A
io.github.lexbritten
Experimental MCP server for current empirical verification of explicit public HTTPS endpoint claims.
API Testing Penetration Testing
21

Related MCP Servers

npm-search-mcp-server
Search Developer Tools
btwiuse
A
license
C
quality
F
maintenance
MCP server for searching npm packages
Updated 7 months ago (2026-02-20 23:48 UTC)
1
38
16
MIT
@mountainpass/addressr-mcp
Location Services Search
mountain-pass
A
license
Not graded
quality
F
maintenance
MCP server for Australian address search and validation powered by Addressr.
Updated 3 months ago (2026-06-04 06:06 UTC)
185
Apache 2.0
openbusdata
Travel & Transportation Open Data
AndrewAubury
A
license
C
quality
B
maintenance
MCP server for the UK Bus Open Data Service, enabling timetable queries, stop search, route discovery, journey planning, and real-time bus tracking.
Updated 3 months ago (2026-06-19 17:07 UTC)
16
MIT
Keenable MCP
Search
keenableai
A
license
A
quality
A
maintenance
MCP server for live web search and clean-markdown page fetch over the Keenable web index.
Updated 14 days ago (2026-08-23 07:11 UTC)
2
85
3
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/paulieb89/govuk-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server