Skip to main content
Glama
Sign In
adb-mcp

adb-mcp

by iksnerd
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Local

get_file_coverage

Reports JaCoCo line and per-method coverage for a single source file, listing missed and partially-covered lines so you can target the weakest file in a package.

Instructions

Same JaCoCo run and task fallback as get_coverage_report, scoped to one source file: the missed and partially-covered line numbers plus per-method detail. Use it after get_coverage_report names the weakest package. file matches by suffix across every module (an ambiguous name returns every match; a miss lists the files that have data). JVM unit tests only. Pass json=true for structured JSON.

Input Schema

NameRequiredDescriptionDefault
argsNoExtra arguments passed to Gradle (e.g. --stacktrace).
fileYesSource file to report coverage for — a filename (e.g. Foo.kt) or package-qualified path (e.g. com/example/Foo.kt). Matched by suffix; an ambiguous bare filename returns every match.
jsonNoReturn structured JSON instead of the human-readable text summary.
taskNoGradle task that generates the JaCoCo XML report. Defaults to jacocoTestReport, which is NOT a task the Android Gradle plugin defines — it exists only if the project declares it. If it is missing, check list_gradle_tasks for AGP's built-in "createDebugUnitTestCoverageReport" (present when a build type sets enableUnitTestCoverage = true). Module-qualified names work: ":app:jacocoTestReport".
project_dirNoPath to the Android project root containing the Gradle wrapper (gradlew). Optional if session_set_defaults has pinned a project_dir for this session.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.4/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 does most of it: it discloses suffix-based matching, that ambiguous bare filenames return every match, that a miss lists files that do have data, the jacocoTestReport default plus the AGP fallback, and the JVM-only test scope. The only gap is that it never signals that invoking it runs a Gradle task (cost/latency), which matters for an agent deciding whether to call it repeatedly.

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?

Four tight sentences, front-loaded with the scope statement before the routing advice. Slight redundancy with the schema ('Pass json=true for structured JSON' and suffix matching are both already documented in the property descriptions).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, and the description compensates by naming the returned fields (missed/partial line numbers, per-method detail). Combined with the ambiguity and no-data behaviors, an agent has everything needed to call it and interpret the result.

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 coverage is 100%, so file matching, the json toggle, and the task fallback are already fully documented in the schema. The description restates the suffix-match behavior and the json flag rather than adding new syntax or format detail, so the baseline 3 applies.

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 and resource ('missed and partially-covered line numbers plus per-method detail' for one source file) and explicitly contrasts its scope with get_coverage_report. An agent can distinguish it from the package-level sibling without opening either schema.

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

Usage Guidelines5/5

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

Gives explicit sequencing ('Use it after get_coverage_report names the weakest package') and a hard exclusion ('JVM unit tests only'). The alternative is named along with the condition that selects it.

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