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., "@Zyfy MCP Server What's the flood risk at SW1A 2AA?"
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.
MCP server for Zyfy — UK postcode and vehicle intelligence for Claude, Cursor, and other AI agents.
Add this server to Claude Desktop, Claude Code, or Cursor and ask natural language questions about UK postcodes and vehicles. No code required.
Node.js 18 or later
A Zyfy API key — sign up free at zyfy.uk (free tier includes 100 requests/month). Your key will look like ea_live_....
Related MCP server: homedata-mcp
Add to your Claude Desktop configuration file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json
{
"mcpServers": {
"zyfy": {
"command": "npx",
"args": ["-y", "@zyfy-uk/mcp"],
"env": {
"ZYFY_API_KEY": "ea_live_your_key_here"
}
}
}
}Restart Claude Desktop after saving the file.
Add a .mcp.json file in your project root:
{
"mcpServers": {
"zyfy": {
"command": "npx",
"args": ["-y", "@zyfy-uk/mcp"],
"env": {
"ZYFY_API_KEY": "ea_live_your_key_here"
}
}
}
}Note: Do not commit
.mcp.jsonif it contains your API key — add.mcp.jsonto your.gitignore.For a global setup (applies to all projects), add the same block to
~/.claude.jsoninstead.
The same .mcp.json format works in Cursor and any other MCP-compatible client.
Tool | Description |
| Flood risk, crime rate, broadband coverage, average property price, deprivation index (IMD), and MP details for any UK postcode |
| Make, MOT history, tax/MOT status and expiry, ULEZ compliance, safety score, and odometer trend for any UK vehicle registration |
| Full enrichment data for the nearest postcode to a lat/lon coordinate |
| All postcodes within a radius of a lat/lon coordinate, each with full enrichment data |
See zyfy.uk/docs for the full response schema and signal reference.
What's the flood risk at SW1A 2AA?
Is AB12 CDE ULEZ compliant, and when does its MOT expire?
What's the average property price and crime rate for the postcode nearest to 51.5074, -0.1278?
List all postcodes within 500 metres of 51.5, -0.1 and their flood risk bands.
Each tool call uses one quota unit from your Zyfy account. postcodes_within uses one unit per postcode returned. Your remaining quota is included in every response. See zyfy.uk/pricing for plan details.
When your quota is exhausted, tools return a message with the reset date and a link to upgrade. When you hit the per-minute rate limit, tools return a message with how many seconds to wait.
If a response includes "enrichmentPending": true, Zyfy is still processing that record in the background. The result contains the best available data — retry in a few seconds for a complete result.
MIT
Look up enriched data for a UK postcode. Returns geographic signals (region, constituency, rural/urban classification), risk signals (flood risk for rivers/sea and surface water, crime rate band), property signals (average price, EPC average), broadband coverage (superfast, ultrafast, gigabit, 4G, 5G), deprivation index (IMD decile), and local MP details. Northern Ireland (BT prefix) postcodes are not supported.
| Name | Required | Description | Default |
|---|---|---|---|
| postcode | Yes | UK postcode, e.g. 'SW1A 2AA' or 'SW1A2AA' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It implies a read-only lookup by listing returned data, but does not explicitly state it is non-destructive, mention authentication, rate limits, or other behaviors.
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 paragraph that front-loads the main purpose, but it lists many data categories, making it slightly verbose. Every sentence adds value, but could be more 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?
With no output schema, the description compensates by listing all categories of returned data, providing sufficient context for an agent to understand the output. It also notes the unsupported region, making it complete for its complexity.
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 100% with a description and example for the only parameter 'postcode'. The description adds no new semantic meaning beyond the schema's explanation.
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 'Look up enriched data for a UK postcode' and lists specific data categories (geographic, risk, property, broadband, deprivation, MP details), clearly distinguishing it from siblings like 'nearest_postcode' and 'postcodes_within'.
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 explicitly states it is for UK postcodes and notes that Northern Ireland (BT prefix) postcodes are not supported, providing a clear when-not-to-use condition. It does not name alternative tools but the sibling names imply different purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up enriched data for a UK vehicle by registration mark. Returns make, colour, fuel type, engine capacity, year of manufacture, tax status and expiry, MOT status and expiry, days remaining until MOT/tax expires, ULEZ compliance, computed safety score, condition score, odometer trend versus fleet average, and MOT history summary with advisory and failure counts.
| Name | Required | Description | Default |
|---|---|---|---|
| registration | Yes | UK registration mark, e.g. 'AB12 CDE' or 'AB12CDE' |
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 describes the returned data but does not mention side effects (it appears read-only), rate limits, error conditions, or authorization requirements. This is insufficient for a tool with no annotations.
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 starts with the purpose but then lists many fields in a dense, unstructured manner. While complete, it could be more readable with bullets or shorter sentences. The essential information is present but not optimally organized.
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 tool (one parameter, no output schema, no annotations), the description provides a comprehensive list of return fields. However, it lacks details on error cases (e.g., missing or invalid registration), performance expectations, or what happens if data is unavailable. This is adequate but not thorough.
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 100% for the single parameter 'registration'. The description adds format guidance with examples ('e.g., AB12 CDE or AB12CDE'), which helps the agent format input correctly. This extra detail raises the score above baseline.
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's action: 'Look up enriched data for a UK vehicle by registration mark.' It lists specific fields returned, making the purpose unmistakable. Sibling tools are all postcode-related, so this tool is well-differentiated.
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 UK vehicle lookups by registration mark. It does not explicitly state when not to use it or provide alternatives, but the context of siblings (postcode tools) and the single parameter make usage straightforward. An exclusion for non-UK vehicles is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the nearest UK postcode to a latitude/longitude coordinate and return its full enrichment data. Useful when you have coordinates and need the corresponding postcode along with its risk and demographic signals.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | Latitude (WGS84), e.g. 51.5074 | |
| lon | Yes | Longitude (WGS84), e.g. -0.1278 | |
| radius | No | Search radius in metres. Default 1000, maximum 10000. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description must cover behavior. It mentions returning 'full enrichment data' and 'risk and demographic signals', which is good. However, it doesn't explain what happens if no postcode is found, radius effects, or coordinate validity. Adequate but has 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?
Two short sentences, front-loaded with action and purpose. Every word earns its place; no redundancy.
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 no output schema or annotations, the description explains what it does, when to use it, and what it returns (enrichment data). Could mention radius or error states, but overall sufficient for a simple geospatial 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 description coverage is 100% (all parameters have descriptions in the schema). The tool description adds no further parameter guidance beyond reinforcing 'latitude/longitude coordinate'. Baseline 3 is appropriate.
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 finds the nearest UK postcode to given coordinates and returns enrichment data. It distinguishes from siblings: lookup_postcode retrieves by code, postcodes_within returns multiple, while this tool finds the single nearest from a coordinate.
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 a clear use case ('when you have coordinates and need the corresponding postcode'). It implies when to use but does not explicitly mention when not to or compare with postcodes_within.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return all UK postcodes within a given radius of a latitude/longitude coordinate, each with full enrichment data. Results are ordered by distance ascending. Each returned postcode costs one quota unit. Requires a Starter plan or above. Maximum radius 5000 metres.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | Latitude (WGS84), e.g. 51.5074 | |
| lon | Yes | Longitude (WGS84), e.g. -0.1278 | |
| radius | No | Search radius in metres. Default 1000, maximum 5000. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It discloses ordering (distance ascending), cost (one quota per postcode), requirements (Starter plan), and max radius (5000m). Missing details on error handling or rate limits, but the disclosed info is substantial.
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, consisting of four sentences that front-load the purpose, then add ordering, cost/requirements, and a size constraint. Every sentence serves a purpose with no redundancy.
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?
While the description covers key behaviors, it lacks details about the return format (what 'full enrichment data' contains) and does not mention pagination or limits on the number of postcodes returned. This is a gap for a tool that could return many results.
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 100%, but the description adds value by explaining the radius unit, default, and max, and clarifying that results are ordered by distance. It reinforces the coordinate reference (WGS84) and adds behavioral context not in the schema.
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 returns all UK postcodes within a radius of a lat/lon coordinate with full enrichment data. It distinguishes from sibling tools like 'nearest_postcode' which likely returns a single nearest postcode, and 'lookup_postcode' for a specific 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?
The description provides clear context on when to use the tool (to get all postcodes within a radius) and includes constraints (Starter plan required, quota cost, max radius). However, it does not explicitly contrast with alternatives or state 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0lookup_postcodelookup_vehiclenearest_postcodepostcodes_withinScored across 4 tools
Each tool serves a distinct purpose: postcode enrichment by code, by coordinates, radius search, and vehicle lookup. No overlap between tools, making selection unambiguous.
All tool names use lowercase and underscores, but they mix verb+noun (lookup_postcode, lookup_vehicle) with descriptive phrases (nearest_postcode, postcodes_within). While readable, the pattern is not perfectly uniform.
4 tools is well-scoped for a focused UK data enrichment server. Each tool provides a distinct capability without unnecessary complexity.
Covers core postcode lookups (by code, coordinates, radius) and vehicle enrichment. Minor gaps like address lookup or reverse geocoding for addresses are absent, but the set is coherent for its stated domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Query UK Parliament, elections, crime stats, ONS census data, and national archives
Search UK companies, land registry prices, charities, OS locations, and traffic data
UK area & property intelligence for AI agents: reports, EPC, comparables, with source provenance.
UK property research tools - crime stats, schools, demographics, valuations for AI.
