Available MCP Tools
The M00N MCP server provides 60 tools: 26 read-only queries and 34 that change state - authoring test cases, assembling manual executions, running them and reporting per-step results, linking automation and managing releases. Each tool respects your user permissions-you can only access projects you're assigned to.
How the Tools Fit Together
The tools mirror the product itself. Analytics tools (launch statistics, trends, test history, health checks) answer questions about quality: pass rates over time, flaky tests, coverage gaps and release readiness. Management tools (test cases, folders, collections, executions, releases) let an AI assistant create and organize the same entities you would manage in the UI, from drafting a test case in Markdown to assembling a manual execution for release sign-off.
In practice you rarely call tools by name. You ask your assistant a question like "which tests became flaky this week" or give it a task like "create test cases for the signup flow", and it chains the right tools: resolving project IDs first with list_projects, then querying or creating what you asked for. The examples below show each tool's inputs and typical responses so you can verify what the assistant did.
All tools work identically on M00N Cloud and self-hosted instances, and every call is scoped by your MCP key: an assistant can never see projects its key does not have access to.
Projects & Runs
Core tools for listing projects and analyzing test run data.
list_projects
List the projects this key can reach. START HERE: almost every other tool needs a project UUID and this is where you get one. Admins see every project in the organisation, managers and users only the ones they are assigned to, so an empty list means no access rather than no projects. Ordered by the display order set in the UI first, then oldest created first, so do not read anything into the first entry beyond that. Returns each project with its id, name and metadata. Use get_project for one project in detail, including the status and priority vocabularies it actually uses, which you need before setting any status.
- "List my M00N Report projects"
- "What projects do I have access to?"
get_project
Get a project's configuration: its meta, the system-field vocabularies it actually uses (statuses/priorities/environments), and its case custom-field definitions. Call this to discover the VALID status and priority values before setting any of them: case_status and case_priority (test cases), execution_status (a Manual Test Execution overall), test_case_execution_status (a case inside one), test_run_status (a source group inside an Execution - NOT a Test Collection, whose status is a closed set of not_started, in_progress, completed, blocked enforced by the database and unaffected by anything a project configures here), release_status (releases) and test_environment. Every one of them is project-customizable, so never hardcode a value or assume the stock list. Each entry is { value, label, isDefault }: send the VALUE to other tools, never the label, and isDefault marks what a create tool will use when you omit the field. Returns { project, systemFields{ case_status, case_priority, execution_status, test_case_execution_status, test_run_status, release_status, test_environment }, customFields[] }.
| Parameter | Type | Required | Description |
|---|---|---|---|
projectId | UUID | Yes | Project UUID (from list_projects) |
- "What statuses does this project use for executions and test cases?"
- "Show me the custom fields configured for test cases in this project"
get_launches_trends
Aggregate a project over a window: pass rate over time, the tests that fail most, the flaky ones, duration trends and the slowest tests. The slowest section is ranked by AVERAGE duration, which is not the same question as what costs the most CI time: a 75-second test that ran once outranks one costing four minutes across eighteen runs. Each row also carries totalDurationMs, the sum over the window - sort by that when the question is pipeline cost. IMPORTANT: there is no single pass rate in this response. trends.passRate is a SERIES, one row per day, each carrying total_runs, passed_runs and pass_rate; to answer a question about the whole window you have to sum the daily totals yourself rather than average the daily rates, which would weight a quiet day the same as a busy one. And it is a rate over LAUNCHES that ended green, not over tests that passed, and the two differ widely; for the test-level figure use summary.testPassRate from get_launches_statistics. In the failing section, total_runs counts ATTEMPT ROWS rather than launches, so failure_rate is failed attempts over attempts and a test retried three times in one launch contributes three. That section ranks over the WHOLE window and says nothing about the present: a test that failed heavily early on and was fixed still tops the list, and no field in the row - there is no lastStatus and no lastSeen - reveals that it is green today. It answers what has failed most, never what is failing now; for that, read the newest launch with get_launch_tests. Flakiness is ranked by flip_count, the number of times a test changed result between consecutive ATTEMPTS, retries included, alongside instability_score which weighs how evenly it splits between pass and fail. Attempts, not launches: a test that fails twice and passes on the third try in every run scores high here while never once turning a launch red, and flip_count can exceed the number of launches in the window. Only passed and failed attempts are counted, so skipped and flaky rows are absent from both figures. For per-launch flipping, read get_test_history and group by runId. days defaults to 30, so a quiet project returns empty series, and the flaky, slowest and tests-by-tag sections are additionally capped at 90 days however much you pass, while the trend series itself honours the full range: so a 365-day call answers two different windows in one payload. Counts and rates in this response come back as STRINGS, total_runs as "45" and failure_rate as "80.00", so coerce them before comparing or summing. Use include[] to compute only the sections you need and topN to size the lists. Reach for get_launches_statistics to page through individual launches, and get_launch_tests when you have one launch.
| Parameter | Type | Required | Description |
|---|---|---|---|
projectId | UUID | Yes | Project to analyze |
days | integer | No | Lookback period (1-365, default: 30) |
tags | string[] | No | Filter runs by tags |
topN | integer | No | Limit for top-N lists (default: 10) |
include | string[] | No | passRate, duration, failing, flaky, slowest, testsByTags |
- "Show me the test pass rate trends for E2E Tests over the last 30 days"
- "What are the top 10 flaky tests?"
- "Which tests are failing most often?"
get_launches_statistics
List the launches of a project, newest first, each with its own pass, fail, skip and duration figures. Every launch row carries id, launch, status, startedAt, endedAt, durationSeconds, tags and stats - the NAME of the launch is in a field called launch, not title or name. The status is REPORTED by the CI job rather than derived from the numbers beside it, and it runs BOTH ways. A launch can be stored failed with stats.failed 0, because the job failed for a reason no test recorded. And a launch that reported nothing at all can be stored passed with stats.total 0 - one here sits 75 minutes after a real run that failed 145 tests, so reading the newest launch as green clears nothing and the earlier failures still stand. Check stats.total before treating a green newest launch as evidence. Never infer one from the other; to answer what failed, read the tests with get_launch_tests. Every launch row also carries a stats object of total, passed, failed, skipped, flaky, retries and running. total EXCLUDES skipped even though skipped is printed beside it, so the identity that holds is passed + failed + flaky = total; retries counts retry ATTEMPTS, not tests that were retried, which is why it can exceed flaky. Returns launches, a summary over the whole window (totalRuns, passedRuns, failedRuns, runningRuns, runPassRate, totalTests, totalPassed, totalFailed, totalSkipped, totalFlaky, testPassRate, avgDurationSeconds), the period and filters applied, and pagination with the real total; there is no top-level total. Read the two rates carefully, because they answer different questions and neither denominator is obvious. runPassRate is the share of LAUNCHES that ended green, out of totalRuns - and totalRuns is EVERY launch in the window. Only three of the end statuses have a bucket - passedRuns, failedRuns and runningRuns - so a launch stored as finished, interrupted, timedOut or completed is counted in totalRuns and in none of them, and the three need not add up to totalRuns. That shortfall is why get_launches_trends and run_health_check answer a slightly higher run pass rate over the same window: they count only launches that passed or failed, so their denominator is smaller. testPassRate is the share of TESTS, computed as (totalPassed + totalFlaky) / totalTests: flaky counts as a pass, because a flaky test passed on a retry and the launch is green on it, and totalTests already EXCLUDES skipped, so totalPassed + totalFailed + totalFlaky is the whole of it while totalSkipped sits outside. Both rates are null, not 0, when the window held nothing at all - testPassRate with no tests, runPassRate with no launches - since nought percent would read as a verdict on work that never ran. IMPORTANT: days defaults to 30, so a project idle for longer returns an empty list, which means nothing in the window rather than nothing at all. Use limit, offset and search to page, statuses or tags to narrow. Reach for get_launches_trends when the question is about the project over time rather than about particular launches, and get_launch_tests when you have one launch and want the tests in it.
| Parameter | Type | Required | Description |
|---|---|---|---|
projectId | UUID | Yes | Project to query |
days | integer | No | Lookback period (default: 30) |
statuses | string[] | No | passed, failed, running, interrupted |
tags | string[] | No | Filter by tags |
search | string | No | Search in launch title/ID/tags |
limit | integer | No | Results per page (default: 20) |
offset | integer | No | Pagination offset |
Audit Trail
Every MCP tool invocation is logged for security and compliance. Admins can view the audit log in Settings → MCP Keys → Activity Log.
Each log entry includes:
- Tool name and parameters
- User and MCP key used
- Target project (if applicable)
- Result status (success, error, or denied)
- Execution duration
- Timestamp