Skip to main content
Glama

Look up UK postcode geography

postcode_lookup
Read-onlyIdempotent

Resolve a UK postcode to its geography — coordinates, local authority, ward, constituency, LSOA/MSOA/output area, police force, rural-urban class and deprivation rank.

One fast call with no downstream data fetching. Use it to check a postcode exists, to get the codes needed for other datasets, or when you only need where somewhere is rather than what it is like.

Args:

  • postcode (string): UK postcode, spaces optional

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

Returns: Coordinates, administrative geography, statistical geography codes (LSOA/MSOA/OA — these are the keys most UK open datasets are published against), and the deprivation rank with the index it came from.

Examples:

  • "Where is SW11 1AA?" -> postcode="SW11 1AA"

  • "What LSOA covers M1 1AE?" -> postcode="M1 1AE"

  • "Is XY1 2AB a real postcode?" -> postcode="XY1 2AB" (returns an error with suggestions)

Don't use when: you want data about the area — use postcode_report instead.

Note: deprivation ranks are NOT comparable between UK nations. Each nation ranks its own areas against its own index, over a different number of areas; the index and its size are returned so you do not compare them by mistake.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
postcodeYesA UK postcode, e.g. "SW11 1AA"
response_formatNo'markdown' to read, 'json' for the structured recordmarkdown

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
lsoaYes
msoaYes
wardYes
regionYes
countryYes
latitudeYes
postcodeYes
longitudeYes
output_areaYes
rural_urbanYes
constituencyYes
police_forceYes
national_parkYes
local_authorityYes
deprivation_rankYes
deprivation_indexYes

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the read-only/idempotent annotations, the description discloses critical behavioral nuances: deprivation ranks are NOT comparable between UK nations, invalid postcodes return an error with suggestions, and the call is fast with no downstream fetching. This provides rich context without contradicting 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?

The description is well-structured with distinct sections (summary, usage, args, returns, examples, don't use, note). Although relatively long, every sentence earns its place, and the most important info is front-loaded in the first sentence.

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

Completeness5/5

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

With only 2 parameters, an output schema present, and strong annotations, the description still adds essential context: examples, error behavior, cross-nation comparability warning, and a clear pointer to sibling tools. It is complete for an agent to select and invoke this tool 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%, so the baseline is 3. The description adds value by noting postcode spaces are optional and provides concrete natural-language examples mapping to parameter values, which is beyond the schema's basic descriptions.

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 ('Resolve') and resource ('UK postcode to its geography'), enumerating exactly what is returned (coordinates, local authority, ward, constituency, etc.). It also distinguishes itself from siblings by noting it is for checking existence and getting codes, not for area data.

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 when to use ('check a postcode exists', 'get codes needed for other datasets', 'when you only need where somewhere is') and when not to ('want data about the area'), naming the alternative tool (postcode_report). This meets the highest bar for usage guidance.

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.