Skip to main content
Glama

Search the UK open-data registry

postcode_search_datasets
Read-onlyIdempotent

Search a curated registry of 45 UK open datasets and APIs for property and neighbourhood research.

Each entry records the dataset's home page, its machine-readable endpoint, format, licence, geographic coverage, update cadence, and the concrete questions it can answer. Use it to find the right source for something this server does not report directly — EPC ratings, planning applications, flood risk, council tax bands, bus timetables, air quality, ground stability, land ownership.

Args:

  • query (string, optional): free text over name, publisher, category, endpoint and questions

  • category (string, optional): category prefix, e.g. "Crime", "Transport", "Environment"

  • limit (number): 1-45, default 10

  • offset (number): pagination offset, default 0

  • response_format ('markdown' | 'json'): default 'markdown'

Returns: { total, count, offset, has_more, next_offset, datasets: [{ id, dataset, publisher, category, api, licence, coverage, update_frequency }] }

Examples:

  • "Where do I get EPC data?" -> query="EPC"

  • "What flood datasets are there?" -> query="flood"

  • "List every transport source" -> category="Transport", limit=20

Follow up with postcode_get_dataset for the full entry including API docs and the questions it answers.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum results (default 10)
queryNoFree text matched against dataset name, publisher, category, API endpoint and the questions each dataset answers. Omit to list everything.
offsetNoResults to skip, for pagination
categoryNoFilter by category prefix, e.g. "Crime", "Transport", "Environment"
response_formatNomarkdown

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
countYes
totalYes
offsetYes
datasetsYes
has_moreYes
next_offsetNo

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful behavioral context beyond that: it is a curated registry of exactly 45 datasets, returns paginated results with has_more/next_offset, and supports both markdown and JSON output. No 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.

Conciseness4/5

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

The description is somewhat long but well-organized with Args, Returns, and Examples sections. It front-loads the purpose and every section earns its place, though a bit of redundancy exists between the schema and the Args list. Overall, it is efficient for the tool's complexity.

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

Completeness5/5

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

For a search tool with 5 optional parameters and an output schema, this description is complete. It explains what the tool searches, how to use it, what it returns, and the follow-up tool for deeper detail. The presence of an output schema reduces the need to explain return shape, but the description covers it anyway.

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 description coverage is high (80%), and each parameter already has a description. The tool description reinforces this by explaining query matches 'name, publisher, category, endpoint and questions', giving concrete category examples, and providing example queries (e.g., 'query="EPC"'). This adds practical value beyond the 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?

The description uses a specific verb ('Search') with a clear resource ('curated registry of 45 UK open datasets and APIs') and scope ('for property and neighbourhood research'). It distinguishes from sibling tools by explicitly positioning this as a search/discovery tool, while noting 'Follow up with postcode_get_dataset for the full entry'.

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?

Provides explicit usage context: 'Use it to find the right source for something this server does not report directly' and lists concrete use cases (EPC ratings, flood risk, etc.). It also names the alternative tool for follow-up, making the division of responsibility between siblings clear.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.7/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: compare does side-by-side multi-postcode analysis, report does a single-postcode deep dive, lookup resolves geography, search_datasets finds datasets, and get_dataset retrieves a full dataset entry. The descriptions explicitly cross-reference when not to use each tool, eliminating any ambiguity.

Naming Consistency5/5

All tool names follow a consistent pattern: lowercase snake_case with a 'postcode_' prefix followed by a verb_noun (compare, get_dataset, lookup, report, search_datasets). No mixed conventions or vague verbs like 'process' or 'execute'.

Tool Count5/5

At 5 tools, the set is tightly scoped for a UK house-search data server. Each tool covers a distinct operation (lookup, report, compare, dataset search, dataset details) and neither feels redundant nor bloated. This is well within the ideal 3-15 range.

Completeness5/5

The tool set provides a full workflow: look up a postcode's geography, get a comprehensive neighbourhood report, compare multiple postcodes, search for external datasets to fill gaps (e.g., EPC, flood risk), and retrieve full dataset details. There are no dead ends; every tool has a clear follow-up and the coverage matches the stated purpose.