Skip to main content
Glama

get_file_coverage

Retrieve JaCoCo line and branch coverage for a single source file, showing missed and partially-covered lines plus per-method detail. Use after a package-level coverage report to identify which specific lines need a test.

Instructions

Same JaCoCo run as get_coverage_report (default task 'jacocoTestReport', same fallback to AGP's 'createDebugUnitTestCoverageReport' when that task doesn't exist), scoped to one source file: line/branch coverage, the exact missed and partially-covered line numbers, plus per-method detail — the per-function breakdown get_coverage_report's package-level summary doesn't carry. Use it to find WHICH lines to write a test for, after get_coverage_report says which package is weakest. file matches by suffix (e.g. "Foo.kt" or "com/example/Foo.kt") across every module of a multi-module build; an ambiguous bare filename returns every matching file, a miss lists what coverage data does exist so you can correct it. Same JVM-unit-test-only scope as get_coverage_report. Pass json=true for structured JSON instead of the text form.

Input Schema

TableJSON 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.
Behavior4/5

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

No annotations are provided, so the description carries full burden. It discloses the underlying JaCoCo task and fallback, the file matching algorithm, the output format options (text vs JSON), the scope (JVM unit tests), and the relationship to get_coverage_report. It is non-destructive, but this is not explicitly stated; however, the read-only nature is implied by the coverage analysis context.

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 a single well-structured paragraph that packs essential information without redundancy. It starts with the core purpose, then flows into usage guidance, file matching details, and output options. It is concise but could benefit from slight formatting (e.g., bullet points for clarity), though current structure is effective.

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 the tool's complexity (5 parameters, no output schema, no annotations), the description covers all key aspects: purpose, usage relation to sibling, parameter behavior, file matching edge cases, and output format options. It does not describe the exact structure of the JSON/text output, but the details provided are sufficient for an agent to invoke the tool correctly.

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 baseline is 3. The description adds significant value beyond the schema: it explains the default task behavior and fallback, clarifies that file matching is by suffix, describes handling of ambiguous names and misses, and notes the optionality of project_dir. This extra context justifies a score above baseline.

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?

The description clearly states the tool's purpose: a JaCoCo coverage report scoped to one source file, providing line/branch coverage, missed lines, and per-method detail. It distinguishes itself from the sibling get_coverage_report by explaining that it operates at the file level with per-function breakdown, not package-level summary.

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?

Explicitly guides when to use this tool: 'Use it to find WHICH lines to write a test for, after get_coverage_report says which package is weakest.' It also explains file matching behavior (suffix match, ambiguous names return all matches, misses list available data) and the scope (JVM unit tests only), providing clear context for selection.

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/iksnerd/adb-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server