Enforces architectural invariants and code quality rules inside your AI agent's edit loop.
Scored across 4 tools
Each tool targets a clearly distinct action: explain_symptom maps a described problem to rules, lookup_rule retrieves details for a named rule, get_install_commands provides installation commands, and request_rule submits a new rule request. The descriptions explicitly clarify when to use each, so there is no overlap.
All tool names follow a consistent snake_case verb_noun pattern (explain_symptom, get_install_commands, lookup_rule, request_rule). There are no deviations in style or convention.
Four tools is slightly on the low side but reasonable for a server focused on rule lookup, symptom explanation, installation, and new rule requests. It is not thin enough to be problematic, but adding a list_rules tool would improve coverage.
The set covers rule lookup, symptom mapping, installation, and creating new rule requests, but lacks a tool to list all rules, update/delete existing rules, or run the actual audit. These are notable gaps for a rule management surface.
Map a natural-language symptom (e.g. 'my app is slow', 'hardcoded password', 'infinite react loop') to the relevant Code Auditor rule(s) and their fixes. Call this when a user describes a problem rather than naming a rule.
| Name | Required | Description | Default |
|---|---|---|---|
| symptom | Yes | A plain-language description of the problem. |
| Name | Required | Description |
|---|---|---|
| hint | No | |
| matches | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is fully covered. The description adds that output includes rules plus their fixes, but since an output schema exists this is largely redundant rather than genuinely new behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both carrying distinct information: first the mapping behavior with examples, second the call condition. No filler and the purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With rich annotations, an output schema, and a fully documented single parameter, the description only needs to convey intent and routing, which it does. Nothing an agent needs to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single 'symptom' parameter, which sets a baseline of 3. The three inline examples ('my app is slow', 'hardcoded password', 'infinite react loop') go beyond the schema's terse 'plain-language description' by showing the expected granularity and free-text style.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Map) with both the input resource (natural-language symptom) and the output resource (Code Auditor rule(s) and their fixes), with concrete examples. The clause 'rather than naming a rule' cleanly separates it from the lookup_rule sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the trigger condition ('Call this when a user describes a problem') and the discriminating condition against the alternative ('rather than naming a rule'), which is exactly the decision an agent must make between this and lookup_rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the exact install commands for Code Auditor for a given AI agent. Call this when a user asks how to install Code Auditor, or asks for the command for a specific agent (claude, cursor, codex, gemini, agents, zcode, or all).
| Name | Required | Description | Default |
|---|---|---|---|
| agent | Yes | The AI agent to install for (e.g. claude, cursor, codex, all). |
| Name | Required | Description |
|---|---|---|
| note | No | |
| agent | Yes | |
| commands | Yes | |
| displayName | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered by structured data. The description adds only the list of accepted agent values, with no note on whether the list is exhaustive, how unknown values are handled, or any auth/rate-limit context. With annotations doing the heavy lifting, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler: the first states what is returned, the second states when to call it. The purpose is front-loaded ahead of the trigger condition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so the description need not explain return values, and it covers what the tool does, when to call it, and the valid agent inputs. Nothing needed to invoke this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single required 'agent' parameter is documented in the schema itself, so the baseline is 3. The description does enumerate additional accepted values (gemini, agents, zcode) beyond the schema's 'e.g.' examples, which is a mild value add but not formatted as an authoritative value set.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Return the exact install commands for Code Auditor') plus the scoping dimension ('for a given AI agent'). It is unambiguous and unlike any sibling (explain_symptom, lookup_rule, request_rule), so an agent can select it immediately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit trigger conditions: 'Call this when a user asks how to install Code Auditor, or asks for the command for a specific agent.' No alternative tool competes for this task, so naming one is unnecessary; the use case is fully pinned down.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the rule kind, description, default severity, detection method, and threshold for a given Code Auditor rule or analyzer. Call this when a user asks what a specific rule does (e.g. import-ban, sql-injection, n+1).
| Name | Required | Description | Default |
|---|---|---|---|
| rule_id | Yes | Rule or analyzer id, e.g. import-ban, sql-injection, n+1. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds only a list of returned fields, which overlaps the existing output schema rather than disclosing new behavioral traits such as error behavior for unknown ids.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the return payload and followed immediately by the trigger condition and examples. No redundant or filler text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with a full output schema and complete annotations, the description supplies the trigger condition and the returned shape. It is essentially complete, with only the untested edge case of an unknown rule_id left implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the parameter is fully documented in the schema, including the same example ids. The description adds no format or resolution semantics beyond what the schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a clear verb (return/look up) and resource (rule/analyzer) and enumerates the specific fields returned (kind, description, severity, detection method, threshold). It is specific enough to distinguish purpose from a generic lookup, but it never contrasts itself with siblings like request_rule or explain_symptom.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use guidance: 'Call this when a user asks what a specific rule does' with concrete example ids. It stops short of naming exclusions or pointing to an alternative tool, so it is clear context without routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Request a new Code Auditor rule. Call lookup_rule or explain_symptom first to confirm no existing rule covers it. Provide a minimal example that should be flagged and a corrected example that should not. Reduce both to the smallest code that shows the difference, and remove secrets and proprietary identifiers. Returns a receipt id.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | ||
| signal | Yes | ||
| symptom | Yes | ||
| languages | Yes | ||
| toolVersion | No | ||
| cleanExample | Yes | ||
| firingExample | Yes |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| duplicateSubmission | Yes | |
| existingRuleMatches | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the risky profile (destructiveHint=true, non-idempotent, not read-only), so the description is not the sole carrier here. It adds useful context — the submission hygiene requirement to minimize examples and strip secrets/proprietary identifiers, plus the return value ('a receipt id') — but never explains what the destructive write actually affects, whether the request persists, or what review/approval follows. Adequate but with a clear gap given a destructive, non-idempotent operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, front-loaded with purpose, then precondition, then content requirements, then return value. No filler and no repetition of schema constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema covers the return shape (and the receipt id is mentioned anyway), so return values are handled. However, for a destructive, non-idempotent submission tool with six required parameters and no schema descriptions, the definition omits what happens after submission, whether the request is persisted or reviewable, and any permission requirements — the remaining gaps an agent would want before committing a write.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 7 parameters, so the schema documents names and constraints only. The description meaningfully explains two of them ('a minimal example that should be flagged' and 'a corrected example that should not', mapping to firingExample/cleanExample), but leaves title, symptom, signal, languages, and toolVersion with no meaning beyond their names and length limits. Partial compensation, not full.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Request a new Code Auditor rule') and immediately distinguishes itself from siblings by naming lookup_rule and explain_symptom as the discovery tools that precede it. An agent can tell this apart from the read-only lookup tools without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit precondition ('Call lookup_rule or explain_symptom first to confirm no existing rule covers it'), which doubles as a when-not-to-use rule: if an existing rule covers the symptom, don't call this. The alternatives are named directly rather than implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
request_ruleexplain_symptomget_install_commandslookup_ruleChecks AI-written code against your rules as it is written, and keeps a record of what it found.
Lints + auto-fixes how AI coding agents discover any new product. 24 rules, 6 tools, score 0-100.
Lets coding agents check their own code for leaked secrets, risky dependencies and AI-code mistakes
Pre-execution governance for AI agents. Deterministic PASS/FAIL/REVIEW verdicts, replayable proof.
Add one secure layer between your agents and this server.
