Loading ToolBench
FastAPI-based MCP server that provides AI agents with API discovery and inspection capabilities through semantic search of OpenAPI specifications
This server has significant definition quality issues that prevent production use. Tool names follow basic verb conventions (find-, get-), but descriptions lack critical LLM-optimization details. Parameter schemas are present but minimally documented. Most critically, the server uses HTTP/FastAPI with custom tool endpoints (/tools/*) rather than proper MCP protocol registration, making tool definitions inferred rather than explicitly registered. Output schemas are not documented. Error handling is generic HTTP exceptions without actionable recovery guidance. The server appears to be a FastAPI wrapper around an API search engine, not a true MCP server with proper tool definitions.
Search for available API endpoints based on natural language intent. Use 'service' to filter by specific microservices (product, cart, payment, shipping).
Get the complete OpenAPI specification for a service. This allows you to "read" the full manual after "finding" the right chapter.
Tool definitions are NOT explicitly registered via MCP protocol. Tools are inferred from HTTP POST/GET endpoints (/tools/*) without proper MCP ToolCall registration. This violates the MCP specification and prevents standard MCP clients from discovering or invoking these tools correctly.
Input schemas lack type declarations and detailed parameter descriptions. 'query' and 'service_name' parameters have basic descriptions but no constraints (length limits, format, validation rules). LLMs cannot infer valid ranges or formats.
Output schemas are completely undocumented. 'find-api-endpoints' returns unstructured results via format_search_results() with unknown field names and types. 'get-service-specification' returns raw YAML as a string without schema documentation. LLMs cannot plan downstream calls or extract structured data.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 0 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 29 | - | v1 |
Tool descriptions are generic and lack WHEN-to-use guidance. 'find-api-endpoints' description mentions filtering by service but does not explain search result structure, limits, or when to use vs get-service-specification. No dependency hints provided.
Error handling returns generic HTTP 500 errors with no actionable recovery guidance. 'Search error: {e}' and 'Error retrieving spec for {service_name}: {e}' provide no hint to LLM about what failed, why, or what to try next. Violates recovery-guide pattern.
No pagination support or result limits documented. 'find-api-endpoints' returns all matching endpoints via format_search_results() with no mention of limits or pagination. If API has 1000+ endpoints, response could exhaust context window.
Tool composition unclear. The relationship between 'find-api-endpoints' (search) and 'get-service-specification' (read full spec) is documented in get-service-specification description ('read the full manual after finding the right chapter') but not bidirectionally. No guidance on which tool to call first or parameter chaining between them.