Loading ToolBench
Model Context Protocol server for Rosetta (Enterprise Engineering Governance and Instructions Management System)
Rosetta MCP Server provides 3 tools for knowledge base retrieval and browsing. All tools have descriptions and are READ_ONLY, which is appropriate for a RAG/retrieval system. However, the server has critical gaps in schema documentation, parameter type definitions, and error handling guidance. Tool names are action-verb based ('get_', 'query_', 'list_') which is good. Descriptions exist but are brief and lack strategic context about when to use each tool vs. alternatives. Input schemas are only partially visible in the provided source, 'query_instructions' shows some input structure, but complete JSON Schema with type definitions is not evident. Output schemas are completely undocumented. Error handling lacks recovery guidance. The server uses HTTP transport (fastmcp), which is current-spec compliant, and resources are declared true, indicating proper protocol support.
Load global behavior rules and information about the project and its context. Call exactly once per session/task.
List immediate children (folders and files) of a virtual path prefix, without content. Use this to browse the instruction hierarchy: skills, rules, workflows, agents, templates, etc.
Fetch instruction docs. Prefer tags for known files and families, query for discovery. Be smart: if you have already fetched a file with specific tags, don't fetch it again.
No input schemas visible for get_context_instructions. Tool takes no documented parameters but no explicit registration with empty schema is shown in source.
Input schemas incomplete or not visible in source code. query_instructions shows partial input structure ({tags, query}) but no complete JSON Schema with type definitions, minLength, maxLength, or enum constraints. list_instructions shows two parameters but no formal schema.
Output schemas completely undocumented. No indication of what fields get_context_instructions, query_instructions, or list_instructions return. LLMs cannot plan downstream tool calls or extract needed data without knowing response structure.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 55 | <=2025-11-25 | v2 |
Descriptions are under 100 characters and lack strategic context. get_context_instructions says 'Load global behavior rules...' but does not explain WHEN to call this vs query_instructions, or what makes it a prerequisite. query_instructions says 'Prefer tags for known files' but does not explain tag naming conventions or discovery workflow. Description baseline for A+ tools is 194 chars; these average ~90 chars.
Parameter descriptions are minimal or missing. query_instructions parameters 'tags' and 'query' have brief descriptions but lack guidance on valid formats, typical tag names, or how semantic search is ranked. list_instructions 'format' parameter description is absent, unclear what values are valid beyond 'XML'.
No error handling guidance. No documentation of what happens when tags are invalid, semantic search fails, or a path does not exist. No recovery hints like 'If path not found, call list_instructions with empty path to explore root.'
Tool composition unclear. get_context_instructions is called 'exactly once per session/task', but no documentation of what that context contains or how it influences query_instructions behavior. Are tags global? Do they change per context? This dependency is undocumented.
list_instructions 'full_path_from_root' parameter accepts arbitrary strings or 'all' or '' but no examples or validation rules shown. LLMs cannot infer expected path format (e.g., 'skills/planning' vs 'skills/planning/' vs 'Skills/Planning').