Loading ToolBench
MCP server and REST API for QuantaRoute Geocoding API - Geocode addresses, lookup locations, process DigiPin codes
The QuantaRoute server has 13 tools with complete input schemas and descriptions. However, there are significant quality gaps that prevent a higher score. Strengths: all tools have input schemas with type definitions and basic descriptions. Weaknesses: (1) Output schemas are completely undocumented, no tool specifies what fields or structure callers should expect, violating the pattern:tool-schema requirement; (2) Descriptions are inconsistent in quality, some are good (geocode, reverse_geocode) but others are generic or marketing-focused ('🚀 REVOLUTIONARY'); (3) One tool (find_nearby_boundaries) is marked 'NOT YET IMPLEMENTED', creating a broken contract with agents; (4) Parameter constraints are missing for several tools (no enum for country, no range validation for coordinates despite having format hints); (5) Error handling guidance is absent, no tool describes what to do if the API fails, what errors are recoverable, or how to self-correct; (6) No tool indicates whether it modifies state or is read-only (all are READ_ONLY per metadata, but this is not reflected in descriptions per pattern:command-tool). The server sits at the border between fair (60-69) and good (70-79), it has solid structural foundations but lacks the refinement, constraint specificity, and user-centric guidance that lift tools from 'functional' to 'production-grade'.
Get autocomplete suggestions for addresses (minimum 3 characters).
Geocode multiple addresses in a single batch request (up to 100 addresses).
🚀 REVOLUTIONARY: Batch lookup for multiple locations. Each location can be specified by coordinates or DigiPin (up to 100 locations).
Convert latitude and longitude coordinates to a DigiPin code.
Find nearby postal boundaries within a specified radius (NOT YET IMPLEMENTED - Coming Soon). The backend endpoint /v1/location/nearby needs to be implemented first.
Geocode an address to get DigiPin code and coordinates. Returns location information including latitude, longitude, and DigiPin.
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract needed fields without knowing response structure (e.g., does geocode return {latitude, longitude, digipin} or {result: {lat, long, pin}}?). Violates pattern:tool and pattern:response-shaper.
Tool find_nearby_boundaries explicitly states 'NOT YET IMPLEMENTED - Coming Soon' in description. Registering unimplemented tools creates a broken contract, agents will attempt to call it and receive errors. Either remove it or implement it.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 55 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 50 | - | v1 |
Check API health status and availability.
Get live statistics about the Location Lookup service (total boundaries, states, divisions, etc.).
Get API usage statistics and quota information.
🚀 REVOLUTIONARY: Get administrative boundaries (pincode, state, division, locality) from coordinates. Provides precision that even government services don't offer.
🚀 REVOLUTIONARY: Get administrative boundaries from a DigiPin code.
Reverse geocode a DigiPin code to get coordinates and address information.
Validate a DigiPin format and check if it corresponds to a real location.
Marketing language ('🚀 REVOLUTIONARY') in tool descriptions for lookup_location_from_coordinates, lookup_location_from_digipin, batch_location_lookup. Descriptions should be factual and LLM-optimized, not sales-focused. This inflates descriptions past the actionable range and dilutes signal for tool selection.
Utility tools (get_usage, get_location_statistics, get_health) have minimal descriptions (under 20 chars effectively in actionable content). Descriptions should explain when and why an agent should call them, and what structure they return.
Parameter 'country' in geocode and batch_geocode is free-form string with no enum constraint, default value ('India'), or validation rule. Should declare country as enum of supported regions or include validation guidance.
Coordinate range hints in descriptions ('Latitude coordinate (-90 to 90)', 'Longitude coordinate (-180 to 180)') are informal. Should use JSON Schema minimum/maximum properties so clients and LLMs can validate before sending.
No error handling guidance in any tool description. If an API call fails (invalid address, unreachable service, rate limit), LLMs have no indication of what to do, retry, ask user, or fail. Violates pattern:recovery-guide.
No indication in descriptions whether tools are read-only vs state-modifying. All are marked READ_ONLY in metadata, but LLMs cannot see metadata, descriptions must explicitly state 'This operation does not modify data' (or vice versa) so agents know retry safety.
batch_geocode and batch_location_lookup accept arrays (addresses, locations) but lack descriptions of per-item success/failure semantics. If 1 of 100 addresses fails, does the tool return partial results or fail entirely? Does it return error indices?
autocomplete parameter 'limit' has a default (5) but description does not clearly state why or what happens if omitted. Also, constraint 'max: 10' is documented in description text but not in JSON Schema maxItems/maximum.