Skip to main content
Glama

Zip-Codes.com Location Intelligence: Spatial Analysis, Districts & 14+ Years of Demographics

Quick ZIP / ZIP+4 / reverse geocode

quick_zip
Read-onlyIdempotent

The fast, small answer for a postal code. Takes a US ZIP Code, a US ZIP+4, a Canadian FSA, a Canadian postal code, or a latitude,longitude pair, and returns the code's city, state or province, county, and whether it spans more than one county. Given a ZIP+4 it also returns the street ranges making up that delivery segment; given coordinates it reverse-geocodes to the code containing the point. zip_lookup accepts exactly the same inputs and returns the same ZIP+4 detail — choose this one when the answer only needs to be the code and its place, because the payload is about half the size and only the timezone enrichment is available here. Use zip_lookup for census, demographic, district or American Community Survey enrichments.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "code": "<code>"
    },
    "name": "quick_zip"
  }
}

Input Schema

NameRequiredDescriptionDefault
codeYesA US ZIP Code, ZIP+4, Canadian FSA, Canadian postal code, or a latitude,longitude pair. For example 90210, 90210-1234, M5V, M5V 2T6, or 34.10,-118.41.
api_keyNoYour ZIP-Codes.com API key, only when you cannot send it as the X-Api-Key or Authorization: Bearer header (for example a key bought with buy_credits in this conversation). Leave it out to use the free tier. It is never shown back in a response.
includeNoEnrichments to add. Only timezone is available on this tool; use zip_lookup for census, district, demographic and ACS enrichments.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / api_key
      Added value: +{
      +  "default": null,
      +  "description": "Your ZIP-Codes.com API key, only when you cannot send it as the X-Api-Key or Authorization: Bearer header (for example a key bought with buy_credits in this conversation). Leave it out to use the free tier. It is never shown back in a response.",
      +  "type": [
      +    "string",
      +    "null"
      +  ]
      +}
  2. Changed1 schema field changed
    • addedInput schema / properties / code / type
      Added value: +"string"
  3. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds genuinely non-structured behavior: payload is roughly half the size of zip_lookup's and only timezone enrichment is supported here. It also discloses how output changes with input shape (ZIP+4 returns street ranges, coordinates reverse-geocode). It does not mention error behavior for invalid/ambiguous codes, which keeps it short of a 5.

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?

Front-loads the differentiator ('The fast, small answer') and keeps output shape and sibling routing in a tight block. Slightly redundant in restating the zip_lookup comparison twice (payload size, then again for enrichments), but every sentence still carries routing or output information.

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 no output schema, the description carries the return-value burden and does so fully: city, state/province, county, multi-county flag, street ranges, and reverse-geocode behavior. Annotations cover the safety profile and the schema covers auth, so nothing an agent needs to call this correctly is missing.

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, but the description adds meaning the schema does not: the input form changes the response ('Given a ZIP+4 it also returns the street ranges', 'given coordinates it reverse-geocodes'). The api_key/free-tier behavior is left to the schema, which handles it well.

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?

States a specific verb and resource ('Takes a US ZIP Code... returns the code's city, state or province, county') and names the exact sibling it must not be confused with, zip_lookup. An agent can distinguish the two without opening either schema.

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?

Explicit routing rule: 'choose this one when the answer only needs to be the code and its place' versus 'Use zip_lookup for census, demographic, district or American Community Survey enrichments.' It also gives the selector criterion (smaller payload, timezone-only enrichment), so both when and when-not are covered.

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.