Skip to main content
Glama
m00nreport

M00N Report MCP

Official
by m00nreport
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

report_case_result

Idempotent

Record per-step pass/fail and case status for a manual test execution, updating group status and execution progress automatically.

Instructions

Record the result of running one case inside a Manual Test Execution: set per-step pass/fail and/or the case status, atomically and idempotently. Target the case by executionCaseId (from get_execution_cases) OR by executionId + caseId (numeric; if the case is in several groups, pass groupId or use executionCaseId). A Test Collection is NOT an Execution, and the trap has a name: the per-case rows get_test_collection returns carry a field called executionId, which is the id of the row inside that Collection and is rejected here with Execution case not found. To record results against a Collection, add it to an Execution with add_collections_to_execution and use the rows get_execution_cases gives you. status: an explicit value (passed/failed/blocked/in_testing/not_executed), or "auto" to derive it from the steps (failed then blocked then in_testing then passed), or omit it to leave the case status unchanged (e.g. when only writing one step). steps[].status is one of not_executed/passed/failed/blocked/skipped; index is the 0-based position in the case steps. The containing source group's status auto-rolls from its cases' results, where EXECUTED means anything other than not_executed - so a case parked in_testing counts as executed, and the same is true of the completionRate get_execution reports. A group whose every case is in_testing therefore reads completed, and the execution reads 100 percent complete, while the work is still going on. The rule: all not_executed -> not_started, some executed -> in_progress, all executed -> blocked if the group contains a blocked case, else completed (test_run_status has no failed; failures show via the group's counters). An explicit set_execution_source_status override lasts until the next report on that group recomputes it. The status of the EXECUTION itself does not roll at all: it stays wherever it was until you move it with update_execution, so an execution whose cases have all been run can still read not_executed. Returns the case status, the group status, the steps written, and fresh execution progress.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
notesNoOptional free-text notes for the case run
stepsNoPer-step results to upsert.
caseIdNoAlternative to executionCaseId: the numeric case id (with executionId).
statusNoCase status from the project vocabulary, typically not_executed, in_testing, passed, failed or blocked, plus any the project added; call get_project for the list it uses. Pass "auto" to derive it from the step results, or omit to leave the status unchanged. The per-step status inside steps[] is a different and fixed vocabulary.
groupIdNoOptional: disambiguate when the case is in several source groups.
causedByNoOptional: which step or thing caused failure
executionIdNoAlternative to executionCaseId: the execution UUID (with caseId).
durationMinutesNoOptional: time spent, in minutes
executionCaseIdNoThe case-run row UUID (from get_execution_cases). Preferred.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.5.3
    • changedInput schema / properties / status / description
      Previous value: -"Case status: passed/failed/blocked/in_testing/not_executed, or \"auto\" to derive from steps, or omit to leave unchanged."New value: +"Case status from the project vocabulary, typically not_executed, in_testing, passed, failed or blocked, plus any the project added; call get_project for the list it uses. Pass \"auto\" to derive it from the step results, or omit to leave the status unchanged. The per-step status inside steps[] is a different and fixed vocabulary."
  2. First observedv1.5.0

TDQS

A5/5.0
Behavior5/5

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

Beyond the idempotentHint and non-destructive annotations, the description discloses atomicity, the auto-derivation rules, how group status rolls up, that execution status does not roll, and that set_execution_source_status overrides last only until the next report recomputes. This gives the agent substantial behavioral transparency beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but every section earns its place: targeting, the Collection trap, status semantics, roll-up rules, overrides, and return value each address a failure mode an agent would hit. It is front-loaded with the main action and then builds outward into edge cases.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter tool with no output schema, the description covers targeting, required/preferred parameters, status vocabularies, idempotency, atomicity, roll-up behavior, side effects, and even what is returned. It is complete enough for an agent to select and invoke the tool correctly without further research.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds critical semantic meaning beyond it: executionCaseId is preferred, executionId+caseId is the alternative, executionId from get_test_collection is rejected, and status 'auto' has a precise derivation order. It also clarifies the step-status vocabulary is separate from the case-status vocabulary.

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 names a specific action and resource: 'Record the result of running one case inside a Manual Test Execution' and clarifies the exact scope by setting per-step pass/fail and/or case status. It also explicitly warns that 'A Test Collection is NOT an Execution', which separates it from collection-related siblings.

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?

The description explicitly tells the agent how to target the case, including the preferred executionCaseId and the alternative executionId + caseId, and when to use groupId. It also gives a concrete migration path for Collections, 'add it to an Execution with add_collections_to_execution', and points to update_execution for moving execution-level status.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools