The Continuous Code Guardian server is an AI-powered code quality assistant that provides context packs and structured guidance for improving code quality, test coverage, documentation, and CI/CD readiness via MCP, without writing files or running tools itself. It offers a suite of tools for various IDEs:
/ca-checkit — Evidence-ranked recommendations with routing cues to other improvement tools.
/ca-smellit — Code smell analysis (smell scorecard) covering quality, architecture, and clean-code issues, with fix prompts.
/ca-testit — Unit test gap analysis (test gap scorecard) and guidance for writing/improving tests, especially for Dart/Flutter.
/ca-commentit — In-source comment guidance via a comment scorecard for targeted additions.
/ca-docit — Structured companion Markdown documentation (outline, API extract, doc drift scorecard) under docs/.
/ca-coverit — Coverage readiness guidance using local coverage reports, aiming for high coverage with an 80% minimum floor.
/ca-sonarit — SonarQube/CI gate prep using SARIF, Sonar, GitLab, or ESLint reports for report-driven improvements.
/ca-aurait — Design quality assessment for Cognite Flows, with rubric scoring and design fix suggestions.
All tools support an optional focus parameter and operate in analyzer modes: none (fast, heuristic), lint (quick), or all (full suite). Polyglot support includes Go, Java, C#, Dart, C++, Scala, and others via heuristics. Integrates with Cursor IDE, VS Code, Antigravity, and Claude Code, with automatic command installation. The server only returns structured context packs; it never writes files, executes tools, or calls LLMs.
Supports C++ with light heuristics for code analysis.
Supports Dart language with named heuristics for code analysis, testing, and coverage.
Provides Flutter-specific test and coverage guidance, including detection and Flutter test/coverage advice.
Supports Scala with light heuristics for code analysis.
Provides a Sonar/CI gate-prep helper that uses local Sonar reports to analyze code quality and guide improvements.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Continuous Code Guardian run /ca-checkit on src/index.js"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
AI-powered continuous code assistant for Cursor IDE, VS Code, Antigravity, and Claude Code via MCP.
Focused public surface:
/ca-checkit — evidence-ranked advisor (routing_cues + urgent|optional recommendations) → confirm subset (default prefers urgent) → run selected children (ca-aurait is never recommended; run it separately)
/ca-smellit — quality-depth + architecture/clean-code prompt (ranked smell_scorecard, severity order) → proceed → apply → post-apply ran/skipped gate (for Sonar/CI gate prep use /ca-sonarit)
/ca-testit — gap scorecard → merge/append into related non-empty tests when appropriate → ran/skipped verify (≤1 fix) → conditional coverit handoff for coverage focus or local misses
/ca-commentit, /ca-docit, /ca-smellit — lightweight JS/TS export, JSDoc, surface, and smell heuristics (not full AST analysis)
/ca-docit — structured companion markdown (canonical outline + API extract + drift scorecard) under docs/ → reconcile or report in sync (no comment edits)
/ca-coverit — coverage readiness → local Cobertura/JSON/LCOV/Clover/Istanbul evidence when present → source-first proceed → source then tests → agent measure→iterate toward goal
/ca-sonarit — Sonar/CI gate-prep helper → local SARIF/Sonar/GitLab/ESLint report evidence → source-first prompt → proceed → source then tests → optional report-driven improve→recheck (≤3 rounds; not a gate pass)
/ca-aurait — Cognite Flows design-quality helper → scored prompt → confirm → apply design fixes
Related MCP server: CodeHealth MCP
All context packs accept UTF-8 text source files through an open suffix matrix. Go, Java, C#, and Dart have named heuristics; C++ and Scala have light heuristics; unknown but source-like files use the other generic profile. Flutter is detected as Dart and receives Flutter test/coverage guidance. These are advisory heuristics, not compiler or language-server analysis; see the Feature 026 quickstart.
For end users installing this MCP into Cursor, VS Code, Antigravity, or Claude Code (Git, PyPI/uvx, local, or binary), see INSTALLATION.md.
Contributor / local editable install:
python -m pip install -e ".[dev]"
cp guardian.config.example.yaml guardian.config.yamlRequires Python 3.12+. Optional analyzer CLIs (Ruff, ESLint, Semgrep, …) are only used when tools run with analyzer_mode=lint or all.
Tool (slash) | Purpose |
| Advisor: evidence-ranked plan from file cues → ask which to run (default prefers urgent) → invoke selected children; never recommends |
| Quality-depth + architecture/clean-code prompt ( |
| Gap scorecard → focused-complete unit tests → ran/skipped verify (≤1 fix); coverit handoff for coverage goals |
| Ranked |
| Structured companion markdown ( |
| Coverage readiness → aspire-high + 80% floor → proceed → source then tests → agent measure→iterate (bounded rounds; MCP does not run coverage) |
| Sonar/CI gate-prep helper (not Sonar / not gate-pass) → source-first prompt → proceed → source then tests → optional report-driven iterate (≤3 rounds; MCP does not run Sonar) |
| Flows design-quality helper → scored prompt (Q1–Q10 / 3.8+) → ask proceed → apply listed design fixes |
How to use them in Cursor, VS Code, Antigravity, or Claude Code: HOW_TO_USE_TOOLS.md.
Slash autocomplete (/ca…) is installed automatically into the workspace —
.cursor/commands/ in Cursor, .github/prompts/ in VS Code, .agent/workflows/ in
Antigravity, .claude/commands/ in Claude Code — when the MCP server starts (requires
"cwd": "${workspaceFolder}" in mcp.json, where supported). Obsolete older /ca-*
shortcut files are removed on install, independently per editor.
See guardian.config.example.yaml. Local guardian.config.yaml and .code-guardian/
are gitignored.
smellit_max_excerpt_bytes / testit_max_excerpt_bytes / commentit_max_excerpt_bytes / docit_max_excerpt_bytes / coverit_max_excerpt_bytes / sonarit_max_excerpt_bytes / aurait_max_excerpt_bytes (default 65536)
coverit_max_report_bytes / sonarit_max_report_bytes (default 65536); sonarit_max_related_files (default 4)
smellit_analyzer_mode / testit_analyzer_mode / commentit_analyzer_mode / docit_analyzer_mode / coverit_analyzer_mode / sonarit_analyzer_mode / aurait_analyzer_mode (default none = fast)
Optional analyzers: toggles for when analyzer_mode is lint or all
Invalid config returns CONFIG_INVALID without leaking secrets
Commentit scorecard & proceed gate: specs/021-commentit-scorecard-gate/quickstart.md
Sonarit report-driven iterate: specs/020-sonarit-report-iterate/quickstart.md
Smellit: specs/016-smellit-quality-depth/quickstart.md (also specs/013-smellit-architecture-refactor/quickstart.md)
Testit: specs/017-testit-verify-loop/quickstart.md (also specs/004-testit-unit-tests/quickstart.md)
Commentit / Docit split: specs/010-commentit-docit-split/quickstart.md
Coverit iterate coverage: specs/015-coverit-iterate-coverage/quickstart.md
Coverit max coverage: specs/014-coverit-max-coverage/quickstart.md
Coverit / Sonarit source prep: specs/012-coverit-sonarit-source-prep/quickstart.md
Aurait: specs/008-aurait-design-quality/quickstart.md
pytest -qFeature 021: specs/021-commentit-scorecard-gate/
Feature 020: specs/020-sonarit-report-iterate/
Feature 017: specs/017-testit-verify-loop/
Feature 016: specs/016-smellit-quality-depth/
Feature 015: specs/015-coverit-iterate-coverage/
Feature 014: specs/014-coverit-max-coverage/
Feature 013: specs/013-smellit-architecture-refactor/
Feature 012: specs/012-coverit-sonarit-source-prep/
Feature 008: specs/008-aurait-design-quality/
Feature 007: specs/007-coverit-coverage-prep/
Feature 004: specs/004-testit-unit-tests/
Feature 003: specs/003-smellit-cleanup-prompt/
Workspace design/UI context pack for Cognite Flows design-quality assessment.
Scans the workspace for design/UI-relevant files under caps — not only the open file.
Optional path prioritizes an entrypoint. Soft Flows gate: weak signals need force;
clearly non-Flows returns not_applicable.
Returns multi-file design_files, condensed rubric Q1–Q10 + 3.8+ target, guidelines_url.
Agent authors scores + fix prompt, asks proceed, applies all listed design fixes on yes.
MCP does not write files, call an LLM, or call Cognite certification APIs.
analyzer_mode: none (default, instant) | lint (quick) | all (full suite, slow).
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | ||
| focus | No | ||
| force | No | ||
| analyzer_mode | No | ||
| workspace_root | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully covers behavioral traits. It explicitly states that MCP does not write files, call an LLM, or use Cognite certification APIs. It also describes the expected agent workflow of scoring, prompting, and applying fixes.
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?
The description is relatively long and contains some jargon (e.g., 'caps', 'Soft Flows gate') that may not be immediately clear. It is structured with line breaks but could be more concise and front-loaded with the main action.
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?
Given the complexity (5 params, no output schema), the description adequately explains the return values (design_files, rubric) and the overall process. However, the lack of explanation for some parameters reduces completeness.
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?
The schema has 0% coverage from descriptions, and the tool has 5 parameters. The description explains the 'analyzer_mode' parameter with its three options and hints at 'force' usage, but it does not describe 'path', 'focus', or 'workspace_root' meaningfully. This leaves a significant gap in understanding parameter semantics.
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 clearly identifies the tool as a workspace design/UI context pack for design-quality assessment. It specifies scanning the workspace for relevant files and returning design files and a rubric. However, it does not explicitly distinguish itself from sibling tools like ca-smellit or ca-docit, which may overlap in purpose.
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?
The description provides some usage guidance, such as using 'force' for weak signals and noting that non-Flows returns 'not_applicable'. However, it lacks explicit instructions on when to use this tool versus alternatives, and it does not mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fast single-file context pack for evidence-ranked condition-check advising. Default skips heavy analyzers.
focus: optional free-form guidance (prefer/exclude tool categories; filters
primary ranked list; other strong cues → deferred_notes).
Trailing text after /ca-checkit becomes focus.
Returns recommendable_tools (never ca-aurait), related_cues, condition_hints,
routing_cues, ranked_recommendations (urgency + rationale + expected_outcome),
and deferred_notes. invented_metrics is always false.
Agent presents an evidence-ranked plan (not fixed catalog order); default subset
prefers urgent; asks proceed + subset, then may invoke selected child tools.
MCP does not write files, call an LLM, or invoke children.
analyzer_mode: none (default, instant) | lint (quick) | all (full suite, slow).
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | ||
| focus | No | ||
| analyzer_mode | No | ||
| workspace_root | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: it does not write files, call an LLM, or invoke children. It also clarifies 'invented_metrics is always false' and the default skip of heavy analyzers.
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?
The description is quite long and includes many details. While front-loaded with purpose, the enumeration of return fields and instructions for the agent could be streamlined.
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?
Given 4 parameters, no output schema, and complex behavior, the description covers most important aspects but lacks detail on 'path' and 'workspace_root', and does not mention error handling or edge cases.
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 coverage is 0%, so description must add meaning. It explains 'focus' parameter in detail and mentions 'analyzer_mode' values. However, 'path' and 'workspace_root' are not described, leaving gaps.
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 clearly states it provides 'evidence-ranked condition-check advising' and lists specific return fields. It distinguishes itself by noting that 'recommendable_tools (never ca-aurait)', which differentiates from sibling ca-aurait.
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?
The description explains when to use it (for context pack advising) and mentions analysis modes. However, it does not explicitly differentiate from other sibling tools like ca-smellit or ca-testit, nor provide when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fast single-file context pack for scorecard-guided in-source comment authoring. Default skips heavy analyzers.
focus: optional free-form additional requests (scope, comment style, what to skip).
Echoed (redacted) in the pack for the Cursor agent. Trailing text after /ca-commentit
becomes focus.
Returns comment_scorecard (ranked gaps; invented_metrics always false) and
apply_policy (comments-only, max_actions=10, no blanket refresh). Agent plans
targeted comment edits, asks Proceed when the list is non-empty, and applies
in-source comments only — does not write companion markdown or rewrite logic.
MCP does not write files or call an LLM.
analyzer_mode: none (default, instant) | lint (quick) | all (full suite, slow).
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | ||
| focus | No | ||
| analyzer_mode | No | ||
| workspace_root | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description explicitly states 'MCP does not write files or call an LLM,' clarifies the agent's role (plans edits, asks Proceed), and specifies output structure. It is transparent about limitations (in-source only, no markdown).
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?
The description is longer than necessary but every sentence adds value: purpose, parameters, behavior, and workflow. It is front-loaded with the core purpose and structured logically.
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?
Given no output schema, the description adequately explains return values (comment_scorecard, apply_policy) and the agent workflow. However, it lacks detail on parameters 'path' and 'workspace_root', leaving some ambiguity for a tool with 4 parameters and no annotations.
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 coverage is 0%, so description must compensate. It explains 'focus' (trailing text echoed) and 'analyzer_mode' (none, lint, all). However, 'path' and 'workspace_root' are only implied by 'single-file' context and not described in detail.
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 clearly states it is for 'scorecard-guided in-source comment authoring' with specific outputs (comment_scorecard, apply_policy). While it doesn't explicitly differentiate from siblings, the purpose is specific and actionable.
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?
The description mentions analyzer modes and default skip of heavy analyzers, providing implicit usage context. However, it does not explicitly state when to use this tool over siblings like ca-docit or ca-checkit, nor does it list exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fast single-file context pack for coverage-compliance / source readiness preparation.
focus: optional free-form guidance (target %, branch focus, rewrite tests).
Trailing text after /ca-coverit becomes focus. Named mid-range % = hard stop;
no focus → aspire to maximum practical line/statement coverage (100% when
achievable) with 80% minimum floor.
Returns suggested_test_path, optional coverage_report_summary and coverage_miss_cues
(Cobertura/coverage JSON/LCOV/Clover/Istanbul when locally available), measure_hints,
measure_prerequisites (with install_examples when tools/packages are missing),
target_coverage_frame, iterate_policy (bounded measure→improve after proceed;
mcp_runs_coverage is always false), apply_policy, and source_change_hints.
Coverit MCP is NOT a coverage runner — agent authors a source-first readiness
prompt, asks all-or-nothing proceed, applies listed source then tests, then the
IDE agent may run how-to-measure and iterate improve→remeasure toward the goal
(see iterate_policy). MCP does not write files, call an LLM, install packages,
or execute coverage tools. UTF-8 text source is accepted across the open language
matrix, with Go/Java/C#/Dart/Flutter measurement examples when applicable.
analyzer_mode: none (default, instant) | lint (quick) | all (full suite, slow).
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | ||
| focus | No | ||
| analyzer_mode | No | ||
| workspace_root | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: it does not write files, call an LLM, install packages, or execute coverage tools. It lists output fields and mentions the tool is a 'source-first readiness prompt.' This provides useful transparency about its non-destructive and preparatory nature.
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?
The description is front-loaded with a clear summary and uses bullet-like clarity (lists output fields, analyzer modes). It is somewhat verbose but every sentence adds value. Could be trimmed slightly without losing meaning.
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?
Given no output schema and no annotations, the description covers inputs, behavior, constraints, and output fields sufficiently. It mentions supported languages, measurement examples, and the iterate_policy. A few output fields (source_change_hints, measure_hints) are listed without explanation, but overall it is complete for a tool of this complexity.
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%. The description explains 'focus' and 'analyzer_mode' in detail (e.g., focus as free-form guidance, analyzer_mode values). However, 'path' and 'workspace_root' are not explicitly described, leaving ambiguity about their purpose.
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 clearly states it is a 'Fast single-file context pack for coverage-compliance / source readiness preparation.' It distinguishes itself by noting it is NOT a coverage runner and that it generates a prompt for the agent. However, it could more explicitly differentiate from sibling tools like ca-testit or ca-checkit.
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?
The description explains when to use the focus parameter, the default behavior (80% minimum floor, aspire to 100%), and what the tool does not do (write files, call an LLM, etc.). It provides good guidance on invoking the tool via trailing text. However, it lacks a clear when-not-to-use statement relative to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fast single-file context pack for structured companion markdown (outline + API extract + drift scorecard). Default skips heavy analyzers.
focus: optional free-form additional requests (markdown emphasis within
canonical H2s, scope, what to skip). Echoed (redacted) in the pack.
Trailing text after /ca-docit becomes focus.
Returns suggested_markdown_path (docs/ + CAPITAL basename), markdown_exists,
existing_markdown_excerpt, outline_contract (exact H2s), api_surface_extract
(public/exported only), doc_drift_scorecard (ranked staleness), invented_metrics
always false. Agent writes/reconciles companion .md or reports in sync and
skips churny rewrite; does not edit source comments. MCP does not write files
or call an LLM.
analyzer_mode: none (default, instant) | lint (quick) | all (full suite, slow).
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | ||
| focus | No | ||
| analyzer_mode | No | ||
| workspace_root | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Thoroughly discloses return fields, that invented_metrics is always false, that MCP does not write files or call LLM, and how focus parameter works (trailing text). No annotations provided, so description carries full burden and meets it.
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?
Front-loaded with key purpose, uses bullet-style listing for clarity. Slightly verbose but each sentence adds value. Could be more streamlined.
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?
Covers return values in detail without output schema, describes main behaviors. Missing parameter explanations for path and workspace_root, but overall fairly complete for a tool with no annotations.
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?
Describes 'focus' and 'analyzer_mode' with details, but 'path' and 'workspace_root' are not explained. Schema coverage is 0%, so description must compensate but is incomplete.
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?
Description clearly states it produces a 'single-file context pack for structured companion markdown' with specific outputs (outline, API extract, drift scorecard). Distinguishes from sibling ca-* tools by specifying its unique purpose and default behavior.
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?
Provides guidance on when to use ('fast', 'default skips heavy analyzers'), analyzer_mode options, and instructions for the agent. Lacks explicit exclusion of alternatives but context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current-file context pack for quality-depth + architecture-aware improvement prompts.
Packages redacted excerpt, optional findings, ranked smell_scorecard (severity + theme;
invented_metrics always false), apply_policy, and architecture_hints. Agent authors an
improvement prompt honoring scorecard ranks and severity order (correctness/safety →
clean-code/cohesion → architecture/performance); asks all-or-nothing proceed; may apply
listed splits first then primary/call-sites (soft cap: primary + ≤5 additional); after
apply should run a bounded post-apply gate (related tests + lint/typecheck when
discoverable) with explicit ran/skipped reporting and at most one fix round. For
Sonar/CI gate prep and optional report-driven iterate, use ca-sonarit instead. MCP does
not write files, call an LLM, or run the post-apply gate.
analyzer_mode: none (default, fast heuristic scorecard) | lint (quick) | all (full suite).
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | ||
| focus | No | ||
| analyzer_mode | No | ||
| workspace_root | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
In the absence of annotations, the description fully discloses behavioral traits: what the tool does (packages context), what it does NOT do (write files, call LLM, run post-apply gate), details about the scorecard (invented_metrics always false), analyzer modes, and soft caps on additional calls.
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?
The description is front-loaded with the core purpose and then provides detailed behavioral context. While it is lengthy, each sentence adds necessary information for correct agent usage. It is well-structured but could be slightly more concise.
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?
Given no output schema, the description thoroughly explains what the tool returns (scorecard contents, architecture hints, etc.) and the expected agent workflow. It covers all critical aspects for correct invocation and follow-up actions.
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 coverage is 0%, so description must compensate. It partially explains analyzer_mode ('none (default, fast heuristic scorecard) | lint (quick) | all (full suite)') but does not explain path, focus, or workspace_root. This adds some value but leaves significant gaps.
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 clearly states the tool's purpose: to provide a 'current-file context pack for quality-depth + architecture-aware improvement prompts'. It specifies what is packaged (excerpt, findings, scorecard, etc.) and distinguishes itself from the sibling ca-sonarit.
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?
The description gives explicit guidance on when to use this tool vs ca-sonarit: 'For Sonar/CI gate prep and optional report-driven iterate, use ca-sonarit instead.' It also outlines the workflow for the agent, including authoring a prompt, asking all-or-nothing proceed, applying splits, and running a post-apply gate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fast primary-file context pack for SonarQube-style quality-gate preparation.
focus: optional free-form guidance (theme focus, rewrite tests, skips).
Trailing text after /ca-sonarit becomes focus.
Returns related_files, suggested_test_path, optional quality_report_summary and
quality_gap_cues (including local GitLab Code Quality/ESLint formats),
change_hints, verify_hints, prep_themes, iterate_policy, apply_policy, and
source_change_hints. Sonarit is NOT SonarQube and does NOT prove gate pass —
agent authors a source-first prep prompt, asks all-or-nothing proceed (source
edits then tests), then may run evidence-gated report-driven improve→recheck
(default max 3 rounds; pause/resume on missing tools; MCP never runs Sonar).
Not a smellit quality-depth campaign — use ca-smellit for that. MCP does not
write files, call an LLM, or run SonarQube.
analyzer_mode: none (default, instant) | lint (quick) | all (full suite, slow).
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | ||
| focus | No | ||
| analyzer_mode | No | ||
| workspace_root | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses behaviors: 'MCP does not write files, call an LLM, or run SonarQube,' and outlines the iterative process. It also explains the analyzer_mode options. It does not explicitly mention destructive actions or auth needs, but the tool appears read-only, so this is acceptable.
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?
The description is front-loaded with purpose but becomes verbose with procedural details. While informative, it could be more concise. Sentences are long, and some information (like the default max 3 rounds) could be streamlined.
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?
Given the tool's complexity and 0% schema coverage, the description should cover all 4 parameters. It explains focus and analyzer_mode but omits path and workspace_root. The output is listed but not fully detailed. The description provides a good overview of the workflow but lacks complete parameter documentation.
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 coverage is 0%, so description must compensate. It explains 'focus' (optional free-form guidance) and 'analyzer_mode' (none/lint/all) well. However, 'path' and 'workspace_root' are not described. The description adds value for some parameters but not all.
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 clearly states the tool's purpose: 'Fast primary-file context pack for SonarQube-style quality-gate preparation.' It uses a specific verb (context pack) and resource (quality-gate prep). It also distinguishes itself from sibling 'ca-smellit' by noting it is not a depth campaign.
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?
The description explicitly provides usage guidelines: it states when to use ('for quality-gate preparation'), when not to use ('Not a smellit quality-depth campaign — use ca-smellit for that'), and describes the workflow (source-first prep prompt, all-or-nothing proceed, evidence-gated improve→recheck). It also explains that MCP does not run SonarQube.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fast single-file context pack for unit-test authoring + gap scorecard.
Packages redacted excerpt, tests_root / suggested_test_path, run_hints, and ranked
test_gap_scorecard (severity + theme; invented_metrics always false). Agent writes
tests under tests/ (merge/append an existing non-empty related suite unless focus
requests rewrite), then verifies with explicit ran/skipped reporting and at most one
fix round on listed test paths only — never edits production. Missing runner → skipped
+ hints (no pause-resume). Coverage focus or local uncovered evidence can recommend
ca-coverit. MCP does not write
files, call an LLM, or run tests. Accepts UTF-8 text source via the open language
matrix; Dart projects receive Flutter-aware guidance.
analyzer_mode: none (default, fast heuristic scorecard) | lint (quick) | all (full suite).
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | ||
| focus | No | ||
| analyzer_mode | No | ||
| workspace_root | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description fully discloses behavioral traits: 'MCP does not write files, call an LLM, or run tests.' It specifies that the agent should merge/append existing test suites unless focus requests rewrite, and that missing runner results in skipped+hints. It limits fix rounds to one and only on listed test paths, and explicitly states 'never edits production.' This is comprehensive and exceeds what annotations would typically provide.
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?
The description is a single dense paragraph that front-loads the purpose and then covers details in a logical flow. Although it is somewhat lengthy, every sentence adds value. Minor improvement could be breaking into bullet points or structured sections for clarity, but it remains effective and not unnecessarily verbose.
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?
Given the tool's complexity (unit test authoring with gap analysis, multiple analyzer modes, and no output schema or annotations), the description provides complete context. It explains the output format (ranked test_gap_scorecard), instructions for the agent (merge/append, verification steps, fix rounds), and even mentions Dart-specific guidance. The recommendation for ca-coverit adds completeness for related workflows.
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%, so the description must add meaning. It explains the 'analyzer_mode' parameter with three clear options and their effects: 'none (default, fast heuristic scorecard) | lint (quick) | all (full suite).' For 'path' and 'focus', it hints at their roles via context (tests_root, merge/append vs rewrite). 'workspace_root' is not explained, but overall the description significantly compensates for the lack of schema descriptions.
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 first sentence clearly states the tool's purpose: 'Fast single-file context pack for unit-test authoring + gap scorecard.' It then details the specific outputs (redacted excerpt, tests_root, run_hints, test_gap_scorecard), making the function unambiguous. The mention of ca-coverit as an alternative provides implicit sibling differentiation.
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?
The description gives explicit context for when to use this tool: for unit test authoring with gap analysis. It recommends ca-coverit for coverage-related tasks, providing an alternative. However, it does not explicitly state when not to use this tool or list all scenarios that would favor a different sibling tool.
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. Dates show when Glama detected each change.
v1.30.0ca-auraitca-checkitca-commentitca-coveritca-docitca-smellitca-sonaritca-testitMost tools have distinct purposes (design, testing, commenting, documentation, coverage, Sonar preparation), but ca-checkit's meta-tool role may be confused with analysis tools like ca-smellit or ca-sonarit. Descriptions help clarify its routing function.
All tools follow the pattern ca-[word]it (e.g., ca-checkit, ca-smellit). The naming is consistent with lowercase and hyphens, and ca-aurait is the only slight outlier but still fits the pattern.
Eight tools cover a comprehensive set of code quality activities without being excessive. Each tool serves a specific subdomain (design, smell, test, comment, doc, coverage, Sonar), and the count is well-scoped for the server's purpose.
The tool set covers design, quality, testing, commenting, documentation, coverage, and SonarQube preparation. Minor gaps like security or dependency analysis exist but are implicitly covered by ca-smellit and ca-sonarit, ensuring most workflows are supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AI code review for GitHub PRs with an MCP autofix loop for Claude Code and Cursor
AI-native git hosting — repos, PRs, issues, CI gates, and AI code review over MCP (60 tools).
Your Aurentia workspace — projects, CRM, tasks, deliverables — in Claude, Cursor or any MCP client.
Persistent memory for Claude Code and Cursor. Stop re-explaining your project every session.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ijanzz5621/mcp-code-guardian'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
