Loading ToolBench
Consolidated Mexican Real Estate Aggregator platform API combining property search, AI-enhanced semantic search, and MCP integration for real estate listings
This MCP server exposes 19 real estate and admin tools via HTTP. Strengths: most tools have descriptions and structured input schemas with enums for constrained inputs (search_properties, semantic-search). Weaknesses: critical gaps in output schema documentation, no visible return types for any tool; descriptions are present but many are generic or underspecified; parameter descriptions lack actionable format/constraint details; admin and auth tools expose security risks (credentials in parameters, no permission gates documented); error handling and recovery guidance absent; tool annotations (readOnlyHint, destructiveHint, idempotentHint) not visible in code.
Conversational property search with context awareness using multi-turn conversation
Get documentation for a specific library with optional query filtering
Enhance search query with context and user preferences
Enhanced property search with up-to-date documentation context
Get list of supported libraries for documentation context
Retrieve API logs for administrative monitoring
Retrieve configured API providers
Get API statistics for administrative monitoring
No output schemas documented for ANY tool. Tools like getApiLogs, getApiStats, getApiProviders, get-libraries, logout, and me have no visible return type specification. LLMs cannot plan downstream operations or extract needed fields without knowing what the response structure is.
Admin tools (getApiLogs, getApiStats, getApiProviders, updateApiProvider) lack permission gates and have no documented security requirements. Critical operations should declare required permissions (e.g., 'admin:read', 'admin:write') and validate access server-side.
Auth tools (login, register, refresh) accept credentials as parameters (email, password, refreshToken). Secrets must never appear in tool parameters, they are logged in traces and prompt history. Use server-side secret injection or OAuth flow instead.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 35 | - | v1 |
Authenticate user with email and password to obtain access and refresh tokens
Logout current user and revoke refresh token
Get current authenticated user information
Get AI-powered neighborhood insights
Parse natural language search queries to extract property search criteria using GPT-4
Refresh authentication tokens using a valid refresh token
Register a new user account with email, password, and name
Extract property search criteria from natural language queries in Spanish or English
Semantic property search using natural language with optional LLM re-ranking
Find similar properties based on a given property
Update API provider configuration
Non-action-verb naming on admin endpoints: getApiLogs, getApiStats, getApiProviders use camelCase get* instead of verb_noun snake_case (e.g., list_api_logs, list_api_stats). LLMs infer intent from naming convention; mixed styles reduce clarity.
Parameter descriptions lack actionable constraints. 'userPreferences' in enhance-query is described as 'User preferences for search enhancement' but provides no schema, no examples, no format guidance. LLMs cannot determine what structure is expected.
Descriptions for tools without visible schemas (getApiLogs, getApiStats, get-libraries, logout, me) are generic and under 40 characters. These offer minimal guidance on WHAT to return, WHEN to call them, or how results differ from similar tools.
No tool annotations visible (readOnlyHint, destructiveHint, idempotentHint). The risk field in the evaluation shows 'WRITE' for auth/admin tools, but the actual MCP tool registration likely lacks these hints, preventing proper agent safety guardrails.
No error handling or recovery guidance documented. If semantic-search returns no results, or conversational-search fails to parse a message, LLMs have no guidance on what to try next (retry, reformulate, escalate). Responses should include actionable next steps.
Real estate tools lack pagination guidance. semantic-search accepts a 'limit' parameter (max 50) but does not document how to fetch additional results. If there are 100 matching properties and limit=20, how does the agent iterate? No cursor, offset, or next_token visible.
Tools designed for composition (search_properties → similar-properties, conversational-search → semantic-search) likely lack chaining IDs in responses. If search_properties does not return propertyId consistently, similar-properties cannot be called. No output schema visibility makes this impossible to verify, but it's a risk.