Skip to main content
Glama
rust-works

omni-dev

by rust-works
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

coverage_diff

Analyze git diff patch coverage from a line coverage report to report patch-coverage percentage and gate status, returning Markdown, YAML, or JSON.

Instructions

Analyze diff/patch coverage from a per-line coverage report plus the git diff, and return the rendered report with the patch-coverage percentage and gate result as YAML. Read-only. Mirrors omni-dev coverage diff. report is a required filesystem path to the head coverage report (lcov / llvm-cov-json / cobertura, auto-detected). format renders the report as markdown (default), yaml, or json. Unlike the CLI this tool never fails the call on a low fail_under_patch or fail_under_lines; it reports below_gate: true / below_line_gate: true instead.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
formatNoRendered output format. Defaults to `markdown`.
reportYesHead coverage report path (lcov / llvm-cov-json / cobertura). Required.
run_urlNoLink to the CI run (markdown footer).
base_refNoBase revision to diff against (default: merge-base of `origin/main` and `HEAD`).
base_shaNoBase (merge-base) commit SHA shown in the markdown `Comparing` line.
head_refNoHead revision the report was measured at (default: `HEAD`).
head_shaNoHead commit SHA shown in the markdown `Comparing` line.
all_filesNoReport per-file deltas and indirect changes for ALL files, not just the ones the diff touches.
repo_pathNoPath to the git repository. Defaults to the current working directory.
commit_urlNoCommit-URL prefix for linking SHAs.
artifact_urlNoLink to the full coverage-summary artifact (markdown footer).
strip_prefixNoOverride the path prefix stripped from report paths to make them repo-relative (default: the repository working directory).
report_formatNoFormat of `report` and of every additional report (auto-detected by default).
baseline_reportNoOptional baseline coverage report path; enables project deltas and indirect-change detection.
collapse_rangesNoCollapse consecutive uncovered new lines into ranges (e.g. `9-11`).
fail_under_linesNoReport a below-line-gate result when overall line coverage is below this percentage, or the report has no executable lines (the tool never fails the call; it reports `below_line_gate` instead).
fail_under_patchNoReport a below-gate result when patch coverage is below this percentage (the tool never fails the call; it reports `below_gate` instead).
additional_reportsNoFurther shard reports to merge with `report` when the coverage run was split across jobs. The merge is a union of files and executable lines, taking the larger hit count per line; a shard with no executable lines is an error.
ignore_filename_regexNoExclude files whose repo-relative path matches any of these regexes from both the head and baseline reports before computing the diff. Matching is unanchored, applied after `strip_prefix` (same semantics as `cargo llvm-cov --ignore-filename-regex`).
baseline_report_formatNoFormat of `baseline_report` (auto-detected by default).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.45.0
    • addedInput schema / properties / additional_reports
      Added value: +{
+  "default": [],
+  "description": "Further shard reports to merge with `report` when the coverage run was\nsplit across jobs. The merge is a union of files and executable lines,\ntaking the larger hit count per line; a shard with no executable lines is\nan error.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • addedInput schema / properties / fail_under_lines
      Added value: +{
+  "default": null,
+  "description": "Report a below-line-gate result when overall line coverage is below this\npercentage, or the report has no executable lines (the tool never fails\nthe call; it reports `below_line_gate` instead).",
+  "format": "double",
+  "type": [
+    "number",
+    "null"
+  ]
+}
    • changedInput schema / properties / report_format / description
      Previous value: -"Format of `report` (auto-detected by default)."New value: +"Format of `report` and of every additional report (auto-detected by\ndefault)."
  2. Changed3 schema fields changedv0.33.0
    • removedInput schema / description
      Removed value: -"Parameters for the `coverage_diff` tool."
    • addedInput schema / properties / ignore_filename_regex
      Added value: +{
+  "default": [],
+  "description": "Exclude files whose repo-relative path matches any of these regexes from\nboth the head and baseline reports before computing the diff. Matching is\nunanchored, applied after `strip_prefix` (same semantics as\n`cargo llvm-cov --ignore-filename-regex`).",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • removedInput schema / title
      Removed value: -"CoverageDiffParams"
  3. Addedv0.32.0

TDQS

A4.1/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and delivers real behavioral context: it is read-only, and unlike the CLI it never fails the call on a low gate, instead reporting `below_gate`/`below_line_gate`. That is exactly the kind of non-obvious trait an agent needs. Minor tension: it says the report is returned 'as YAML' while the schema default is markdown, which slightly muddies the output contract.

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?

Front-loaded with purpose and output, then read-only status, then the required parameter and format, then gate behavior. Each sentence conveys distinct information with little waste, though the 'as YAML' phrasing slightly conflicts with the markdown default and costs a bit of precision.

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?

For a 20-parameter tool with no output schema, the description covers the essential non-obvious behavior (read-only, non-failing gate semantics) and the return shape (patch-coverage percentage and gate result), while the schema's 100% description coverage documents the remaining parameters. Complete enough, though it could say more about the format default given the YAML/markdown mismatch.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3; the description adds meaning by noting `report` is a required filesystem path with auto-detected format, that `format` renders markdown (default)/yaml/json, and how `fail_under_patch`/`fail_under_lines` behave (report flags rather than fail). This exceeds the schema on the gate parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Analyze) and resource (diff/patch coverage) plus the exact inputs (per-line coverage report + git diff) and output (rendered report with patch-coverage percentage and gate result). No sibling tool in the list does coverage analysis, so it is unambiguous, and 'Mirrors `omni-dev coverage diff`' anchors it for CLI users.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The purpose strongly implies when to reach for it (checking patch coverage of a diff), and it clarifies that `report` is required, but there is no explicit when-to-use vs when-not guidance or named alternatives. With no competing sibling, implied usage is adequate but not spelled out.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools