50+ tools over MCP, under the same permissions and audit log as any human on your team.
The specs, tickets and designs already exist. The cases covering them usually do not.
Take Jira bug PROJ-1234, write a regression case from its repro steps, and add it to the Checkout collection
create_test_caseadd_cases_to_collectionA numbered, foldered case in the Checkout collection, ready for the next cycle
Read the Checkout v2 frames in Figma and draft a case for every state: empty cart, expired card, 3-D Secure challenge
create_foldercreate_test_caseA Checkout v2 suite with one case per state, before a line of code ships
Open the Q3 billing PRD in Notion, work out which acceptance criteria have no case yet, and write only the missing ones
search_testscreate_test_caseOnly the gaps get written - nothing your team already covered is duplicated
PR #482 touches the payment module. Which cases cover it, and how reliable have those tests been lately?
search_testsget_test_historyA risk note in the review, before the merge rather than after the incident
Find the manual cases in Payments with no automation behind them and open a Linear ticket for each, sized by the case priority
get_coverage_gapsget_folderThe automation backlog stops being a spreadsheet somebody has to maintain
Build a regression cycle for the 2.4 release covering checkout and payments, assign it to QA, environment staging
create_executionadd_collections_to_executionadd_suites_to_executionadd_cases_to_executionA real execution with assignees, dates and snapshotted steps, exactly like one a QA lead assembled by hand
The evidence is spread across four tools. One prompt is cheaper than four tabs.
Take Sentry issue CHECKOUT-4F1, write a regression case from the stack trace, and link the Playwright test that covers it
create_test_caselink_autotest_to_caseThe bug that reached production now has a case that owns it and automation bound to it
Check last night's CI run for new failures and open Jira bugs carrying the error and stack trace, labelled auto-created
get_launches_statisticsget_launch_testsTriaged before standup, with the evidence already attached
Checkout latency spiked at 14:02. Which checkout tests ran since, what did they do, and post the summary to #incidents
search_testsget_test_historyOne message that says whether the suite caught it, missed it, or never covered it
I just got paged for the payments service. Give me its test health and everything that failed in the last 24 hours
run_health_checkget_launches_statisticsA composite health score and the recent failures, in the window where it matters
Rank this week's flakiest tests with their retry counts and post the top ten to #qa with what changed since last week
search_testsget_test_historyThe ranking lands in the channel every week without anyone opening a dashboard
Which tests only passed on retry last night? Tag the cases behind them and re-trigger the GitLab pipeline for those suites
get_launch_testsbulk_update_casesThe unstable ones are tagged and re-run without anyone opening the CI UI
The work is done. Someone still has to assemble the evidence for the people who sign.
Summarise the 3.2.0 release - pass rate, known issues, coverage - and publish it as a Confluence page under Releases
get_releaseexport_reportA release page nobody had to assemble the night before the release
Every Monday: pass rate, flaky count and automation coverage for every project, appended to the QA Metrics 2026 sheet
list_projectsrun_health_checkA trend line that exists because it accrued, not because someone remembered
Push this week's pass-rate trend and failure count into our Grafana quality board, annotated with the release dates
get_launches_trendsget_launches_statisticsQuality on the same wall as the rest of production, not in a tab only QA opens
For every high-severity Snyk finding fixed this sprint, open a verification execution and record the result case by case
create_executionadd_cases_to_executionreport_case_resultEvidence that each fix was verified, not just merged
Attach the 3.2.0 test evidence to change request CHG0043210: pass rate, failed cases and the sign-off state
get_releaseexport_reportThe CAB question answered in the ticket before it gets asked in the meeting
Every night at 02:00: pull the nightly regression run, analyse the new failures, fix the broken specs, and open a PR
get_launches_statisticsget_launch_testsA scheduled routine over the remote connector - the diff is waiting when you get in
These are not blank templates. Each one gathers the evidence first and hands it to the model, so the conversation starts where a person would have finished digging.
analyze_flaky_testsFlakinessAnalyse flaky tests in Payments over the last 14 days and tell me which to quarantine before the release
The top ten flip-floppers arrive already ranked, before the model says a word
get_test_historydebug_test_failureDebuggingDebug why checkout.spec.ts > payment flow failed in last night’s run
The error, the recent pass-fail pattern and the case it belongs to, all in the first message
get_launch_testsget_test_historyrelease_readinessReleaseRun release readiness for 3.2.0 and tell me what would block it
A go or no-go argument assembled from run data rather than from the room’s mood
get_releaseget_coverage_gapsgenerate_test_casesAuthoringGenerate test cases for the new refund flow in the Payments project
Drafts shaped by your own folders and templates, persisted as first-class cases
suggest_test_casescreate_test_caseweekly_health_reportReportingGive me this week’s health report for every project I can see
Scores, movement and what to fix first, with no spreadsheet in the loop
run_health_checkget_launches_trendsinvestigate_regressionRegressionInvestigate the regression in the checkout suite since Tuesday
The run where the trend turned, and the tests that turned with it
get_launches_trendsget_test_historyrun_manual_executionManual cycleWork through the 2.4 regression execution and record the result of every case as you go
Pass or fail per step, case and group statuses deriving themselves, execution closed at the end
get_execution_casesreport_case_resultupdate_executionEvery one of the 50+ tools with its arguments, return shape and annotations, plus the 7 prompts and 8 resources.
4 roles including a non-billable Guest. An MCP key carries the permissions of the account it belongs to, so an agent can never do what its owner cannot.
A key only ever reaches the workspace it belongs to. An agent cannot see another organisation’s projects, cases or results - there is no path to them.
Every tool call an agent makes is recorded and reviewable in the app. "We let an AI write tests" becomes something you can show an auditor.
A looping agent throttles itself rather than your platform.
9 tools carry the flag so a client can demand confirmation, and the delete tools behind them archive rather than permanently remove data.
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.
Paste one URL into Claude Desktop, Claude Code or claude.ai and approve it in the browser. Nothing to install, no key to keep safe.
{
"mcpServers": {
"m00n": {
"type": "http",
"url": "https://m00nreport.com/mcp"
}
}
}Cursor, ChatGPT, Zed, Windsurf, VS Code or an agent you wrote yourself. Drop in the config below with your own key and you get the same 50+ tools - self-hosted included.
{
"mcpServers": {
"m00n": {
"command": "npx",
"args": ["-y", "@m00nsolutions/mcp-server"],
"env": {
"M00N_API_URL": "https://m00nreport.com",
"M00N_API_KEY": "m00n_mcp_your_key_here"
}
}
}
}Any MCP-compatible client, over one of two paths. Claude Desktop, Claude Code and claude.ai use the hosted remote connector: a URL plus a browser consent screen, authenticated with OAuth 2.1 and no key file on disk. Every other client, including Cursor, ChatGPT, Zed, Windsurf and VS Code, uses the @m00nsolutions/mcp-server package from npm over stdio with an MCP key. The remote connector's redirect allowlist is hardcoded to claude.ai and claude.com, so it is a Claude connector specifically. Both paths expose the identical tools, prompts and resources.
Your own model generates; M00N Report does not resell you one. suggest_test_cases supplies project-aware scaffolding through pattern matching over your existing templates and folder structure, not an LLM call, and create_test_case persists whatever your assistant writes, turning Markdown into a first-class rich-text case with steps, tags and an optional Jira link.
An MCP key carries exactly the permissions of the account it belongs to, so an agent can never exceed its owner's role. Most tools read; the ones that change state are marked, and 9 are flagged destructive so a client can require explicit confirmation before running them. The five delete_ tools, for test cases, collections, releases, folders and executions, archive rather than permanently delete. Every tool call is written to an MCP audit log with a UI in the app, and per-key rate limiting caps a runaway agent.
They cover opposite directions. The ingest API is how automated results get in: an OpenAPI 3.0.3 specification published at /api/ingest/v2/openapi.json, used by the five official reporters. The MCP server is how test assets get managed: authoring cases, building and running manual executions with per-step results, linking automation to cases, tracking releases, and reading coverage and health. There is no public REST API for test case, execution or release management; that surface is the UI plus MCP only.
Yes, by iterating over the read tools. There is no built-in agent and no shipped portfolio dashboard: your own agent calls list_projects, then run_health_check, get_launches_trends and get_coverage_gaps for each project it can see, and assembles the rollup itself. run_health_check scores one project at a time, so a multi-project view is something the agent builds, not a screen we ship. Nothing in that analysis leaves your MCP connection for a separate AI service, and there are no AI credits to buy.
Yes. Install @m00nsolutions/mcp-server and point it at your own instance URL with an MCP key issued by that instance, which matters when the reason you self-host is that test data cannot leave your network. Self-hosted gets the identical tools, prompts and resources as the cloud.
Connect in about a minute on the free plan, then ask your assistant to draft a suite for a feature you shipped last week. Everything it writes lands in a repository your team can see, review, execute against and ship behind.