Loading ToolBench
CLI, MCP and Skills for the world's property portals — search and monitor listings across 9 providers in 9 countries
The server has 6 tools with complete input schemas and explicit descriptions. Naming follows verb-noun conventions (property_search, property_providers, property_locations, property_dedupe, property_filter, property_compare). However, descriptions are sparse to minimal (10-100 chars), many parameter descriptions are missing entirely, and output schemas are not documented. Error handling is present but minimal. Tool composition is reasonable but some parameters could be clearer.
Compare property snapshots and identify new listings, removals, and price changes.
Deduplicate normalized property listings conservatively.
Filter property listings and optionally explain removals.
Find known provider location IDs or coordinate shortcuts.
List available providers, countries, transactions and authentication requirements.
Search property providers by country and return normalized property-listing.v1 JSON.
Output schemas not documented. Tool definitions show input schemas but no description of output structure, forcing LLMs to infer response fields. Per patterns, 'Document the output schema' is critical for tool chaining.
Parameter descriptions are sparse. Examples: property_search has 'location' (required) with no description, 'country' described only as 'ISO country code' (18 chars, below 20-char minimum for actionable descriptions). Many parameters like 'dedupe_threshold', 'candidate_threshold', 'rank', 'profile' have no descriptions at all. Per patterns, every parameter must have a non-empty description.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2026-07-28+ | v2 |
Tool descriptions are under 100 chars and lack WHEN/WHY context. Example: 'property_search' = 'Search property providers by country and return normalized property-listing.v1 JSON.' (99 chars) does not explain when to call this vs property_locations, or what the return contains. When should the LLM call it? What does it return?
No input validation or actionable error messages. Code shows ValueError and Exception handling in search_properties but no structured error response guiding the LLM on recovery. Per patterns, error responses must tell the LLM what to do next and categorize as retryable/user-fixable/fatal.
Parameter naming inconsistency and ambiguity. 'property_search' mixes parameter styles: 'provider' (enum) vs 'portal' (alias, undocumented); 'location' vs 'location_id'; 'state' (US-specific, undescribed). Also, 'dedupe' is a boolean flag but also a separate tool (property_dedupe), creating tool-level confusion. Per patterns, tool names must disambiguate and parameters must have clear, consistent naming.
No pagination or result limiting documented. property_search returns all properties across multiple pages (default max_pages=3) but no documented limit on total count returned. Per patterns, tools returning lists must state the limit and support pagination to prevent context window exhaustion.
Missing dependency hints. property_dedupe, property_filter, and property_compare all require a pre-existing properties array (from property_search), but descriptions do not state 'Call property_search first.' Per patterns, include dependency hints so agents understand multi-step workflows.