MCP server + live dashboard for AI code governance — OWASP LLM Top 10, real-time MCP App UI, 25+ security patterns, Bayesian learning Brain, hallucinated import detection, multi-agent governance. Works with Claude, Cursor, VS Code, ChatGPT, Goose, Windsurf.
Rigour MCP Server exhibits severe definition quality issues across nearly all 24 tools. While tool names follow verb_noun conventions reasonably well (rigour_recall, rigour_check, rigour_review, etc.), the critical failure is pervasive absence of input parameter schemas and descriptions. Source code inspection of packages/rigour-mcp/src/advertised-tools.ts shows tool definitions are declared but no schemas are visible in the provided code excerpts. Descriptions exist but are extremely generic (10-40 characters), failing to explain WHEN to use each tool, WHAT parameters are required, WHAT the output structure contains, or HOW to use the results. Without schema inspection of the actual advertised-tools.ts file, parameter types, requirements, and validation rules cannot be verified. This is a critical blockers for LLM-based tool selection and parameter binding.
Tools (24)
rigour_agent_deregisterwritesource verified31/100
Deregister an agent from multi-agent governance
rigour_agent_registerwritesource verified31/100
Register a new agent for multi-agent governance
rigour_cache_statsread onlysource verified28/100
Get cache hit/miss statistics and performance metrics
CRITICAL: No input parameter schemas visible in source code. All 24 tools lack visible JSON Schema definitions with type declarations. Cannot verify parameter names, types, requirements, enums, or constraints. Violates pattern:constrained-input and pattern:tool-description.
IMMEDIATE: Publish the full advertised-tools.ts file schema definitions showing all 24 tools with complete JSON Schema input/output definitions. Verify every parameter has a 'type' field (string, number, boolean, array, object) and a 'description' field (min 20 chars, max 200 chars explaining purpose and constraints).
Expand tool descriptions from generic 30-char statements to 100-150 character expert summaries. Template: '[WHAT it does]. Use when [WHEN]. Returns [WHAT OUTPUT]. Example: [SAMPLE INPUT → SAMPLE OUTPUT].' Example for rigour_recall: 'Retrieve stored contextual information from the Rigour learning system. Use when you need previously analyzed patterns, code metrics, or historical findings for the current project. Returns a structured object with recalled metadata, timestamps, and source references.'
Add explicit parameter descriptions for all inputs. For each parameter, document: (1) what it controls, (2) valid values or format (e.g. enum values, regex pattern, numeric range), (3) whether it is required or optional, (4) any defaults. Example: 'pattern_name (string, required): The identifier of the pattern to check. Must be a registered pattern in the Rigour index (e.g. "singleton-pattern", "dependency-injection"). Required for accurate matching.'
Document return schemas for all 24 tools. For each, specify: the top-level structure (object, array, string, etc.), all key fields, field types, field descriptions, and pagination info if applicable. Use JSON Schema format visible in the MCP server definition. Example: 'Returns an object: { success (boolean), findings (array of { id, severity, location, description }), total_count (number) }'
Score history
Overall score trend
↑ 6 points across a rubric change (v1 → v2)
45/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-22
F
45
2026-07-28+
v2
2026-03-09
F
39
-
v1
read onlysource verified28/100
Query the scope and boundaries of the current context cache
CRITICAL: Tool descriptions are extremely generic and under 20 characters. Examples: 'Recall contextual information...' (31 chars), 'Check if a specific pattern...' (30 chars), 'Query the scope and boundaries...' (32 chars). Most descriptions lack critical context: WHEN to use the tool, HOW to interpret its output, WHAT prerequisites exist, or HOW results chain to downstream tools. LLMs cannot reliably select these tools or understand expected behavior.
CRITICAL: No parameter descriptions visible. Tools declare input parameters but descriptions for those parameters are not present in source excerpts. This makes it impossible for LLMs to understand what each parameter controls, what values are valid, what format is expected, or when a parameter is required vs optional.
HIGH: No output schemas documented. Tools return results but the response structure is not specified anywhere in visible source. LLMs cannot plan downstream tool calls, extract specific fields, or understand what data is available. Pattern:response-shaper requires documented return types for all tools.
HIGH: governance/agent-management tools (rigour_agent_register, rigour_agent_deregister, rigour_checkpoint, rigour_handoff, rigour_handoff_accept, rigour_hooks_init, rigour_run, rigour_run_supervised) lack clear error handling and recovery guidance. No visible documentation of: what errors can occur, which are retryable, what state changes happen on failure, how to undo partial operations, or what guard rails prevent misconfiguration.
MEDIUM: State-modifying tools (rigour_index, rigour_remember, rigour_forget, rigour_agent_register, rigour_agent_deregister, rigour_checkpoint, rigour_handoff, rigour_handoff_accept, rigour_hooks_init, rigour_run, rigour_run_supervised) have WRITE risk but no descriptions clarifying idempotence, retry behavior, or compensation paths. Agents need to know: is it safe to retry? Will calling twice create two copies? How do I undo accidental changes?
MEDIUM: Tool naming is moderately clear (verb_noun pattern) but some names are vague. Examples: 'rigour_check', does it check the codebase, a pattern, a gate, or current status? 'rigour_run' vs 'rigour_run_supervised', the distinction is not immediately obvious without deep reading. Names should disambiguate at first glance.
rigour_checkrigour_runrigour_run_supervised
Clarify idempotence and retry behavior for WRITE tools. Add sentences like: 'Idempotent: calling twice with identical parameters produces one result, not duplicates. Safe to retry on network failures.' Or: 'Non-idempotent: each call creates a new entry. Verify before retrying to avoid duplicates.'
Add error recovery guidance to all tools. Include expected error cases and LLM-actionable recovery steps. Example: 'Error: context_not_found. Action: Ensure rigour_index has been run on the current project first. Call rigour_index() to rebuild the pattern index and try again.'
Reduce ambiguity in tool pairs (e.g. rigour_run vs rigour_run_supervised). Rename to rigour_run_autonomous and rigour_run_supervised to make the distinction immediate. Add descriptions explaining the governance difference: 'Executes with automatic approval gates. For critical operations, use rigour_run_supervised instead.'
Add tool annotations to the MCP protocol registration: mark READ_ONLY tools with readOnlyHint=true, WRITE tools with destructiveHint=true (for deletes) or idempotentHint=true (for safe retries). This lets LLM clients render warnings before execution.
For state-management tools (rigour_remember, rigour_forget, agent registration), add confirmation/dry-run parameters. Example: 'confirm (boolean, optional, default false): If false, return a preview of what would be stored without persisting. Set to true to execute.'
Add pagination support to tools returning lists (rigour_cache_stats, context discovery tools). Include: 'limit (number, optional, default 20, range 1-100): Max results per page. cursor (string, optional): Opaque cursor for next page. Returns: { items (array), total_count (number), next_cursor (string or null) }'
Document prerequisites and dependencies between tools. Add notes like: 'Requires: rigour_index must have been called first. Depends on: current project context set via environment or tool configuration.'
Create a reference table in server documentation mapping tool output fields to downstream tool input parameters. Ensure every ID, reference, or key returned by one tool is explicitly accepted by tools that consume it (e.g., pattern_id returned by rigour_check_pattern must be accepted by rigour_explain).