Loading ToolBench
Lightweight zero-config MCP server. Give it an llms-full.txt (path or URL) and optional OpenAPI/AsyncAPI dirs — it registers the right tools automatically.
Server provides 6 tools with basic descriptions and input schemas. Naming follows verb_noun convention (get_, list_, search_). However, descriptions are generic and lack actionable guidance for LLM selection. Parameter descriptions are minimal or absent. No output schemas documented. Error handling is absent from visible code. Tools lack annotations (readOnlyHint, idempotentHint). Search tool has good parameter constraints (context_lines 0-20, max_results 1-50) but others are bare. Overall structure is functional but falls short of production-grade quality.
Returns the full AsyncAPI specification for the given name. Prefer search_documentation for targeted lookups to avoid loading the entire spec. Use list_asyncapi_specs to discover valid names.
Returns the complete docs documentation from llms-full.txt. Prefer search_documentation for targeted lookups to avoid loading the entire file.
Returns the full OpenAPI specification for the given name. Prefer search_documentation for targeted lookups to avoid loading the entire spec. Use list_openapi_specs to discover valid names.
Lists all available docs AsyncAPI specifications. Use the returned names with get_asyncapi_spec to fetch a specific spec.
Lists all available docs OpenAPI specifications. Use the returned names with get_openapi_spec to fetch a specific spec.
Searches all loaded docs documentation (llms-full.txt and any OpenAPI/AsyncAPI specs) for lines containing the query string (case-insensitive). Returns matching lines with surrounding context.
No output schemas documented. LLMs cannot infer what fields to expect from tool responses, forcing them to guess at downstream field names and types.
Parameter descriptions missing or minimal. 'name' parameter in get_openapi_spec and get_asyncapi_spec has description but list tools have no parameter descriptions at all.
Tool descriptions lack WHEN-to-use guidance. Descriptions state WHAT the tool does but not when an LLM should prefer it over alternatives or what prerequisites exist.
No error handling or recovery guidance visible. If a spec file is malformed or missing, no error message tells the LLM what to do next.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2026-07-28+ | v2 |
No tool annotations (readOnlyHint, idempotentHint). All tools are read-only but this is not declared, forcing LLMs to infer safety from descriptions.