Loading ToolBench
MCP server for sudocode, git-native context management for AI-assisted development. Provides tools for spec and issue management, relationships, feedback, and references.
The sudocode MCP server demonstrates solid quality with well-documented tools and clear specifications for domain-specific operations (specs/issues/links). Tool naming follows verb_noun conventions (upsert_issue, list_specs, show_issue). Descriptions are substantial (150-250 chars) and explain WHEN to use each tool. Input schemas are present with typed parameters and enums. However, output schemas are not documented in the provided source, parameter descriptions vary in completeness, and error handling guidance is minimal. The domain model is clear (specs as requirements, issues as work items, linking as dependency management), but the implementation lacks explicit error recovery patterns and structured output documentation. Tools are narrowly focused (single responsibility) and composable (e.g., link tool connects specs to issues). Resource operations span READ_ONLY (ready, list_issues, show_issue, list_specs, show_spec) and WRITE (upsert_issue, upsert_spec, link, add_reference, add_feedback), with appropriate risk labeling.
**REQUIRED when closing issues that implement specs.** Document implementation results by anchoring feedback on specific spec sections. Feedback types: 'comment' (discussion), 'suggestion' (improvement), 'request' (change request). Use when specs need clarification or improvement based on implementation experience.
Insert an Obsidian-style [[ID]] reference into spec or issue markdown content.
Create a relationship between specs and/or issues. Use this to establish the dependency graph and connect work to requirements. Most common: 'implements' (issue → spec) and 'blocks' (dependency ordering).
Search and filter issues. Use this when you need to find specific issues by status, priority, keyword, or when exploring what work exists in the project.
Search and browse all specs in the project. Use this to find existing specifications by keyword, or to see what specs are available before creating new ones.
Shows you the current project state: what issues are ready to work on (no blockers), what's in progress, and what's blocked. Essential for understanding context before making any decisions about what to work on next.
Output schemas not documented. Tools return complex domain objects (specs with feedback arrays, issues with dependency graphs, link relationships) but the response structure is not formally specified. LLMs cannot plan chaining calls without knowing what fields to expect.
Error handling lacks recovery guidance. No indication of what to do if a spec_id is invalid, if a link creates a cycle, if an issue is already in the specified status, or how to resolve 'issue not found' errors. Error responses should guide the LLM to alternative actions.
add_reference tool has weak description (72 chars of actual guidance). The tool's purpose ('Insert an Obsidian-style [[ID]] reference') does not explain WHEN to use it instead of the link tool or upsert_issue/upsert_spec. Agents will conflate reference insertion with relationship linking.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 66 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Get full details about a specific issue. Use this to understand what the issue implements (which specs), what blocks it (dependencies), its current status, and related work. Essential for understanding context before starting implementation.
Get full details about a specific spec including its content, relationships, and all anchored feedback. Use this to understand requirements before implementing.
Create or update an issue (agent's actionable work item). **Issues implement specs** - use 'link' with type='implements' to connect issue to spec. **Before closing:** provide feedback on the spec using 'add_feedback' if this issue implements a spec. If issue_id is provided, updates the issue; otherwise creates a new one. To close an issue, set status='closed'. To archive an issue, set archived=true.
Create or update a spec (user's requirements/intent/context document). If spec_id is provided, updates the spec; otherwise creates a new one with a hash-based ID.
upsert_issue and upsert_spec parameter descriptions lack validation guidance. For priority (number 0 - 4), no description states the allowed range. For status enum, no guidance on state transitions (can you go from 'closed' back to 'open'?). For tags array, no guidance on format or limit.
add_feedback has optional anchor parameters (anchor_line, anchor_text) with unclear semantics. If both are omitted, where is feedback anchored? Do both need to match? Can they conflict? This ambiguity invites misuse.