Skip to main content
Glama

Address Validate

lookup_address_validate
Read-only

Validate a freeform address and return structured components (street, city, state, postal code, country), GPS coordinates, and confidence score. Use when you need to verify or parse an address.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
addressYesFreeform address to validate

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds that the tool returns GPS coordinates and a confidence score, but it does not disclose potential failure modes (e.g., invalid addresses) or elaborate on network dependencies beyond what openWorldHint implies. It does not contradict the 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 two sentences: the first leads with the verb and outcome, listing return fields; the second provides a usage directive. There is no filler or redundant phrasing.

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?

The tool has only one parameter and no output schema, so the description carries the burden of documenting return values. It lists the structured components and confidence score, which is helpful. It lacks specifics on coordinate format or error behavior, but for a simple lookup tool this is adequate.

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?

The schema has 100% coverage for the single parameter 'address', with description 'Freeform address to validate.' The description's mention of 'freeform address' adds no additional semantic detail beyond the schema, so the baseline of 3 is appropriate.

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 explicitly states the action ('validate') and the resource ('freeform address'), and lists the output components (street, city, state, postal code, country, GPS coordinates, confidence score). This clearly distinguishes it from sibling lookup/decoding tools by focusing on address parsing and verification.

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

Usage Guidelines4/5

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

The description includes a direct usage directive: 'Use when you need to verify or parse an address.' It does not explicitly mention when not to use the tool or alternative tools, but no sibling tool is an obvious alternative for address validation, so the context is clear.

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.

Resources