Loading ToolBench
Model Context Protocol (MCP) Server Implementation for managing AI models and users with admin console
This server has 4 tools with basic schemas and descriptions, but significant gaps in the definition quality rubric. All tools have explicit registration with Zod schemas and brief descriptions, but descriptions are too short (10-20 chars) to provide meaningful guidance to LLMs about WHEN to use each tool or what happens. Parameters lack detailed format/constraint documentation. Error messages are generic. No parameter descriptions beyond bare strings. The in-memory database means no real persistence, limiting production value. Tool naming is reasonable (verb_noun pattern) but descriptions fail the 'actionable docstring' test, they state WHAT but not WHEN or WHY.
Add a new model
Delete a model
Get model statistics
Update a model
All tool descriptions are under 30 characters and lack actionable content. They state WHAT (e.g., 'Add a new model') but not WHEN the LLM should call them or what business context triggers their use. Example: 'Add a new model' tells the LLM nothing about whether this creates a reference model, a fine-tuned variant, or a system entry.
No descriptions on any input parameters. The rubric requires 100% of A+ tool params to have descriptions. For example, the 'provider' parameter in add-model has no description, an LLM cannot know whether to pass 'openai', 'OpenAI', 'gpt-4-provider', or something else. The 'parameters' field (number of model parameters) lacks a unit and range hint (billions? total? learnable only?).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 42 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 34 | - | v1 |
Zod schemas present but lack constraint documentation. The 'parameters' field is z.number() with no min/max bounds. An LLM could pass -1, 0, or 1e20 with no guidance.
Error handling is generic. delete-model returns 'Model with ID {id} not found' with isError: true, but no guidance on what to do next.
No output schema documentation. The server returns text-based responses (JSON stringified), but there is no schema definition for what fields downstream tools or agents can expect. For example, add-model returns a JSON string of the new model, but the LLM does not know in advance it will receive {id, name, provider, parameters} so it can plan follow-up calls.
delete-model lacks confirmation or dry-run support. An agent could accidentally delete a critical model. No idempotency guarantees documented.
Parameter names could be more specific. The 'provider' field in add-model does not distinguish between 'provider_name' (OpenAI) and 'provider_key' (openai).