Coco MCP
Know What is Untested
AI coding agents generate tests faster than any engineer. The problem is they do not know what your test suite already covers. Coco MCP Server connects any AI agent to runtime coverage data from your instrumented build. The agent queries which statements, branches and conditions were hit. It writes tests for the ones that were not, and verifies the result.
Your Team Already Tests. The Question is Whether You Know What's Left Untested.
AI is changing how fast tests get written, however, it hasn't changed whether anyone knows what those tests actually cover. That gap shows up at release time, at audit time, or after an incident.
Lower the cost of getting to release
Closing the last stretch of a coverage target is repetitive work. When it's measured and automated, senior engineers spend that time reviewing instead of producing.
Make "are we ready to release" a factual answer
A coverage number from an actual test run, with gaps named precisely, replaces a guess with evidence in the release meeting.
Cut regression time after every change
Knowing exactly which tests a change affects means re-running dozens of tests, not thousands, on every commit.
MCP is how AI agents talk to tools
Coco MCP Server is how they talk to your coverage data
An agent can read every line of your codebase and still not know which parts of the code were executed by a test run. Only a Coco instrumented build records that.
What MCP does
Model Context Protocol (MCP) is the standard interface for connecting AI coding agents to external tools and data sources. GitHub Copilot in VS Code, Claude Code and other agents act as MCP hosts. A server exposes tools the agent can call. The agent decides when to call them, what to ask, and what to do with the result.
Without it, getting coverage numbers in front of an AI agent is a manual chore: export a report, copy the results, paste them into the chat, and hope nothing is misread. The agent then works from that one-time snapshot, with no way to check itself after writing new tests.
What Coco MCP Server adds
The Coco MCP Server removes that manual step entirely. The agent asks for coverage data directly and gets back only what it needs: first a quick check that data exists, then a high-level summary, then the exact locations of untested code once it knows where to look. After it writes and runs new tests, it checks its own work and confirms whether coverage actually improved, automatically.
Under the hood, this means wrapping cmreport and cmcsexeimport in tools the agent calls directly, then re-importing the updated .csexe report and re-querying after each change.
Measured on the Coco Parser Sample — Real Agent Session Results
Coco parser sample – real agent session – code coverage demo with two natural-language prompts
Two prompts. Eight tool calls. No manual reports.
natural-language prompts: analyze coverage, then improve parser.cpp
MCP tool calls automating each reporting and import step
unexecuted statements identified as exact file:target locations for new tests
Global decision coverage: before vs after
Results from the Coco parser sample included in every installation. Your numbers will differ. See the full agent session walkthrough.
The agent estimates which parts of the code are untested
It reads source and test files to infer what is covered. Some gaps identified may not exist; others may be missed entirely. Without runtime data, there is no way to distinguish between the two.
Tests are written for parts of the code already executed
Without runtime data, the agent may duplicate coverage it cannot see. Real gaps remain open until discovered at review or audit.
The agent queries unexecuted code items from the instrumented build
Coco's instrumented build records which parts of the code were executed by a test run. The MCP server exposes this data as queryable tools. The agent gets the exact locations of untested source code, writes tests for those. It rebuilds the project, re-runs the tests and gets new coverage data for analysis.
Learn how Coco and AI can turn your coverage data into a full risk assessment your team can actually act on, sprint after sprint.
Watch the webinarThe agent queries exactly the data the current decision requires, with no raw reports and no wasted context
| Tool | Scope | Detail |
|---|---|---|
check_coverage_summary |
Database | Has coverage data been imported? Yes / No. |
get_coverage_overview |
Project / File / Function | Global %, per-file breakdown, optional per-function breakdown with cyclomatic complexity. Agent prioritizes which files to inspect next. |
get_file_coverage_detail |
File / Line | Exact file:target locations by status: unexecuted, dead-code, executed. Optionally maps each point to the tests that executed it. |
MCP Host Compatibility
Works with the agent your team already uses
Coco MCP Server communicates over stdio and follows the MCP standard. Any compliant host connects without changes to workflow prompts.
What Changes When Coverage Comes From Instrumentation
Engineering time shifts from writing to reviewing
The agent queries unexecuted instrumentation points from the .csmes database, writes tests for the exact file:line locations, and re-verifies. Your engineers review the result, not produce it.
Every percentage point has a .csexe behind it
Coverage comes from cmreport reading a .csmes database built by instrumented test runs. Untested code is named by file and line. That number goes into your release decision or your safety case.
Agent-written tests enter the TÜV-certified evidence chain
The agent writes tests. Coco instruments them. The execution data lands in the same .csmes database your safety case already cites. SGS TÜV Saar certified up to ASIL D. No new tool qualification needed.
Re-run the tests that cover a patch. Not all of them.
analyze_patch_coverage_from_diff takes the output of git diff and returns the tests that execute the changed lines, with their current pass/fail state. Re-run those. Not all 4,000.
C, C++, C#, Python, Tcl, and QML in one instrumented build
Most enterprise products mix languages across services, UI layers and embedded components. Coco instruments all of them together, collecting results in one .csmes database. No separate toolchain, no separate report, no manual merging of numbers.
Coco is independently certified by SGS TÜV Saar for safety-related software up to ASIL D under ISO 26262. When your agent raises coverage, it raises it in a tool your auditors already recognize.
Map Coco to your standard →
Coco wraps the compiler. Nothing else in your build changes.
New to Coco? Coco is a code coverage tool that supports C, C++, C#, QML, Python and Tcl. It instruments your build and records exactly what your tests executed. No changes to your source, test suite or CI pipeline required.
Coco Produced Certified Coverage Data your Auditors Already Accept
Automotive
ISO 26262 · ASIL A–D
ISO 26262 defines coverage requirements by ASIL level: statement and branch coverage for ASIL A and B, MC/DC for C and D. These must be collected from the target hardware, not from desktop simulation, because the execution environment affects which branches are reachable.
Coco instruments the production binary, collects decision and MC/DC data directly on the ECU or SIL bench, and produces the evidence your safety case needs. A Qualification Kit supports DO-330-aligned tool qualification so your team is not building that case from scratch.
Railway
EN 50128 · EN 50716 · SIL 3–4
EN 50128 requires structural coverage at SIL 3 and 4, typically branch and condition coverage as a minimum, with MC/DC for the most critical components. Railway software runs on RTOS-based embedded targets, often without network access, display output or a graceful shutdown path.
Coco collects coverage directly from those targets using a dump-on-event strategy, then merges results from embedded and desktop test runs into one .csmes database. The application and test infrastructure remain unchanged. EN 50716, the updated successor to EN 50128, is also supported.
Industrial Automation
IEC 61508 · SIL 1–4
IEC 61508 mandates coverage-based verification for software elements at SIL 2 and above. Industrial safety systems are rarely a single language or a single test type: PLC logic in C, HMI in C++ or QML, safety layers in C#, tested by unit suites on desktop, functional tests on the controller, and manual validation on the target device.
Coco accumulates coverage from every test type into one .csmes database, giving the functional safety manager a single, auditable coverage figure that reflects the full test campaign, not just what ran in CI. Qualification Kit available.
Medical
IEC 62304 · Class C
IEC 62304 Class C software requires a documented verification strategy that includes structural coverage. Notified bodies expect to see which code was executed by which test, not just a coverage percentage.
Coco produces per-test, per-instrumentation-point reports directly from the .csmes database, the same database the AI agent queries when closing gaps. Mixed C, C++, C# and QML products are covered in one instrumented build. Qualification Kit included to support tool qualification under IEC 62304 and ISO 14971.
Aerospace & Defence
DO-178C · DAL A · DO-330
DO-178C Table A-7 requires structural coverage analysis at source code and object code level. At DAL A, MC/DC is mandatory. Coverage must come from dynamic testing of the actual executable on the target processor or an approved equivalent, not from static analysis tools.
Coco instruments the binary and collects MC/DC directly from the execution environment. Programmes using subcontracted test houses can share instrumented binaries and merge results centrally via cmmerge. Source code never leaves the programme office. Tool qualification evidence aligned to DO-330 is available.
Know What Your Tests Are Missing by End of Day
The MCP Server works with any Coco 7.5.0+ installation and any stdio MCP client: Claude Code, GitHub Copilot in VS Code, or your own agent. Evaluation is free.
Introducing the Coco MCP Server Preview
In the first part of this blog post series, Part 1, we implemented the mentioned workflow for the task of generating unit tests with the help of Coco CLI tools to maximize code coverage. Today we are releasing Coco MCP Server Preview which can be leveraged in generative AI powered workflows by developers, testers, managers and CI/CD.
Webinar
Explore Code Coverage with AI: Find Risky Code in Minutes
This 40-minute session with Marius Schmidt from Qt Group shows how to replace that with a ranked list of your highest-risk functions, generated automatically from your own codebase and updated on every build, so release and planning conversations are based on evidence rather than instinct.
Tutorial
How to Use AI Code Assistants to Generate Unit Tests and Maximize Coverage
See how you can use GitHub Copilot + Coco Code Coverage to raise test coverage from 65% to 78%, and how this approach can be adapted for other frameworks and industries, including safety-critical domains.
Blog
How to Stop Writing Tests for the Wrong Functions and Start Testing with Ranked Lists by Risk
A high code coverage percentage doesn't tell you whether you're testing the right code. Teams naturally gravitate toward testing easy, simple functions that boost the metric, while complex, high-risk logic stays untested.
Coco Evaluation Guide
Evaluation Guide is here to support you throughout the process of an evaluation, from downloading the tool to the point of installing and starting the use.
Learn more