Loading ToolBench
A local MCP server that provides tools for listing available AI models and querying their configuration, along with prompts for code review, concept explanation, debugging, and architecture design. Acts as an MCP client hub connecting to multiple external MCP servers (Notion, GitHub) and AI providers (OpenAI, Google Gemini, Anthropic Claude).
This MCP server has severe gaps in definition quality across both tools. Tool schemas are visible but lack parameter descriptions entirely. Tool descriptions exist but are minimal (under 50 chars each) and provide no actionable context for LLM selection. Both tools accept zero parameters, which is unusual for model configuration tools and suggests incomplete implementation. No output schemas are documented. Error handling is completely absent, there are no recovery guides, validation, or error categorization. The server implements prompts and resources (shown in capabilities) but these are not evaluated here. The codebase shows basic MCP SDK integration but lacks the depth required for production agent tooling.
Returns a list of all available models grouped by provider
Returns the current provider and model configuration
No parameter descriptions despite JSON Schema structure. Both tools define inputSchema via createZodSchema() but neither tool provides any parameter documentation in the schema (properties are empty objects). When parameters are absent, this is not a blocker, but schemas MUST document what the tool does and when to use it.
Tool descriptions are under 60 characters and lack actionable context. 'Returns a list of all available models grouped by provider' and 'Returns the current provider and model configuration' fail to answer: What does it do? When should the LLM call it instead of a similar tool? What does it return? LLMs cannot infer these details from minimal descriptions.
No documented output schemas. Neither tool declares what fields it returns or their types. Code shows list-models returns { [provider]: [model_code_strings] } and show-model returns { provider, model }, but these structures are inferred from implementation callbacks, not declared in the tool definition. LLMs must guess the output structure and cannot plan downstream tool calls or field extraction.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 35 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 28 | - | v1 |
Zero error handling. No error categorization (retryable vs user-fixable vs fatal), no recovery guidance, no validation, no timeout handling. If a tool fails (e.g. DEFAULT_PROVIDER is misconfigured), the LLM receives raw exceptions and cannot reason about next steps.
No tool annotations. Neither tool declares readOnlyHint, destructiveHint, or idempotentHint. While both tools are safely read-only, this is not explicitly marked in the schema, agents cannot verify safety without calling the tool.