Loading ToolBench
An MCP server that provides access to YARD documentation for Ruby gems, enabling code navigation, documentation retrieval, and source code exploration.
YardMCP exhibits solid schema discipline and consistent naming conventions across 12 tools, but suffers from uneven description quality and missing output schema documentation. All tools follow verb_noun naming (ListGems, GetDoc, BuildGemDocs). Input schemas are present and properly typed for all tools. However, 7 of 12 tools have minimal descriptions (<100 chars), and the server lacks explicit output schema documentation for any tool. Parameter descriptions are present and actionable (e.g., 'The YARD path (e.g., 'String#upcase')'), but the code does not show documented return types. Error handling exists (DocumentationError, AmbiguousObjectError classes visible in lib/yardmcp.rb) but recovery guidance is not evident in tool descriptions. The codebase is readable and follows Ruby conventions, but the MCP tool registration in exe/yardmcp and lib/yardmcp.rb does not show explicit output schema declarations for downstream LLM planning.
Returns the full ancestor chain (superclasses and included modules) for a class or module.
Builds YARD documentation for a specified gem.
Lists the children (constants, classes, modules, methods, etc.) under a namespace.
Fetches the code snippet for a YARD object from installed gems.
Fetches documentation and metadata for a YARD object (class/module/method).
Returns inheritance and inclusion information for a class or module.
Lists all classes and modules in the loaded YARD registry for a specified gem.
Output schemas not documented. No tool returns a documented schema showing LLMs what fields to expect. Descriptions state what tools do but not what they return. Example: GetDocTool returns a hash with 'type', 'name', 'namespace', etc. (visible in lib/yardmcp.rb:get_doc method) but tool definition does not expose this schema for agent planning.
Minimal or missing recovery guidance in error descriptions. DocumentationError and AmbiguousObjectError are defined in code but tool descriptions do not indicate what LLM should do on failure. Example: GetDocTool description lacks 'If object not found, try SearchTool first.' guidance.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 46 | - | v1 |
Lists all installed gems that have a .yardoc file available.
Lists all methods for a class or module.
Returns related objects: included modules, mixins, and subclasses for a class or module.
Performs a fuzzy/full-text search in the YARD registry for objects whose path or docstring matches the query.
Returns the source file and line number for a YARD object (class/module/method).
Seven tools have descriptions under 100 characters, some under 80 chars (ChildrenTool, HierarchyTool, AncestorsTool, RelatedObjectsTool). These lack sufficient context for LLM selection and WHEN to use each tool vs overlapping variants (e.g., HierarchyTool vs AncestorsTool distinction unclear).
Parameter descriptions exist but could be more prescriptive. Example: 'gem_name' parameter described as 'Optional: the name of the gem containing the object. If omitted, searches all indexed gems.', good, but does not state format constraints or behavior on ambiguous results for tools like GetDocTool and SearchTool where AmbiguousObjectError can occur.
SearchTool 'limit' and 'offset' parameters lack numeric constraints in descriptions. Code shows search(..., limit: 25, offset: 0) with defaults but descriptions do not state min/max or reasonable bounds (e.g., limit 1-1000).