Loading ToolBench
MCP server that provides a capability registry with search, resolution, and upstream MCP gateway functionality for managing and discovering capabilities
Six tools with complete input schemas and descriptions. Naming follows verb_noun pattern (list-, capability-, load-, search-, resolve-, list-). Descriptions are detailed (100-250 chars) and explain WHEN to use each tool. Parameters are well-typed with enums where appropriate (section, taskMode). However, output schemas are not documented in the source, LLMs cannot see what fields to expect from responses. Error handling and recovery guidance are absent. No tool annotations (readOnlyHint, destructiveHint). All tools are READ_ONLY but this is not formally declared.
Get metadata, provenance and indexed files for one capability. Pass path and query to receive a compact ranked Markdown entrypoint shortlist, including linkedPaths and linkedFiles metadata for mentioned internal files; inspect large linked Markdown with capability-info before loading it. Path alone returns the full outline.
List all capabilities available in the registry, with their origin when imported.
List configured upstream MCP servers and their readiness status.
Load a capability as Markdown content. Prefer an exact path for progressive disclosure; otherwise load a section.
Resolve one primary capability and at most two non-conflicting supporting capabilities from the complete task and project context. Returns compact reasons, bounded entrypoints, conflicts and context budget without loading guidance.
Capability-first ranked search across indexed files. Global results return the best matching file for each shortlisted capability; inspect one with capability-info, then use capabilityId to search its internal files or load an exact path.
Output schemas not documented. LLMs cannot see what fields to expect from tool responses (e.g., what does resolve-capabilities return? What fields are in each capability object?). This forces LLMs to guess at response structure and risks incorrect downstream tool chaining.
No tool annotations. All six tools are READ_ONLY but lack readOnlyHint annotation. This prevents clients from optimizing caching, retry logic, and safety checks. Agents cannot distinguish safe-to-retry tools from destructive ones.
No error handling or recovery guidance. If a capability ID is invalid, or search returns no results, or upstream MCP is unreachable, the tool definitions do not explain what the LLM should do next. Error responses should guide recovery (e.g., 'Capability not found. Try search-capabilities() to find similar ones.').
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | 2026-07-28+ | v2 |
Parameter 'headingLimit' in capability-info lacks validation constraints. Description says 'maximum 8' but no minItems/maxItems in schema. LLMs may pass invalid values (negative, >8). Add explicit numeric bounds to schema.
Parameter 'maxCapabilities' in resolve-capabilities lacks schema bounds. Description says '1 to 3' but schema has no minimum/maximum. LLMs may pass 0, -1, or 100. Add explicit numeric constraints.