Loading ToolBench
MCP server for Elasticsearch integration with property search, geocoding, and semantic search capabilities using ELSER and E5 models
This server exhibits significant definition quality issues across all 4 tools. While tool names follow verb_noun conventions and input schemas are present with types, descriptions are severely underdeveloped, parameter descriptions lack detail, and output schemas are not documented. The server returns free-form text responses (via MCP's content/text pattern) rather than structured objects, making LLM consumption difficult. Error handling is minimal, failures return error text in content arrays without guidance on recovery or classification. The fastmcp framework abstracts some schema details, but the actual tool implementations show weak documentation and no validation guidance.
Geocode a location string into a geo_point.
Get the required parameters for the properties search template.
Get detailed information about a specific property by its ID.
Search for properties using the configured search template with support for semantic search, geolocation filtering, and advanced property criteria.
Output schemas not documented. All tools return free-form text via content/text arrays instead of structured objects with typed fields. LLMs cannot plan downstream tool calls or extract specific data reliably.
Tool descriptions are too short and lack context. Descriptions range 28 - 188 chars (baseline 194 chars median for A-tier tools). Most lack WHEN to use the tool, prerequisites, or what structure is returned.
search_properties accepts numeric parameters (latitude, longitude, distance, bathrooms, tax, maintenance, square_footage_min/max, home_price_min/max) but parameter descriptions lack explicit min/max constraints or valid ranges. LLMs may pass absurd values (e.g., latitude 999, distance -50).
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | <=2025-11-25 | v2 |
Error handling is minimal. All failures return plain text error messages in content arrays. No classification (retryable vs user-fixable vs fatal), no guidance on recovery (e.g., 'Try calling get_properties_template_params() first' or 'Check your Google Maps API key'), no actionable suggestions.
search_properties potentially returns unbounded result sets (no pagination documented). Tool description does not mention limit, offset, or next_cursor. Large result sets waste tokens and risk context window exhaustion.
Google Maps API key is a hidden dependency (injected via environment, checked at runtime). If missing, geocode_location fails with 'No Google Maps API key provided' but the tool description does not document this prerequisite or guide the user to set it.
get_properties_template_params returns parameters as both structured data (in 'data.parameters') and as text (in content). This dual representation is confusing and violates the principle of consistent output structure. Output should be a single, well-defined schema.