Loading ToolBench
AI-powered features for the real estate platform including property analysis, market trends, recommendations, and AI assistant capabilities
This MCP server demonstrates basic tool structure but falls significantly short of production quality. All 11 tools have action verbs (get_) and are READ_ONLY, which is good. However, descriptions are uniformly generic (8-60 chars), parameter descriptions are missing entirely, and output schemas are not documented. The tool implementations are stubs returning hardcoded placeholder data. Input schemas exist for all tools and are properly typed, but lack descriptions for most parameters. No error handling guidance, no pagination support despite list-returning tools, and no tool annotations. The server is HTTP-based (positive for transport), but the definition quality is weak across nearly every dimension except naming conventions.
Get comparable properties for valuation
Get investment analysis for a location
Get AI suggestions to optimize a listing
Get market statistics for a specific location
Get market trends for a location
Get statistics for a neighborhood
Get detailed information about a specific property by ID
Generic or missing parameter descriptions. Most tools (e.g. get_market_trends, get_neighborhood_stats, get_investment_analysis) have parameters with no descriptions or only property names repeated. LLMs cannot infer what 'location', 'timeframe', 'property_type', 'status', 'limit' mean without explicit descriptions.
No output schemas documented. All tools return hardcoded placeholder dicts (e.g. {'location': ..., 'price_trend': ...}) but LLMs are not told what fields to expect. Without documented output structure, agents cannot plan downstream calls or extract required data reliably.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 52 | - | v1 |
Get price history for a property
Get listings for a seller
Get seller performance metrics
Search for properties based on criteria
Tool descriptions are too short (8 - 60 chars, baseline 194). Examples: 'Get market trends for a location' (32 chars), 'Get statistics for a neighborhood' (34 chars), 'Get seller performance metrics' (30 chars). These fail to explain WHEN to use each tool vs similar ones (e.g. get_market_trends vs get_market_statistics), or what the data includes.
No pagination or result limits specified. search_properties accepts a 'limit' parameter but no description explains the range (1 - 100?), what happens if omitted, or whether pagination via offset/cursor is supported. Tools returning lists (search_properties) should declare max results to prevent context overflow.
No error handling guidance. None of the tools document recovery paths. E.g. if get_property_details fails because property_id doesn't exist, what should the LLM do? Should it try search_properties? No guidance given.
Potential confusion between similar tools. get_market_trends, get_market_statistics, and get_neighborhood_stats all fetch data about locations/neighborhoods but lack descriptions distinguishing them. An LLM cannot tell whether to call get_market_trends or get_market_statistics for price trends.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). While all tools are READ_ONLY (correct), this is not explicitly declared in the tool definitions, relying on Risk metadata in external context rather than the MCP spec.
All tool implementations are stubs returning hardcoded data. This is acceptable for a proof-of-concept but not production-ready. No actual integration with real estate data sources, no rate limiting, no caching strategy documented.
Enum constraints present (timeframe, status) but not all enum params are consistent. get_seller_listings has status enum ['active', 'sold', 'all'] but other tools lack enums for similar concepts. Inconsistency forces LLMs to guess valid values.