Loading ToolBench
A plugin-based marketplace system with SPECLAN (specification language) support for managing specifications, requirements, and change requests, plus a todo task management system
This MCP server has severe definition quality issues across most tools. 11 of 14 tools have descriptions under 20 characters or are missing critical schema information. Only 4 tools (speclan-id-generator, speclan-query, check-speclan-tree, guard-locked-specs) have reasonably complete input schemas with typed parameters. The remaining 10 tools lack visible input schema definitions entirely, or have only partial/inferred schemas. Many descriptions are generic boilerplate without explaining WHEN to use the tool or WHAT it returns. No tools document output schemas. Parameter descriptions are inconsistent, some params have detailed constraints, others are bare identifiers. This server reads like an internal plugin system without production-grade tool documentation.
Verify that speclan plugin is installed (required dependency for speclan-engineering plugin) - warns if missing
Scan and validate SPECLAN tree consistency - reports structural violations, frontmatter errors, ID uniqueness, naming, placement, and reference integrity with fix hints
Detect SPECLAN project context at session start - counts draft/review/approved specs, checks plugin dependencies (speckit, feature-dev), detects BMAD method installation, and persists environment variables
Detect SPECLAN directory in a project by walking up the filesystem from a start directory, checking standard locations (speclan, specs/speclan, .speclan, .specs/speclan)
Detect todo directory and build status summary at session start - counts open, in-progress, and done tasks, lists active WIP tasks
Prevent invalid modifications to SPECLAN specifications - blocks setting invalid status values and prevents Write/Edit on locked specs (deprecated, in-development, under-test, released)
10 of 14 tools have no visible input schema definitions. Tools like speclan-format, detect-speclan-dir, detect-speclan-context, check-speclan-dependency, detect-todo-context, and todo-format expose only file paths or project dirs with no structured schema. This violates the pattern:tool requirement that every tool declare its input contract.
Tool descriptions are generic and lack LLM-optimized guidance. Most are between 25-50 characters, below the 50-200 char baseline for A+ tools. Examples: 'todo-start' (25 chars): 'Move a todo task from open to work-in-progress state', does not explain WHEN to call it vs other tools or WHAT it returns. 'check-speclan-dependency' (30 chars): 'Verify that speclan plugin is installed', no guidance on retry behavior or what the user should do if it fails.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 35 | 2026-07-28+ | v2 |
Apply SPECLAN format validation and guidance when working with specification files - enforces YAML frontmatter structure (id, type, title, status, owner, created, updated), entity relationships, ID prefixes, and status workflow
Generate unique IDs for SPECLAN entities (goals, features, requirements, change requests) with end-biased gap distribution strategy
Query SPECLAN entities with flexible filtering - supports type, status, ID, parent, and full metadata output with JSON results
Add a new todo task to the open queue
Move a work-in-progress task to done state
Apply todo format guidance when accessing todo files - enforces header format (Status/Priority/Assignee/Created/Branch), maintains Tasks checklist with [ ]/[x], logs work with timestamps in YYYY-MM-DD HH:MM format, references dependencies by ID only
Move a todo task from open to work-in-progress state
Update a work-in-progress task with progress notes and implementation log entries
No tools document their return schema or output format. LLMs cannot plan downstream calls without knowing what fields to expect. For example, speclan-query says it returns JSON but does not specify field names, types, or structure. This violates pattern:response-shaper.
No error handling guidance. Tools like guard-locked-specs and check-speclan-tree can fail (invalid status, tree violations) but do not document how the LLM should handle failures or retry. This violates pattern:recovery-guide and pattern:error-classification.
STDIO-only transport. The server exposes tools exclusively over STDIO (bash/mjs scripts spawned via shell). This is not remotely accessible and cannot be tested by hosted MCP clients. HARD CAP: protocol readiness ≤ 50.
Inconsistent parameter descriptions. Some tools (speclan-id-generator, speclan-query) have detailed param docs with enums and constraints; others (detect-speclan-context, check-speclan-dependency) have one-liner params with minimal context. Pattern:constrained-input and pattern:tool-description require ALL params to be documented.
Todo tools (todo-add, todo-start, todo-update, todo-done) lack clear semantics. Descriptions do not explain the state machine (open -> in-progress -> done) or what happens if you call todo-start on a task that is already done. This violates pattern:tool-description and pattern:error-classification.
No tool composition guidance. The SPECLAN toolset (speclan-id-generator, speclan-format, check-speclan-tree, speclan-query, guard-locked-specs) has interdependencies not documented. For example, guard-locked-specs depends on speclan-format validation, but LLMs are not told this. Violates pattern:tool-chain.