Loading ToolBench

Reading the current corpus…

rulecatch-sdk MCP server · C · ToolBench

rulecatch-sdk

MCP server for Claude Code — query AI rule violations, coding standards, and analytics directly in your IDE. Model Context Protocol.

2026-07-28+STDIO6 tools

61/100

Definition Quality72

Protocol Readiness50

Supportability51

Spec posture

Inferred effective spec 2026-07-28+·current baseline 2026-07-28

Static source inference · medium confidence

Current-spec patterns detected

Summary

The Rulecatch MCP server defines 6 tools with consistent naming (verb_noun pattern) and mostly complete schemas. All tools have descriptions and input parameters with type definitions. However, there are significant gaps: (1) output schemas are NOT documented in the source code, handlers return unstructured text responses rather than typed JSON objects; (2) parameter descriptions lack depth and guidance for LLM selection; (3) no error handling documentation or recovery paths; (4) response format is plain text concatenation rather than structured data, which violates pattern:response-shaper. Tools are well-named and input schemas are present, but the lack of output documentation and unstructured responses are critical issues for production agentic use.

Tools (6)

rulecatch_fix_planread onlyauthsource verified73/100

Generate a fix plan for violations: prioritized list of rule violations with estimated effort and recommended ordering.

rulecatch_rulesread onlyauthsource verified63/100

List all active Rulecatch rules with their conditions, severity, and descriptions.

rulecatch_summaryread onlyauthsource verified77/100

Get a summary of Rulecatch violations and AI coding activity for a time period. Includes top violated rules and category breakdown.

rulecatch_top_rulesread onlyauthsource verified73/100

Show top 10 most frequently violated rules across your codebase and team — ranked by violation count, impact, and avg correction time.

rulecatch_violation_detailread onlyauthsource verified73/100

Get full details for a specific violation: file path, line number, rule description, matched conditions, git context. Use this before fixing a violation.

rulecatch_violationsread onlyauthsource verified73/100

List Rulecatch rule violations. Filter by severity, category, session, corrected status, rule name, file path, language, tool, or branch.

Issues (6)

CRITICALresponse-shaper ↗

Output schemas not documented. All tools return plain text responses (content: [{type: 'text', text: '...'}]) rather than structured JSON objects. LLMs cannot parse or chain responses reliably. Per pattern:response-shaper, tools must return typed fields.

rulecatch_summaryrulecatch_violationsrulecatch_violation_detailrulecatch_rulesrulecatch_fix_planrulecatch_top_rules

HIGHtool-description ↗

Parameter descriptions lack guidance on when to use each filter. For rulecatch_violations, the 9 filter parameters (period, severity, category, sessionId, corrected, rule, file, language, toolName, branch) have minimal docs. LLM cannot reason about which combinations are most useful without field-level guidance.

rulecatch_violationsrulecatch_fix_plan

HIGHrecovery-guide ↗

No error handling documentation. Handlers return {isError: true, content: [{type: 'text', text: 'Error: ...'}]} with no recovery guidance. Per pattern:recovery-guide, errors must tell the LLM what to do next (retry, ask user, call different tool, etc.).

Recommendations

Convert all text responses to structured JSON. Instead of 'Violations: 42 total (10 errors, 5 warnings, 27 info)', return {violations: {total: 42, errors: 10, warnings: 5, info: 27}, ...}. Document the output schema for each tool in the handler or in a separate types file exported in JSDoc.
Add detailed descriptions to filter parameters in rulecatch_violations. E.g., 'severity: Filter by severity level (error=most critical, warning=medium, info=least critical). Omit to include all.' This guides LLM filter selection.
Implement structured error responses. Instead of {isError: true, content: [{type: 'text', text: 'Error: ...'}]}, return {isError: true, content: [{type: 'text', text: 'Retry Error: Service temporarily unavailable. This is retryable. Try again in 5 seconds.'}]} or {isError: true, content: [{type: 'text', text: 'User Error: Invalid period. Expected one of: today, 3d, 7d, 14d, 30d, this_week, this_month, all. Got: "3weeks".'}]}
Add per-tool toolAnnotations to registerTool(). Example: server.registerTool('rulecatch_summary', {description: '...', inputSchema: {...}, readOnlyHint: true}, async handler). This signals to the agent that the tool is safe to retry.
Document pagination for rulecatch_violations explicitly. Add an 'offset' parameter (0-based, default 0) alongside 'limit', and return {violations: [...], total: 1250, offset: 0, limit: 20, hasMore: true} in the response. This enables multi-page agent patterns.
Add JSDoc blocks above each tool handler documenting the return type. Example: /** @returns {{violations: Array<{id, rule, severity, ...}>, total: number}} */

Score history

Overall score trend

↑ 26 points across a rubric change (v1 → v2)

61/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-22	C	61	2026-07-28+	v2
2026-03-09	F	35	-	v1