AI agents that write tests. A test management system that governs them.

The governance gap nobody is pricing in

Someone on your team already has an AI writing tests. It writes them into a branch, a chat window, or a scratch file that never gets reviewed. Nobody knows how many exist, which feature they cover, who approved them, or whether last night’s pipeline touched a single one. Output volume went up. Visibility went down.

That is not an AI problem, it is a system-of-record problem. A test that lives outside the test management system is not managed, no matter how good the model that wrote it.

50 tools, 26 that change state

Counts, not adjectives. The M00N Report MCP server exposes exactly 50 tools, each with a live handler, verified by countingapi/mcp/definitions.mjs directly rather than reading our own marketing.

An agent with write access can:

• Author real test cases: Markdown converted into the editor’s own Slate document model, with an auto-created folder and suite hierarchy, tags, and a Jira link attached atomically at creation.
• Plan an entire manual cycle: open an execution and populate it from a whole Test Collection, an entire suite, or hand-picked cases (worked example below).
• Bind automation to the case it covers: link_autotest_to_case connects an automated test to a manual case by title, including before that test has ever run once.
• Manage releases: create and update releases, and link or unlink the launches that belong to them.
• Keep the repository tidy: move and bulk-update cases, and archive what is no longer needed.

Worked example: an agent planning a manual test cycle

Ask for it in a sentence: “Build a regression cycle for the 2.4 release covering checkout and payments, assign it to QA, environment staging.” The agent runs four write tools in sequence, all delegating to the same service layer the UI calls:

1. create_execution opens a named manual execution with an environment and a date window.
2. add_collections_to_execution pulls in a whole reusable Test Collection.
3. add_suites_to_execution adds an entire suite on top of it.
4. add_cases_to_execution hand-picks any individual cases the collection and suite missed.

What comes back is a real execution with assignees, an environment, dates and snapshotted case content, exactly like one a QA lead assembled by hand, ready for a person to start clicking through.

Agentic AI readiness: an agent that reads your whole quality state

Everything above is AI that writes tests. This is the other half, and the founder considers it the core direction of the product: an agent that reads everything M00N Report knows about quality, across every project it can see, and decides what needs attention next.

Over MCP, an agent can work through a project portfolio like this:

1. list_projects enumerates every project the agent’s key can see.
2. run_health_check returns, per project, a composite 0-100 score weighted across automation stability, coverage and manual execution, with sub-scores and prioritized recommendations.
3. get_launches_trends and get_launches_statistics show which projects are trending up or down.
4. get_coverage_gaps runs the bidirectional check: cases with no automation, and automated tests that no case owns.
5. export_report pulls a formatted summary, trend or release report for whichever project needs a closer look.

That is a portfolio view, built by the agent itself, one project at a time: which of your projects is lagging, and where failures are clustering. Then it acts through the write tools described above: file the missing test case, open an execution, cut the release.

Prompts and resources that arrive carrying data

6 data-enriched prompts and 8 resources ship alongside the tools, and the prompts are not string templates. analyze_flaky_tests executes a windowed SQL query across recent result history, ranks tests by how often they flipped between pass and fail, and embeds the top ten in the prompt before handing the agent its task list. The conversation starts with the evidence already in the model’s hands.

• 6 prompts: analyze_flaky_tests, debug_test_failure, release_readiness, generate_test_cases, weekly_health_report and investigate_regression.
• 8 resources: project lists, a project health summary, a flaky-tests report, currently-failing tests, folder structure, a launch report, test case content and a release summary.
• Server instructions: around 130 lines shipped to the model on connect, teaching the entity hierarchy and the trap of confusing a case’s internal id with the TC-number a human reads off the screen.

Connecting it

Two transports, two auth modes, one identical tool surface: 50 tools, 6 prompts, 8 resources either way.

The controls that make this governance, not novelty

Everything an agent does lands inside the permission model your team already operates under.

• Role-based access control: 4 roles, including a non-billable Guest, and an MCP key that carries the permissions of the account it belongs to. An agent cannot do what its owner cannot do.
• Tenant isolation: enforced in PostgreSQL through row-level security, not application-layer filtering. There is no query path that reaches another organization’s data.
• MCP audit log: every tool call an agent makes is recorded and reviewable in the app, which turns “we let an AI write tests” into something you can show an auditor.
• Per-key rate limiting: a looping agent throttles itself rather than your platform.
• Destructive-operation flags: 7 tools carry the flag so a client can demand confirmation, and the delete tools behind them archive rather than permanently remove data.
• Single sign-on: OIDC and SAML with group-to-project JIT mapping, so the accounts your agents run as are provisioned by the same policy as everyone else.

The agent always has fresh data to read

An agent is only as useful as the data underneath it. Results reach the platform from any language: five official reporters (Playwright, Jest, pytest, NUnit, JUnit 5) plus a documented OpenAPI 3.0.3 ingest contract at /api/ingest/v2/openapi.json for everything else, so the read tools above are never querying a stale or partial picture. The full reporter and any-language story is on the test management page.

A server is common now. A governed write surface is not.

We audited eight test management and test reporting products for an official MCP server, verified 2026-07-21. Six ship one: Zephyr, ReportPortal, Allure TestOps and Qase, plus qTest and PractiTest which gate theirs to specific plans. Only TestRail and Xray have none, and Xray’s request, XRAY-11040, is still open.

So the server itself is no longer the differentiator. What matters is what it is allowed to do. A read-only server turns an assistant into a nicer query console: it can tell you the pass rate and hand the work back to you.

M00N Report’s server is 26 state-changing tools out of 50, each running through the same RBAC, the same audit log and the same coverage tracking as a human session. An agent does not just read your test suite, it maintains it, and every change it makes is governed in the platform rather than in a wrapper.