Click on "Deploy 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., "@postal-lookup-mcp what city is ZIP 90210 in?"
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.
Resolve any postal/ZIP code to its place name, state/region, and coordinates. Free, in one command.
pip install postal-lookup-mcp # or: uvx postal-lookup-mcpThen ask your agent: "what city is ZIP 90210 in?" or "where is postal code SW1A in the UK?"
No API key. No signup. Free.
Tool | What the model sees it for |
| Resolve a postal/ZIP code to place name(s), state/region, and lat/lon. "What city is ZIP 90210 in?", "where is postal code X in country Y?" |
country_code is a 2-letter ISO code (US, GB, DE, ...). postal_code format varies by country. Some postal codes span multiple places, in which case all of them come back in places[].
Related MCP server: sthan-io
> lookup_postal_code("us", "90210")
{
"country": "United States",
"country_abbreviation": "US",
"postal_code": "90210",
"places": [
{
"place_name": "Beverly Hills",
"state": "California",
"state_abbreviation": "CA",
"latitude": "34.0901",
"longitude": "-118.4065"
}
],
"attribution": "Postal data by Zippopotam.us (zippopotam.us)"
}A code that isn't recognized comes back as a clean error, never a crash:
> lookup_postal_code("us", "00000")
{
"error": "No place found for postal code \"00000\" in country \"US\" — check the code and the 2-letter country code (US, GB, DE, ...), or the country may not be covered.",
"attribution": "Postal data by Zippopotam.us (zippopotam.us)"
}This server is part of the Lulu Ads network:
tool results may carry one clearly labeled, disclosed sponsored data field
(never instructions, never hidden). That sponsorship pays the hosting, so the
lookup stays free. Fail-open by design — if the ads backend is slow, down,
or (as with a local install) has no credentials at all, the tools behave
exactly like an unmonetized server.
Run your own MCP? The same one-line integration is open to every publisher — getlulu.dev/publishers, 70% rev share.
Postal data by Zippopotam.us, a free community lookup service covering ~60 countries. This project is not affiliated with Zippopotam.us.
pip install fastmcp lulu-ads httpx uvicorn
MCP_TRANSPORT=http POSTAL_LOCAL_DEV=1 python server.py # serves http://localhost:8080/postal/mcpResolve a postal/ZIP code to its place name(s), state/region, and
coordinates. country_code is a 2-letter ISO code (US, GB, DE, ...);
postal_code format varies by country (e.g. "90210" for the US,
"SW1A 1AA" style outward codes for the UK). Use for "what city is ZIP
90210 in", "where is postal code X in country Y", or any question
that needs a place name/region/lat-lon from a postal code -- not for
the reverse (place name to postal code) or for full street address
lookup. Some postal codes span multiple places, in which case all of
them are returned. Returns an error dict (never raises) if the code
isn't recognized for that country.
| Name | Required | Description | Default |
|---|---|---|---|
| postal_code | Yes | ||
| country_code | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation is present, and the description adds valuable behavioral context beyond it: description of multi-place postal codes, retourning all matches, and the error dict behavior (never raises). These are non-obvious behaviors that help the agent anticipate outcomes.
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 well-structured and front-loaded with purpose, followed by usage exclusions and behavioral edge cases. Every sentence adds distinct value, with no redundancy or filler.
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 moderate complexity (2 params, multiple return possibilities), the description covers purpose, parameter formats, usage exclusions, edge cases, and error behavior. It provides a complete picture even without an output schema.
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%, but the description fully compensates by explaining both parameters: country_code as a 2-letter ISO code with examples, and postal_code with country-specific format examples. This provides essential semantic detail missing from 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 uses a specific verb ('Resolve') and clearly identifies the resource (postal/ZIP code to place names, state/region, coordinates). It distinguishes itself from reverse lookups and full street address lookup, making the tool's purpose 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 provides explicit when-to-use examples ('what city is ZIP 90210 in') and states what it is not for ('not for the reverse... or for full street address lookup'). This clearly guides an agent on when to select this tool over alternatives.
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_postal_codeScored across 1 tool
With only one tool, there is no possibility of confusing it with others. The description clearly delineates what it does and does not do (e.g., not reverse lookup or full address lookup), so an agent can unambiguously select it for postal-code-to-place queries.
The single tool name 'lookup_postal_code' follows a clear verb_noun pattern and is self-descriptive. Consistency is trivially satisfied since there's only one name, but the name itself is well-structured and aligns with common conventions.
One tool is below the typical 3-15 range, but the server's scope is extremely narrow: resolving postal codes to place information. The single tool fully addresses this purpose, so the count feels slightly under but reasonable rather than thin or inadequate.
The tool provides complete coverage for its stated domain: it resolves postal codes to place names, region, and coordinates, handles multi-place spans, and returns error dicts for unrecognized codes. No obvious missing operations for the declared purpose of postal code lookup.
Zippopotam MCP — wraps Zippopotam.us ZIP/postal code API (free, no auth)
Free, keyless postal/ZIP code lookup: place name(s), state/region, and coordinates.
Postal code lookup with place names and coordinates for 60+ countries. Via Zippopotam.us.
Unofficial MCP server for the public PortlandMaps property/permit/zoning API. Not city-affiliated.
