APIVerve

Street Address Parser

StreetAddressParser

Read-only

Street Address Parser: Street Address Parser is an address parsing API that breaks raw US street addresses into structured location components. Pass any single-line address string to extract the building number, directional, street name, street type, unit, city, state abbreviation, and postal code. Set standardize=true to get the address type (street, PO box or intersection) free, and on paid plans the mailing-format delivery line, last line and ZIP+4. (Cost: 2 credits)

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": {
      "address": "<address>"
    },
    "name": "StreetAddressParser"
  }
}

Input Schema

Name	Required	Description	Default
`address`	Yes	The street address to parse
`standardize`	No	Add a standardized block: the address type, plus on paid plans the delivery line, last line and ZIP+4

Output Schema

Name	Required	Description
`data`	No
`error`	No	Error message, null on success
`status`	No	"ok" on success

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 7, 2026

TDQS

A3.7/5.0

Behavior4/5

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

The annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds real value beyond that: it discloses the 2-credit cost, that the address-type portion of the standardize block is free while delivery line/last line/ZIP+4 require a paid plan, and that input is US-only. Missing is any statement about behavior on unparseable addresses.

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 body is dense and front-loaded, leading with the core function and ending with the cost note. The only waste is the opening redundancy 'Street Address Parser: Street Address Parser is an address parsing API', which restates the name and title twice before the useful content begins.

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

Completeness4/5

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

An output schema exists, so the enumerated fields are a bonus rather than a necessity, and the description covers cost, plan gating and input format adequately for a two-parameter parser. Remaining gaps are how it handles malformed or non-US addresses and any input length limits.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both parameters are already documented in the schema, and the standardize description there mirrors the paid-plan caveat. The description reinforces that address accepts any single-line string, but adds no new syntax, format or constraint details beyond the schema. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb (breaks/parses) and resource (raw US street addresses) and enumerates exactly which components are extracted (building number, directional, street name, street type, unit, city, state, postal code). An agent can tell this is a parsing/extraction tool rather than a lookup. It does not, however, differentiate itself from nearby siblings like ReverseGeocode, ZipCodesLookup or ContactExtractor.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: it says to pass a single-line address string and sets the scope to US addresses, and it explains when to flip standardize=true. There is no explicit when-not guidance, no mention of what happens with non-US or multi-line input, and no pointer to alternative tools for geocoding or ZIP lookups.

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

All APIVerve tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.