Skip to main content
Glama
ijanzz5621

Continuous Code Guardian

by ijanzz5621

ca-coverit

Analyze source code readiness for coverage compliance and provide actionable measurement hints, iteration policies, and test improvement suggestions.

Instructions

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).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathNo
focusNo
analyzer_modeNo
workspace_rootNo
Behavior4/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

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