Loading ToolBench
MCP server for Event-Spec-Driven Development (ESDD) providing tools for dependency map validation, assembly, hashing, rendering, and workflow guidance
SpecDAG has 14 tools with consistent verb-noun naming (validate_map, assemble_maps, hash_map, etc.), which is strong. All tools have descriptions (avg ~120 chars, within baseline 34-392). However, input schemas are present but minimal: most parameters lack type constraints, enums, or format specifications. Output schemas are undocumented, tools return text or JSON but the structure is not formally declared. Error handling is basic (FAIL/PASS strings) with no recovery guidance. No tool annotations (readOnlyHint, destructiveHint). The server is READ_ONLY dominant (13/14 tools) with one WRITE tool (generate_report) that lacks confirmation or dry-run support. Parameter descriptions are sparse (e.g., 'Node ID to analyze' lacks format/constraint details). Overall: solid naming and basic descriptions, but schemas and error handling fall short of production baseline.
Calculates all downstream nodes affected by changing a specific node ID in a map.
Walks a specs directory, merges all feature dependency maps and checks for global cycles and node conflicts.
Generates a static HTML review report for a dependency map file or specs directory.
Returns the full ESDD (Event-Spec-Driven Development) skill rules, templates, and layouts.
Computes a deterministic SHA-256 Merkle-DAG attestation for a dependency map, including referenced evidence files.
Guide for migrating an existing feature description or legacy specifications into an ESDD Spec-DAG.
Output schemas undocumented. Tools return text or JSON but structure is not formally declared. LLMs cannot plan downstream calls or extract typed fields reliably.
Parameter descriptions lack format/constraint details. E.g., 'Node ID to analyze' does not specify format, length, or valid characters. 'view' parameter lists options in description text instead of enum constraint.
Error handling is minimal. Tools return 'FAIL: <error>' or 'PASS: <result>' with no recovery guidance. LLMs cannot determine if errors are retryable, user-fixable, or fatal.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 48 | 2026-07-28+ | v2 |
Renders a local dependency-map.yaml into a Mermaid markdown diagram string.
Reviews a local dependency map from a methodic ESDD perspective, checking nodes, edges, and obligations.
Provides the structured ESDD checklist and question flow for starting a single-feature implementation.
Provides the ESDD checklist for integrating multiple features via shared events and contracts.
Provides the ESDD checklist for reconciling discrepancies between the intended Spec-DAG and observed code/run traces.
Provides a textual summary of metrics, blocked approvals, orphans, unverified expectations, and the critical path of a map.
Validates a local dependency-map.yaml file for schema correctness and acyclic (cycle-free) constraints.
Validates a dependency map and verifies that its Merkle root matches an expected hash.
No tool annotations. generate_report is destructive (WRITE) but lacks readOnlyHint/destructiveHint. Agents cannot distinguish safe from risky tools without reading descriptions.
generate_report (WRITE tool) lacks confirmation or dry-run support. Agents can accidentally overwrite output files without user approval.