Loading ToolBench

Reading the current corpus…

mcp-triage MCP server · C · ToolBench

mcp-triage

Triage broken MCP setups across 8 agent clients — find what is wrong, fix what is fixable, escalate the rest. Zero runtime dependencies.

<=2025-11-25STDIO2 tools

63/100

Definition Quality80

Protocol Readiness45

Supportability46

Spec posture

Inferred effective spec <=2025-11-25·current baseline 2026-07-28

Static source inference · medium confidence · detected: Logging

Deprecated protocol patterns detected

Summary

Two tools with clear, action-oriented names (triage_scan, triage_fix) and detailed descriptions (150+ chars each). Input schemas are present with typed properties and descriptions. However, output schemas are not documented in the visible code, LLMs cannot predict what fields to expect from results. Error handling is mentioned in descriptions but not formalized. Tool composition is sound: scan is read-only, fix is write with dry-run safety. Naming follows verb_noun pattern well.

Tools (2)

triage_fixwritesource verified78/100

Repair MCP config files that fail to parse — mechanical repairs only (strip JSON comments and trailing commas). Dry-run by default: unless dry_run is explicitly false, nothing is written. A .mcp-triage.bak backup is kept before any write, and nothing is written unless the repaired copy parses cleanly.

triage_scanread onlysource verified82/100

Scan the MCP configuration files of the agent clients on this machine (Claude Desktop, Claude Code, Codex, Cursor, VS Code, Windsurf, OpenClaw, dsh) and report findings: broken JSON/TOML, commands not on PATH, missing env vars, relative-path arguments, plain-http remotes, transport mismatches, and cross-client drift for same-named servers. Read-only.

Issues (4)

HIGHtool ↗

Output schemas not documented. LLMs cannot predict what fields triage_scan and triage_fix return, forcing them to guess at response structure and downstream field names.

triage_scantriage_fix

HIGHrecovery-guide ↗

Error handling not formalized. Descriptions mention 'broken JSON/TOML' and 'commands not on PATH' but do not specify error response format, recovery guidance, or categorization (retryable vs user-fixable).

triage_scantriage_fix

MEDIUMconstrained-input ↗

Parameter 'cwd' lacks validation constraints. Description says 'default: the server process working directory' but does not specify format, allowed paths, or path traversal guards.

triage_scantriage_fix

LOWtool-description ↗

triage_fix dry_run parameter defaults to true, which is safe, but the description could be clearer about the backup mechanism (.mcp-triage.bak) and when it is created.

triage_fix

Recommendations

Document output schemas for both tools. Example: triage_scan should return {diagnostics: [{checkId, severity, title, hint, ...}], summary: {totalIssues, byClient: {...}}}. triage_fix should return {dryRun: boolean, repairs: [{file, status, details}], backupPath: string}.
Formalize error responses with categorization. Define error types: 'parse_error' (retryable), 'permission_denied' (user-fixable), 'invalid_path' (user-fixable). Include recovery hints in every error.
Add constraints to 'cwd' parameter: 'Absolute or relative path to a directory. Must be readable. Relative paths are resolved from the server's working directory. No path traversal (../) allowed.'
Expand 'file' parameter description to clarify: 'Absolute path to a single config file (JSON, TOML, or YAML). If omitted, scans all standard client config locations.'
Add a 'format' enum parameter to triage_scan to let users request output as 'json' or 'human-readable', improving composability with downstream tools.

Spec posture evidence

Inferred effective spec: <=2025-11-25.

Relies on Logging (deprecated) - log to stderr or use OpenTelemetry

Score history

Overall score trend

First recorded score · v2 rubric

63/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-23	C	63	<=2025-11-25	v2