Loading ToolBench
MCP server bridging specs (Linear / JIRA / GitHub Issues / Notion / Markdown / Figma) to tests, with bidirectional traceability and a spec-quality coach (AI 規格大師)
mk-spec-master has 18 well-named tools with comprehensive descriptions (avg 180 chars, within baseline 194). All tools have input schemas with type definitions. However, parameter descriptions are sparse or missing entirely, most params lack guidance on format, constraints, or valid values. Output schemas are documented in descriptions but not formally specified in inputSchema. Error handling is implicit (no recovery guidance visible). Tool composition is strong (each does one thing), but parameter validation rules are underdocumented. STDIO transport caps protocol readiness at 50.
Score a spec on clarity, completeness, and testability. Checks for: presence of acceptance criteria, role clarity, preconditions, edge cases, and language quality. Returns {spec_id, title, score (0–100), issues: [{severity, message}, ...], suggestions: [string]}. Pairs with propose_spec_improvements for a coaching loop.
Heuristically link tests to specs by matching test names / docstrings against spec titles / acceptance criteria. Returns {linked: [{spec_id, test_node_id, confidence}, ...], summary: {total_linked, total_tests, total_specs}}. Useful for bootstrapping coverage on legacy codebases; review the results before committing.
Turn parsed acceptance criteria into testable scenarios. Each scenario is classified as happy / edge / error via keyword heuristics, and split into Given / When / Then where possible. Pass the `acceptance_criteria` array returned by parse_spec. Returns {count, scenarios[]} where each scenario has {id, ac_id, title, kind, given, when, then}. Best paired with generate_test_plan for a markdown handoff to mk-qa-master.
Pull a single spec by id from the active source. For markdown_local the id is either the `id:` field in frontmatter or the filename stem; for github_issues it's the issue number as string. Returns the full Spec record {id, title, body, url, status, labels, metadata}. Pair with parse_spec to extract structured acceptance criteria.
Parameter descriptions missing or minimal. Most params (status, label, limit, spec_id, raw_text, etc.) lack guidance on format, constraints, valid values, or when to use them. LLMs cannot infer parameter semantics from names alone.
Output schemas not formally documented in inputSchema. Descriptions mention return structure (e.g. '{active, available, version}') but no formal JSON Schema for responses. LLMs cannot plan downstream tool calls without knowing response field names and types.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2026-07-28+ | v2 |
One-shot: fetch + parse + extract for a spec, then emit a markdown test plan with a `business_context` block per scenario ready to hand to `mk-qa-master.generate_test(business_context=...)`. The AI client typically reads this plan, loops the scenarios, and calls mk-qa-master once per scenario. Set `target_runner` to hint the desired output (pytest / jest / cypress / go / maestro). Returns {spec_id, target_runner, scenario_count, markdown, scenarios[]}.
Render a coverage matrix: specs × tests. Rows are specs (from the active source), columns are test files / suites, cells show which tests verify which specs. Useful for dashboards, CI gates, and spotting untested specs. Returns {matrix: {spec_id: {test_node_id: timestamp, ...}, ...}, summary: {total_specs, total_tests, coverage_pct}}.
Detect specs that have changed since tests were linked. Compares the current acceptance-criteria hash (from parse_spec._meta.ac_hash) against the hash stored in the index when link_test_to_spec was called. Returns {drifted: [{spec_id, title, old_hash, new_hash, tests_affected}, ...], summary: {total_drifted, total_specs}}. Use this to flag specs that need test updates.
Compute a stable hash of a spec's acceptance criteria for drift detection. Returns {spec_id, ac_hash (SHA-256), ac_count}. Pair with link_test_to_spec's ac_hash parameter to enable get_drift_report.
Analyze test coverage, drift, and quality trends to suggest where to focus next. Returns {focus_areas: [{area, priority, reason, suggested_action}, ...], summary: {coverage_pct, drift_count, quality_score}}. Snapshots the current state into HISTORY_DIR so trend tools can compare against past runs.
Retrieve specs semantically similar to a query. Useful for finding related specs, spotting duplicates, and understanding the broader context around a feature. Returns {query, results: [{spec_id, title, similarity_score, excerpt}, ...]}.
Retrieve the edit history of a spec from the active source (if supported). For GitHub Issues this is the issue timeline; for markdown_local it's git log if available. Returns {spec_id, title, events: [{timestamp, author, action, before, after}, ...]}.
Return the active spec source (selected via SPEC_SOURCE env var) plus all adapters built into this server. Call first in any session so the AI knows whether to expect markdown / GitHub / (future) Linear / JIRA / Notion semantics. Returns {active, available, version}.
Retrieve usage and error telemetry from the server. Returns {period, tool_calls: [{name, count, avg_duration_ms, error_count}, ...], errors: [{tool, message, count}, ...]}. Helps identify bottlenecks and common failure modes.
Initialize a vector store / knowledge base from the active spec source. Embeds each spec's title + body + acceptance criteria so get_spec_context can retrieve semantically similar specs. Returns {count, indexed_specs: [spec_id], store_path}.
Record that a test verifies a spec. Writes into SPEC_PROJECT_ROOT/.mk-spec-master/index.json (data ownership stays with the user). Re-linking the same node_id updates the timestamp instead of duplicating. Call this right after mk-qa-master.generate_test returns a node_id so the coverage matrix stays current. Pass `spec_title` / `spec_source` / `spec_url` (typically already known from earlier fetch_spec) to cache them into the index so get_coverage_matrix can render titles without re-fetching from the source. Pass `ac_hash` (from parse_spec._meta.ac_hash) to enable drift detection via get_drift_report. Returns {action: 'added'|'updated', spec_id, test_node_id, total_links_for_spec}.
Enumerate specs from the active source. For markdown_local this globs SPEC_PROJECT_ROOT/specs/*.md and reads YAML frontmatter; for github_issues it queries the configured owner/repo (set via SPEC_PROJECT_KEY). Optional filters: status (string — adapter-specific: 'in-progress' for markdown, 'open'|'closed'|'all' for GitHub), label (string), limit (int, default 50). Returns {source, count, specs[]}.
Extract structured acceptance criteria from a spec body. Looks for headings matching 'Acceptance criteria' / 'AC' / '驗收條件' / '驗收標準' (case-insensitive, en + zh-TW + zh-CN) and pulls numbered or bulleted items beneath. Pass `spec_id` to use the active adapter, or `raw_text` to parse ad-hoc spec text without going through any source. Returns {spec_id, title, acceptance_criteria[], roles[], preconditions[], _meta}. Roles + preconditions are placeholders in v0.1 — filled by the v0.2 spec-quality coach.
Given a spec and quality analysis, suggest concrete rewrites. Returns {spec_id, title, improved_body (markdown), changelog: [{section, before, after}, ...]}. The AI client can review the suggestions and decide whether to update the source.
No error handling guidance. Tools lack recovery hints (e.g. 'If spec not found, try list_specs() first'). Error responses will not guide LLM on retry vs user-fixable vs fatal classification.
STDIO transport only. Server is not remotely accessible and cannot be used by hosted MCP clients. Limits deployment to local/CLI-only scenarios.
Enum constraints missing. Parameters like 'status' and 'target_runner' accept free-form strings without enum definitions. LLMs will hallucinate invalid values (e.g. 'pending' instead of 'in-progress').