Loading ToolBench
Canon — spec-driven development platform. Provides access to organization's spec documents and markdown knowledge base through MCP tools for searching, retrieving, and managing specifications.
Canon MCP provides 7 tools with complete input schemas and descriptions. Naming follows verb_noun convention (search, get_spec, update_section_status). Descriptions are substantive (100-200 chars), explaining WHAT and WHEN. However, output schemas are not documented in the visible code, LLMs cannot predict response structure. Error handling is absent: no guidance on retryability, user-fixable vs fatal errors, or recovery paths. Parameters lack constraints (enums, ranges, patterns) despite accepting restricted values (status field accepts 'draft|todo|in_progress|done|blocked|deprecated' but no enum declared). The triage_issue tool orchestrates multiple concerns (classify + match + apply labels + create PR), violating single-responsibility. No tool annotations (readOnlyHint/destructiveHint) despite clear read vs write distinction.
Find specs related to a given spec using vector similarity (kNN). Returns a list of related specs ordered by similarity. Filters results based on ai_exposure configuration.
Retrieve raw markdown content of a document by repo and path. Returns the complete markdown file as-is without parsing. Useful for accessing the raw spec source.
Retrieve a specific section from a spec by section ID. Returns the section with its content, acceptance criteria, scenarios, and child sections. Enforces ai_exposure restrictions.
Retrieve a full spec document by repo and path. Returns the complete spec with all sections, acceptance criteria, scenarios, and metadata. Respects ai_exposure restrictions from frontmatter and repo configuration.
Search the spec knowledge base using hybrid search (vector + BM25). Returns matching sections with repo, path, title, heading, body snippet, status, and relevance score. Use this to find specs related to what you're working on.
Output schemas not documented. LLMs cannot predict response structure (fields, types, nesting). Breaks downstream tool chaining and forces agents to guess at available data.
No error handling guidance. Tools do not indicate retryability, user-fixable errors, or recovery paths. E.g., update_section_status may fail if section_id is invalid, but no error message tells the LLM what to do.
Parameters accept restricted values (status: draft|todo|in_progress|done|blocked|deprecated) but lack enum constraints. Free-form strings invite hallucinated values.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | 2026-07-28+ | v2 |
MCP tool: Classify a GitHub issue and match it to existing specs. Orchestrates classification, matching, and optionally applies labels/comments.
Update the status of a section in a spec. Changes the section state to one of: draft, todo, in_progress, done, blocked, deprecated. Creates a commit with the change.
triage_issue violates single-responsibility: classifies issue, matches specs, applies labels, and creates PR in one tool. Should split into separate tools (classify_issue, match_specs, apply_labels, create_spec_pr) for composability.
No tool annotations (readOnlyHint/destructiveHint/idempotentHint). Agents cannot distinguish safe reads from destructive writes without reading descriptions. update_section_status and triage_issue should be marked destructive.