Provides tools for retrieving carbon intensity data for Great Britain from the National Grid ESO.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@OpenUKPublicDataMCP look up postcode SW1A 1AA"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
OpenUKPublicDataMCP is a no-key-first Model Context Protocol server for useful UK public data.
The goal is to give Claude, Hermes, Cursor, and other MCP clients one reliable endpoint for common UK public-data questions: postcodes, GOV.UK content, bank holidays, carbon intensity, public datasets, flood monitoring, parliamentary/legal/statistical lookups, and optional-key enrichments such as Companies House, EPC, Ordnance Survey, and TfL.
MVP shipped: 23+ MCP tools, FastAPI explorer API, and web/ React map UI. Tier C backlog (EPC, Met Office, Parliament) remains optional.
Related MCP server: floodwise
No-key-first: core tools must work without signup.
Source-cited: every tool returns upstream source metadata and retrieval time.
Official-first: prefer official UK public sector APIs; label community/non-official sources explicitly.
Thin adapters: normalize useful fields but keep upstream payloads available.
Optional enrichments: API-key sources are allowed only as optional modules.
Read-only by default: no public-sector write operations in the initial project.
health_check — server health and configured source count.
list_sources — source registry with auth/licence/freshness notes.
plan_uk_public_data_research / get_research_methodology / save_uk_research_note — agent planning surface.
lookup_postcode — postcode lookup via postcodes.io.
get_bank_holidays — GOV.UK bank holidays by UK region.
get_carbon_intensity — National Grid ESO carbon intensity for Great Britain.
search_govuk — GOV.UK Search API.
search_public_datasets — data.gov.uk CKAN package search.
list_flood_warnings / search_flood_areas — Environment Agency flood monitoring (England).
search_ons_datasets / get_ons_dataset / get_ons_latest_version / get_ons_observations — ONS Beta API.
search_planning_applications — planning.data.gov.uk (England).
get_cpih_inflation_headline — CPIH month-on-month % from ONS observations.
list_uk_regions — explorer geography metadata (sample postcodes).
police_street_crime_near — data.police.uk near lat/lng.
search_mp_by_postcode, search_constituencies — UK Parliament Members API.
met_office_site_forecast — Met Office DataHub (optional MET_OFFICE_DATAHUB_API_KEY).
companies_house_company_profile — optional COMPANIES_HOUSE_API_KEY.
os_places_find_place — optional OS_PLACES_API_KEY.
tfl_line_status — optional TFL_APP_ID + TFL_APP_KEY.
Implementation plan: docs/plans/2026-07-05-openuk-v1-implementation.md. Test brief: docs/tests/Q2-executive-report.md.
cd /home/stephen/projects/OpenUKPublicDataMCP
python3.11 -m venv .venv
. .venv/bin/activate
pip install -e '.[dev]'
python -m openukpublicdata_mcp.serverRun validation:
pytest
fastmcp inspect src/openukpublicdata_mcp/server.py:mcp
fastmcp list src/openukpublicdata_mcp/server.py --json
fastmcp call src/openukpublicdata_mcp/server.py lookup_postcode postcode='SW1A 1AA' --jsonAfter the server is stable, register it with Hermes using hermes config set rather than editing config files directly:
hermes config set mcp_servers.openukpublicdata.command "/home/stephen/projects/OpenUKPublicDataMCP/.venv/bin/python"
hermes config set mcp_servers.openukpublicdata.args '["-m", "openukpublicdata_mcp.server"]'
hermes config set mcp_servers.openukpublicdata.timeout 120
hermes config set mcp_servers.openukpublicdata.connect_timeout 60Restart Hermes after changing MCP config.
./scripts/run-web.sh
# http://127.0.0.1:8765See web/README.md for dev mode (Vite + API).
See research/LINKS.md and research/github-projects/ for the first competitor/source notes.
Fetch Companies House company profile (requires COMPANIES_HOUSE_API_KEY).
| Name | Required | Description | Default |
|---|---|---|---|
| company_number | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the API key requirement, omitting details such as read-only nature, rate limits, error handling, or data scope. This is insufficient for full behavioral transparency.
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 a single sentence that front-loads the purpose and includes a key requirement. It is concise and to the point, but could be slightly better structured with a separate line for the requirement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema and one required parameter, the description still lacks completeness. It does not explain what data the profile contains, any constraints on the company number (e.g., UK companies only), or the nature of the operation (read-only). The API key requirement is stated but not elaborated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single parameter 'company_number' with no description (0% schema description coverage). The tool description provides no additional meaning about the parameter, such as format or source, leaving the agent with no guidance on what value to 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?
The description clearly states the verb 'Fetch' and resource 'Companies House company profile', making the purpose obvious. However, it does not differentiate from sibling tools, which include various data fetch operations, so it is clear but not distinctive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the requirement of COMPANIES_HOUSE_API_KEY, which is a usage precondition. It does not provide guidance on when to use this tool versus alternatives, but since no other Companies House tool exists among siblings, usage is implied. Score 3 for implied usage with a key requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get bank holidays for England and Wales, Scotland, or Northern Ireland.
| Name | Required | Description | Default |
|---|---|---|---|
| region | No | england-and-wales |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as data freshness, whether future or all holidays are returned, or any rate limits. The tool is a simple read operation, but the lack of detail is notable.
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 a single concise sentence with no unnecessary words, fully capturing the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple one-parameter tool with an output schema, the description is minimally complete but lacks contextual guidance on typical use cases or limitations. It covers the essential purpose but could be more helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, but the description lists the three regions (matching the enum values). It does not explicitly state that the parameter is optional with a default, though the schema conveys that. The description adds moderate value by naming the regions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'bank holidays', and specifies the geographic scope (England and Wales, Scotland, or Northern Ireland). This distinguishes it well from sibling tools which focus on different data types.
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?
No guidance is provided on when to use this tool versus alternatives. With many sibling tools for different UK data, the agent would benefit from explicit usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current GB carbon intensity, optionally for a regional intensity region ID.
| Name | Required | Description | Default |
|---|---|---|---|
| region_id | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as rate limits, data freshness, authentication requirements, or side effects. The tool performs a read operation, but this is not explicitly stated, and the description carries the full burden of transparency.
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 a single sentence of 12 words, with no filler or redundancy. Every word earns its place, making it highly efficient while still conveying the essential information.
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?
The tool has only one optional parameter and an output schema is present, so the return format is covered. However, the description lacks any mention of data source, refresh interval, or potential error conditions. For a simple tool, it is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description mentions 'optionally for a regional intensity region ID', clarifying that region_id is optional and its purpose. This adds value beyond the schema alone, though no details on valid values or format are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 'current GB carbon intensity', with an optional regional filter. The verb 'Get' and specific resource 'carbon intensity' make the purpose unambiguous, and it stands out among sibling tools like get_bank_holidays or get_cpih_inflation_headline.
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?
No guidance is given on when to use this tool versus alternatives. There is no mention of prerequisites, context, or when to avoid using it. The description simply states what the tool does, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Latest CPIH index month-on-month % change from ONS observations (UK aggregate slice).
| Name | Required | Description | Default |
|---|---|---|---|
| dataset_id | No | cpih01 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the output (latest CPIH index month-on-month % change) but does not mention read-only nature, authorization needs, or rate limits. Since no annotations are provided, the description carries the burden; it is adequate but not comprehensive.
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 a single concise sentence that front-loads the key purpose. However, it omits important details about parameter and usage, which limits its effectiveness despite the brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema, the description does not need to explain return values. However, it is missing parameter information and usage context. For a simple tool, it is minimally adequate but leaves gaps for a agent making selection decisions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one optional parameter with no description and 0% schema coverage. The description does not explain the parameter at all, only mentioning 'dataset_id' implicitly via the default 'cpih01'. The description fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the latest CPIH index month-on-month % change from ONS observations, specifying it is a UK aggregate slice. This distinguishes it from sibling tools like get_ons_observations and get_ons_latest_version.
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?
No guidance on when to use this tool versus alternatives. With many sibling ONS tools, the description should indicate when this is the appropriate choice, but it does not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch ONS dataset metadata (release frequency, editions, links).
| Name | Required | Description | Default |
|---|---|---|---|
| dataset_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states the basic read action without disclosing potential outcomes like error handling, required permissions, or any side effects. The safety profile is unclear.
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 a single, concise sentence that efficiently conveys the tool's purpose without extraneous words. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one parameter) and presence of an output schema, the description is adequate but minimal. It lacks details on input format, potential errors, and which specific metadata fields are returned, making it only moderately complete.
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 0%, meaning the description adds no meaning to the dataset_id parameter beyond the schema's type. No format examples or constraints are given, so the agent must rely solely on the parameter name.
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 specifies the resource (ONS dataset metadata) and the action (Fetch), listing specific metadata elements (release frequency, editions, links). This clearly distinguishes from sibling tools like get_ons_observations and get_ons_latest_version.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for fetching metadata, but does not explicitly state when to use this tool versus alternatives such as search_ons_datasets or get_ons_latest_version. No when-not or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve the latest ONS Beta API edition/version for a dataset.
| Name | Required | Description | Default |
|---|---|---|---|
| dataset_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose whether the operation is read-only, requires authentication, or handles errors for invalid dataset IDs.
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 a single sentence, which is concise. However, it could provide more information without becoming verbose; it is slightly under-specified.
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?
Despite the tool's simplicity and the presence of an output schema, the description lacks behavioral context, parameter semantics, and usage guidance, making it incomplete for an agent to invoke 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 description coverage is 0%, and the description adds no meaning beyond the parameter name 'dataset_id'. No format, source, or constraints are explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('resolve') and the specific resource ('latest ONS Beta API edition/version for a dataset'). It effectively distinguishes from sibling tools like get_ons_dataset and get_ons_observations.
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?
No guidance on when to use this tool versus alternatives. The description does not mention prerequisites, typical use cases, or exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch ONS observations with time=*; some datasets require extra upstream dimension filters not yet exposed.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| edition | No | ||
| version | No | ||
| dataset_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the 'time=*' wildcard behavior and a potential missing filter issue, but fails to mention any other behavioral traits like read-only nature, rate limits, or error conditions.
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 a single sentence with no wasted words. However, it could be more front-loaded with essential info; it starts with 'Fetch ONS observations' which is functional.
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?
Despite having an output schema, the description lacks parameter semantics and usage guidance. The tool has 4 parameters with one required, and the description does not cover enough context for an agent to 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 description coverage is 0%, and the description adds no meaning to the parameters. It mentions 'time=*' but does not explain the four parameters (limit, edition, version, dataset_id) or their roles.
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 the tool fetches ONS observations with a time wildcard, which is a clear verb-resource pairing. It hints at a limitation about extra dimension filters, distinguishing it from sibling tools like get_ons_dataset that fetch metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It mentions a limitation ('some datasets require extra upstream dimension filters not yet exposed') but does not advise on when to use or not use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Methodology for no-key-first UK public data research and citation rules.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'no-key-first' but does not disclose side effects, authentication needs, or what happens when called. Minimal behavioral disclosure.
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 a single sentence with no wasted words. It is appropriately sized for zero parameters, but it lacks structure that could improve readability (e.g., bullet points).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description does not need full return details, but it should set clearer expectations. The mention of 'methodology' and 'rules' is insufficient given the sibling tools. Adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, schema coverage is trivially 100%. The description adds meaning by naming the resource ('methodology' and 'citation rules'), providing baseline context. However, it could be more explicit about the content.
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 it provides a 'methodology' and 'citation rules,' but it does not specify the verb (e.g., retrieve, fetch) or the nature of the output. It is vague and does not clearly differentiate from siblings like plan_uk_public_data_research.
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?
No guidance on when to use this tool versus alternatives such as plan_uk_public_data_research or save_uk_research_note. The description lacks context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return server health and source registry status.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description states it returns health status but doesn't elaborate on behavior or side effects. Adequate for a non-destructive read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words. Perfectly concise.
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?
Low complexity (0 params, output schema exists) and description covers the core purpose. Could explain 'source registry status' but minor.
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?
No parameters; schema coverage is 100%. Description adds no param info but is unnecessary.
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?
Clear verb+resource: 'Return server health and source registry status.' Distinct from sibling tools which fetch external data.
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?
No explicit guidance on when to use or alternatives. Usage is implied as a general health check.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List current Environment Agency flood warnings (England).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits like read-only nature or data freshness. It only states it lists warnings, missing important context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at one sentence, but it sacrifices necessary detail for brevity. It is appropriately sized but could include more information without being wordy.
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?
Despite having an output schema, the description lacks details about the parameter and usage context, making it incomplete for a tool with one parameter and no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'limit' with a default, but the description does not mention it. Since schema description coverage is 0%, the description fails to add meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists current flood warnings from the Environment Agency for England, using a specific verb 'List' and identifying the resource and scope.
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?
No guidance is provided on when to use this tool versus alternatives like search_flood_areas. There is no mention of context or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List configured UK public-data sources and their auth/licence metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| auth | No | all |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states that the tool lists sources with metadata, but does not disclose idempotency, rate limits, or any side effects. The behavior is implicitly read-only, but not stated.
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 a single, concise sentence without redundancy. However, it is slightly too brief, lacking parameter information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description is adequate for a basic understanding but misses the 'auth' parameter and any contextual cues about when to use this 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?
The input schema has one parameter 'auth' with enum values, but the description does not mention it or explain its purpose or usage. With 0% schema description coverage, the description adds no value beyond the schema itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and the resource 'configured UK public-data sources', including their auth/licence metadata. It distinguishes itself from sibling tools which are specific data endpoints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for discovering available data sources, but it lacks explicit guidance on when to use versus specific data retrieval tools or any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List UK nations/regions with sample postcodes for explorer map drill-down.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. 'List' implies a read operation but does not explicitly state safety, side effects, or data source freshness. Minimal behavioral disclosure, not contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of 11 words, perfectly concise with no wasted words. Essential information front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and presence of an output schema, the description sufficiently covers the tool's purpose and additional context (sample postcodes). Could hint at the structure of the output, but schema handles that.
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?
Tool has no parameters, so baseline score of 4 applies. Description does not need to add parameter information, and schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'List UK nations/regions with sample postcodes', specifying the exact resource (UK nations/regions) and action (list), which is distinct among sibling tools that focus on different data resources.
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?
Indicates usage context ('for explorer map drill-down') but does not provide explicit when-not-to-use or alternative tools. However, no obvious alternative exists among siblings for this specific resource.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up a UK postcode and return location/geography metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| postcode | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description implies a read operation with no side effects. But with no annotations, it does not detail rate limits, authentication, or exact output fields beyond 'metadata'. Acceptable for a simple lookup but could be more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, focused sentence with no extraneous information. Perfectly concise for the tool's simplicity.
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 values are documented. However, the description could clarify what 'location/geography metadata' entails (e.g., lat/long, region). For a single-parameter lookup, it's adequate but leaves some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'postcode' has no schema description (0% coverage). The description adds 'UK' context, specifying the geographical scope. However, no format or validation details are provided, so only minimal added value.
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?
Clearly states it looks up a UK postcode and returns location/geography metadata. Distinguishes from sibling tools like search_mp_by_postcode which is for MP lookup, and os_places_find_place which is a broader search.
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?
No guidance on when to use this tool versus alternatives like search_mp_by_postcode or os_places_find_place. Missing when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Met Office Weather DataHub site-specific forecast (optional MET_OFFICE_DATAHUB_API_KEY).
| Name | Required | Description | Default |
|---|---|---|---|
| latitude | Yes | ||
| longitude | Yes | ||
| resolution | No | hourly |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It mentions an optional API key, which is a configuration detail, but fails to disclose rate limits, data freshness, or whether the tool is read-only. The description provides minimal insight into side effects or prerequisites.
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 very concise, but it sacrifices informativeness. It is a single phrase without structure or elaboration. While conciseness is valued, here it results in under-specification, earning a middle score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema, the description need not detail return values, but it still leaves gaps in usage context. For a tool with 3 parameters (2 required) and no schema descriptions, the description is incomplete, lacking guidance on parameter semantics and when to use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the tool description does not explain any of the three parameters (latitude, longitude, resolution). The description adds no meaning beyond the schema, leaving the agent without guidance on how to use the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the resource ('Met Office Weather DataHub site-specific forecast') and implies the action of retrieving a forecast. It distinguishes this tool from siblings, as no other tool in the list targets Met Office weather data. However, it could be more explicit about the kind of forecast (e.g., daily, hourly) and what is returned.
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?
There is no guidance on when to use this tool versus alternatives, such as other weather or data tools. The description mentions an optional API key but does not explain when it is needed or what happens without it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find UK places or postcodes via Ordnance Survey Places (requires OS_PLACES_API_KEY).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It does not state whether the tool is read-only, destructive, or any other behavioral traits (rate limits, data freshness).
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 a single sentence with no fluff, but it is too minimal and omits important details that could be added without verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0% schema description coverage, and two parameters, the description is incomplete. It fails to explain usage context, parameter behavior, or return values, leaving the agent to infer too much.
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 0%, requiring description to compensate. The description only hints that 'query' is a place name or postcode, but does not explain format or the 'limit' parameter at all.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Find' and resource 'UK places or postcodes' via Ordnance Survey Places, and mentions the API key requirement. It is specific but does not distinguish from similar sibling like lookup_postcode.
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?
Only includes a prerequisite (API key) but provides no guidance on when to use this tool versus alternatives such as lookup_postcode or other geospatial tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a structured research plan (tool order, depth, suggested output) for UK public-data questions.
| Name | Required | Description | Default |
|---|---|---|---|
| depth | No | standard | |
| topic | Yes | ||
| period | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states it returns a plan, with no mention of side effects, latency, required permissions, or that it is read-only. This is insufficient for an agent to assess risk or constraints.
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 a single sentence, which is concise but lacks structure and front-loading of critical information. It could be more informative without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a planning tool and many siblings, the description is incomplete. It does not explain how the output plan should be used, what fields it contains, or how depth/period affect it. The presence of an output schema is not leveraged in the description.
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 0%, so the description must explain parameters. It does not describe 'topic', 'depth' (enum meanings), or 'period'. The description adds no value beyond the schema names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns a structured research plan with tool order, depth, and suggested output, which is distinct from sibling tools that retrieve specific data. Verb 'Return' and resource 'structured research plan' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for UK public-data questions but does not explicitly state when to use this tool versus directly calling a specific sibling data tool. No guidance on prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Street-level crime categories near a lat/lng (England and Wales, data.police.uk).
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | ||
| limit | No | ||
| latitude | Yes | ||
| longitude | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states what data is returned, omitting information on side effects, rate limits, authentication needs, or whether it's read-only. The behavior is not transparent.
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 a single, concisely worded sentence that front-loads the key action and scope. Every word serves a purpose with no fluff.
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?
Despite having 4 parameters (2 required) and 0% schema description coverage, the description addresses only the coordinate parameters. The output schema exists but the description doesn't mention return structure or any additional context needed for correct invocation.
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 0%, so the description must compensate. It mentions lat/lng as parameters but fails to clarify date format, limit meaning, or default behaviors. The description adds little semantic value beyond the schema's existence.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves street-level crime categories near a lat/lng, specifying geographic scope (England and Wales) and data source (data.police.uk). The verb is implied, but the resource and context are well-defined. It distinguishes from unrelated sibling 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?
No guidance on when to use this tool versus alternatives. No prerequisites, context, or when-not-to-use information is provided. The description lacks any usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Persist a research brief under ~/research// (or UK_RESEARCH_ROOT).
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | ||
| topic | Yes | ||
| filename | No | UK_PUBLIC_DATA_BRIEF.md | |
| content_markdown | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It indicates writing ('persist') but does not disclose overwrite behavior, required permissions, error conditions, or side effects.
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 very concise (one sentence), which is efficient, but it sacrifices necessary detail. It is not verbose, but lacks completeness.
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?
Despite having an output schema (not shown), the description does not explain return values or behavior. For a 4-parameter tool with required fields, the description is insufficiently complete.
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 0%, and the description provides no explanation of individual parameters beyond implying slug affects the path. The required fields topic and content_markdown are not described.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (persist) and the resource (research brief), including the file location pattern. However, it does not distinguish this tool from its siblings, though no sibling directly overlaps in functionality.
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?
No guidance on when to use this tool versus alternatives, prerequisites, or exclusions. The description is silent on context of use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Westminster constituencies by name (UK Parliament API).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| search_text | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. However, it only mentions the data source (UK Parliament API) without addressing whether the tool is read-only, idempotent, or has rate limits. The description is minimally transparent.
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 a single, front-loaded sentence that efficiently conveys the core purpose without any extraneous words.
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 a moderate complexity (2 parameters) and an existing output schema, the description is adequate but minimal. It could add context about typical use cases or the nature of the search (e.g., partial match, case sensitivity). However, the output schema is not described, but that is not required.
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 0%. The description implies search_text is a constituency name but does not explain the limit parameter or any format/constraints. Given the lack of schema descriptions, the description should provide more detail for each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'search', the resource 'Westminster constituencies', and the qualifier 'by name', with the source 'UK Parliament API'. This distinguishes it from sibling tools like search_govuk or search_mp_by_postcode.
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?
No guidance on when to use this tool versus alternatives such as search_mp_by_postcode or search_govuk. The description does not include contextual cues or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Environment Agency flood monitoring areas by name or river.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral transparency. It does not mention any behavioral traits such as read-only nature, rate limits, authentication, or error behavior (e.g., no results handling). The minimal description leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence of 10 words, front-loading the key information. However, it could include more detail without becoming verbose. It earns a 4 for efficiency but loses a point for lacking depth.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with 2 parameters and an output schema, the description is partially complete. It covers the basic purpose but omits usage guidance and behavioral details. Given the availability of an output schema (which likely documents return values), the description is minimally viable but not comprehensive.
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 0%, meaning the schema provides no parameter descriptions. The description adds only that the search is 'by name or river' for the query parameter, but does not clarify the format or that the query can be either. The limit parameter is entirely unmentioned. The description fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Search' and the resource 'Environment Agency flood monitoring areas', specifying search by name or river. This distinguishes it from sibling tools like list_flood_warnings and search_constituencies, which target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for searching flood areas by name/river, but provides no explicit guidance on when to use this tool versus alternatives like list_flood_warnings or other search tools. No exclusions or when-not-to-use advice is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search GOV.UK content.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states 'Search GOV.UK content' with no information about permissions, rate limits, return format, pagination, or what types of content are searched.
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 very short (one sentence), but it is under-specified rather than concise. It fails to include necessary information, making it insufficient for the agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is completely inadequate for a tool with 2 parameters and many siblings. It lacks details on usage, parameter semantics, and behavioral context.
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 0%. The description does not add any meaning to the parameters 'query' or 'limit'. The agent receives no guidance on how to use them.
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 the verb 'Search' and the resource 'GOV.UK content', which is clear. However, it does not differentiate from sibling tools like search_public_datasets or search_ons_datasets, which also search UK public data.
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?
No guidance on when to use this tool versus alternatives. No context about prerequisites, limitations, or exclusive use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find current MPs for a UK postcode (UK Parliament Members API).
| Name | Required | Description | Default |
|---|---|---|---|
| postcode | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only mentions 'current MPs' but does not disclose whether multiple results are possible, error handling, rate limits, or authentication needs. Output schema exists but description adds no behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, concise and front-loaded. Could include more detail without becoming verbose, but no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema, the description is adequate but leaves gaps in behavioral expectations. Lacks guidance on result structure or edge cases.
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 0%, and the description only says 'UK postcode' without providing format guidance, examples, or validation rules. The single required parameter is self-explanatory from its name, so minimal added value.
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?
Clearly states the tool finds current MPs for a UK postcode, citing the UK Parliament Members API. Distinguishes from siblings like search_constituencies by specifying MPs rather than constituencies.
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?
No guidance on when to use this tool versus alternatives such as search_constituencies or lookup_postcode. No mention of prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search ONS Beta API datasets by keyword.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states 'search by keyword' without mentioning read-only nature, pagination, rate limits, or error behavior.
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 a single sentence, which is efficient, but it is too brief and lacks critical details, making it insufficiently informative for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's two parameters and lack of usage guidance, the description is incomplete. The existence of an output schema does not offset the missing parameter context and behavioral details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no information about the parameters (query and limit) beyond what the schema provides. Schema coverage is 0%, so the description should compensate but fails to do so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as searching ONS Beta API datasets by keyword, which is specific and distinguishes it from sibling search tools like search_govuk or search_constituencies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs alternatives, no prerequisites, and no exclusion criteria. It only implicitly indicates its scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search England planning applications via planning.data.gov.uk (optional reference filter).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| dataset | No | planning-application | |
| reference | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description does not disclose behavioral traits beyond the basic operation. No mention of pagination, rate limits, read-only nature, or response format. With no annotations, the burden falls on description, which is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence efficiently conveys primary purpose. Could be slightly expanded without bloat, but overall appropriate length.
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?
Provides source and optional filter, but lacks details on pagination parameters (limit/offset), default dataset, and return value structure. Output schema exists, reducing the need for return value explanation, but parameter details are still 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 has 4 parameters with 0% description coverage. Description only adds context for 'reference' as optional filter, leaving limit, offset, and dataset unexplained. Insufficient compensation for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action ('Search'), the resource ('planning applications'), the geographic scope ('England'), the data source ('planning.data.gov.uk'), and an optional filter ('reference'). This distinguishes it from sibling tools which target different data types.
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?
No guidance on when to use this tool versus alternatives such as search_constituencies or search_flood_areas. Lacks any when-not or context for optimal use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search data.gov.uk dataset metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure, yet it only states the purpose. It omits any behavioral traits such as whether the search is read-only, rate limits, or how results are returned.
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 very concise (one sentence, five words), but it is under-informative. While front-loaded, it sacrifices meaningful content for brevity, resulting in a borderline adequate score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two parameters, no annotation coverage, and an output schema (though not shown), the description is completely inadequate. It provides no context about how to formulate queries, what the output contains, or any constraints.
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 0%, and the description adds no information about the parameters. It does not explain what the 'query' parameter represents or how 'limit' affects results, leaving the agent without guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Search' and the specific resource 'data.gov.uk dataset metadata', distinguishing it from sibling tools like search_govuk (general gov.uk search) and search_ons_datasets (ONS-specific datasets).
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?
No usage guidelines are provided. The description does not specify when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
London tube/DLR/tram line status via TfL Unified API (requires TFL_APP_ID and TFL_APP_KEY).
| Name | Required | Description | Default |
|---|---|---|---|
| line_ids | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behaviors. It reveals the authentication requirement (TFL_APP_ID/TFL_APP_KEY) but fails to mention rate limits, error handling, caching, or what happens when line_ids is null. Significant gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence covering purpose, scope, data source, and auth is efficient. However, it omits parameter details that could be integrated without bloat. Still, it is well front-loaded and earns its words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, return value details are covered. However, the description does not explain what 'line status' entails (e.g., types of disruptions) or how to use the optional parameter. Moderate completeness for a simple 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 0%, so the description must explain parameters. It does not describe the format of 'line_ids' (e.g., line names, IDs, or separation style) nor the default behavior when null. This leaves the agent guessing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning line status for London tube/DLR/tram via TfL API. It distinguishes itself from sibling tools, which cover other UK public data sources, by mentioning the specific API and transport modes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking line status but does not provide explicit guidance on when to use this tool versus alternatives. It mentions the need for API credentials, which is helpful, but no exclusions or when-not-to-use scenarios are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Most tools target distinct data sources and actions, but there is slight overlap among search tools (e.g., search_ons_datasets vs search_public_datasets) and between location tools (lookup_postcode vs os_places_find_place). Descriptions help, but an agent might select the wrong search tool without careful reading.
Naming conventions are inconsistent: some tools use verb_noun (get_bank_holidays, list_flood_warnings), while others mix noun and verb (companies_house_company_profile, os_places_find_place). There is no uniform pattern, though most names are descriptive.
With 26 tools, the server is on the higher end but covers a wide range of UK public data sources, justifying the count. It could be slightly trimmed, but overall it feels appropriate given the breadth of domains (weather, crime, transport, etc.).
The tool set covers many key UK public data sources (ONS, Companies House, flood warnings, etc.) but misses several major ones like DVLA, NHS data, or land registry. For an 'open UK public data' server, there are notable gaps that could limit agent coverage.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
This MCP server provides seamless access to Malaysia's government open data, including datasets, w…
data.gov.uk MCP — UK national open-data portal (CKAN API).
Hosted MCP server for live public-data APIs and Skills for AI agents.
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/HappyMonkeyAI/OpenUKPublicDataMCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
