Loading ToolBench
Model Context Protocol server exposing system prompt files and summaries.
The server has solid naming conventions (list_prompts, get_prompt_suggestion follow verb_noun pattern) and generally good descriptions. However, there are critical gaps in schema completeness, particularly for the dynamic prompt tools which are only partially specified. The dynamic tool registration pattern makes it difficult to verify full schema compliance for individual prompt tools. Tool descriptions are adequate (100-200 chars range) but could better explain WHEN to use each tool vs alternatives. Parameter descriptions are present and mostly clear, but the dynamic tools lack explicit input schema documentation in the visible source.
Dynamic tools registered at runtime from discovered prompt files. Each tool returns the prompt content in either text or JSON format, with persona activation hints. Tool names are derived from prompt file paths and follow the pattern: <service>-<variant>-<flavor>.
Suggests the most appropriate prompt tool for a given use case, favoring configurations tuned for the user's LLM.
Enumerate available prompt files. Filter by service name, flavor, or provider to narrow the list. Returns up to 25 entries by default.
Dynamic prompt tools have incomplete schema documentation. While the tool registration shows a 'format' enum parameter, the actual tool names and descriptions are generated at runtime from descriptor files. Cannot verify individual prompt tool schemas, descriptions, or naming conventions from source alone. Tools are inferred rather than explicitly defined.
Output schema documentation is missing for all tools. The code returns content arrays with text/structuredContent fields, but there is no formal documented output schema telling LLMs what fields to expect or how to parse results. Dynamic tools return structuredContent with {id, service, flavor, variant, path, llm, length, personaHint} but this is not documented as a formal schema.
list_prompts returns up to 25 results by default but does not support pagination/cursor-based continuation. If a user has 100+ prompts, they cannot discover the full set. No total_count or next_cursor field is documented in the response.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2025-06-18+ | v2 |
Error handling lacks recovery guidance. The source shows no explicit error handling for file read failures, missing descriptors, or invalid filters. If a file is deleted or inaccessible, users get a generic error with no guidance on next steps.
get_prompt_suggestion does not document what 'fallback choices' are returned when no exact match is found. The requireMatch parameter controls behavior, but the response structure for fallback scenarios is not defined. LLMs cannot plan how to use the results.
Dynamic prompt tool descriptions mention 'persona activation hints' but do not formally document what a persona hint contains or how LLMs should interpret it. The instructions in the server's capabilities encourage behavior that may not align with some LLM safety guidelines (e.g., 'you MUST adopt the persona').