Loading ToolBench
MCP server for Machine Generated Content Feed API. Provides tools to search, filter, and retrieve US residential real estate market reports from the Content Feed API. Designed for easy discovery and use by LLMs.
Server provides 10 tools with complete input schemas and descriptions. Naming follows verb_noun convention (list_, search_, get_, lookup_). However, descriptions lack LLM-optimization guidance (many exceed 200 chars), parameter descriptions are minimal, and output schemas are entirely undocumented. No error handling guidance, no pagination metadata (total_count, next_cursor), and no tool annotations (readOnlyHint). Tools are read-only but this is not formally declared. Average tool description ~140 chars (acceptable range), but parameter descriptions average ~50 chars and lack format/constraint details. No security concerns (no secrets in params). Composition is sound, tools chain logically (lookup_cities → search_by_city). Baseline: 549 production tools average 18-char names (these average 22 chars, acceptable) and 194-char descriptions (these average 140 chars, slightly short but acceptable). Per-tool scores range 45 - 70; average 58.
Advanced search for real estate content with multiple filter criteria
Get the latest market report for a specific city. Use lookup_cities first if you're unsure of the exact city name.
Get the latest price analysis report for a specific city
Get a list of all available entity types in the real estate content feed that can be used for filtering content
Get all available values for a specific entity type (e.g., all report types, all city names
Get a list of all available report types in the database
Output schemas completely undocumented. No tool returns a documented response structure. LLMs cannot plan downstream calls or extract required fields (e.g., does search_by_report_type return report_id, title, date, url?). This violates pattern:tool and forces LLMs to guess field names.
No pagination metadata returned. Search tools accept page_num and page_size but responses lack total_count or next_cursor. Without knowing result cardinality, LLMs cannot plan iteration or detect when all results are fetched. Violates pattern:paginated-result.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 67 | 2026-07-28+ | v2 |
Get the exact city name formats available in the database before searching. Use this to find the correct city name format for use with search_by_city.
Search for real estate content by city name. IMPORTANT: The API requires exact city name matching. Use lookup_cities first to find the correct name format to use.
Search for real estate content by report type. Use list_report_types first if you're unsure about the exact report type to use.
Search for real estate content published within a specific date range
Parameter descriptions lack format/constraint details. E.g., 'page_size: Number of items per page (1-50)' is stated in description but not enforced in schema (no minimum/maximum). Date parameters say 'YYYY-MM-DD format' but no pattern constraint. LLMs cannot validate inputs before calling. Violates pattern:constrained-input.
No error handling guidance. Tools do not document what errors can occur (e.g., invalid city name, API rate limit, malformed date) or how to recover. Violates pattern:recovery-guide and pattern:error-classification.
No tool annotations. All tools are read-only but lack readOnlyHint annotation. This prevents clients from optimizing caching, retry logic, or permission checks. Violates current MCP spec (2026-07-28) tool annotation requirement.