Loading ToolBench
Wrapper architecture MCP server for Precisely APIs supporting geocoding, address verification, property data, risk assessment (flood, wildfire, fire, earthquake, coastal), crime data, demographics, and more. Supports both stdio (default) and HTTP transports.
The server defines 18 tools with reasonable input schemas and descriptions, but has critical gaps in parameter documentation, output schema definition, and error handling. All tools are explicitly registered with names, descriptions, and JSON Schema input definitions. However, most parameter objects lack individual type and description documentation. No output schemas are documented anywhere in the codebase. Description lengths are adequate (100-200 chars) but lack LLM-friendly structure about when to use the tool vs similar alternatives. The tools are well-named with action verbs (geocode, verify_address, lookup, parse_address, get_property_data, etc.) following the verb_noun pattern. Naming is clear and internally consistent. However, several tools have object-type parameters (address, preferences) that are completely undocumented, LLMs cannot understand what fields these objects should contain. All tools are read-only (good for safety) but lack any error recovery guidance or per-item failure handling for batch operations.
Address autocomplete suggestions. Example: {'address': {'addressLines': ['1700 District'], 'country': 'USA'}, 'preferences': {'maxResults': 5}}
Autocomplete postal codes and cities. Example: {'address': {'type': 'POSTAL', 'postAddress': '12180', 'country': 'USA'}, 'preferences': {'maxResults': 5}}
Express autocomplete (V2). Example: {'address': {'addressLines': ['350 Jordan'], 'country': 'USA'}, 'preferences': {'maxResults': 5}}
Convert address to coordinates. Example: {'address': '42 Valley Of The Sun Dr, Fairplay, CO 80440', 'country': 'USA'}
Get coastal risk. Example: {'address': '123 Ocean Ave, Miami, FL', 'country': 'US'}
Get earthquake risk. Example: {'address': '123 Main St, San Francisco, CA', 'country': 'US'}
Object-type parameters (address, preferences) completely undocumented. 'address' is {'type': 'object'} with no properties or nested descriptions. LLMs cannot determine what fields to pass (addressLines? country? postAddress?). This affects autocomplete, autocomplete_postal_city, autocomplete_v2, and lookup.
No output schemas documented anywhere. Tool descriptions show examples in input parameters but never describe what fields the response contains, their types, or structure. Agents cannot plan downstream tool calls without knowing what data is available. For example, does geocode return {'latitude': number, 'longitude': number, 'confidence': number} or {'coords': {...}, 'address_components': [...]}?
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 54 | <=2025-11-25 | v2 |
Get flood risk by address. Example: {'address': '2755 Milwaukee St, Denver, 80238 CO', 'country': 'US'}
Get historical weather risk. Example: {'address': '123 Main St, Boston, MA', 'country': 'US'}
Get property attributes (bedrooms, bathrooms, etc). Example: {'address': '2755 Milwaukee St, Denver, 80238 CO', 'country': 'US'}
Get property information. Example: {'address': '42 Valley Of The Sun Dr, Fairplay, CO 80440', 'country': 'US'}
Get property fire risk. Example: {'address': '123 Main St, Boston, MA', 'country': 'US'}
Get property replacement cost. Example: {'address': '2755 Milwaukee St, Denver, 80238 CO', 'country': 'US'}
Get wildfire risk by address. Example: {'address': '2755 Milwaukee St, Denver, 80238 CO', 'country': 'US'}
Lookup address by PreciselyID. Example: {'keys': [{'key': 'P0000GL41OME', 'country': 'USA', 'type': 'PB_KEY'}]}
Parse single address. Example: {'address': '1700 District Ave #300, Burlington, MA 01803'}
Parse multiple addresses (max 10). Example: {'addresses': [{'id': '1', 'address': '123 Main St, Boston, MA 02101'}, {'id': '2', 'address': '456 Oak Ave, Denver, CO 80203'}]}
Convert coordinates to address. Example: {'lat': 39.5501, 'lon': -105.9999, 'country': 'USA'}
Verify and standardize address. Example: {'address': '1600 Pennsylvania Ave, Washington DC', 'country': 'USA'}
No error handling documentation or recovery guidance. Descriptions do not explain what happens when an address is not found, API rate limits are hit, or invalid input is provided. Agents have no guidance on whether failures are retryable or require user intervention.
Parameter descriptions missing for complex inputs. The 'keys' parameter in lookup is an array of objects with 'key', 'country', 'type' fields, but none of these nested properties are documented. What does 'type' expect? Is 'PB_KEY' the only valid value? Can 'country' be optional?
Batch operation (parse_address_batch) lacks per-item failure reporting. The description does not specify whether the tool will partially succeed if 3 of 5 addresses fail to parse, or fail entirely. Agents cannot plan error recovery without knowing failure granularity.
Default country values ('USA', 'US') hardcoded in examples but inconsistently applied. Some tools default to 'USA', others to 'US'. This inconsistency is minor but adds friction, LLMs may be confused whether both mean the same region.