Swipium

Overview Schema Source Related Servers Discussions Admin

Record a test outcome

qa_note

Record QA workflow outcomes for reports, capture checkpoint screenshots, link steps, and classify failures or blocked cases with reasons and evidence.

Instructions

Record the outcome of one workflow for the report. Use outcome:"blocked" + missingPrecondition rather than a false failure; category says why. A pass/fail note captures a checkpoint screenshot and links the steps since the last note; extra evidence goes in artifactUris (this session's URIs only, others are dropped).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "sessionId": "<sessionId>",
      "workflow": "<workflow>",
      "outcome": "<outcome>"
    },
    "name": "qa_note"
  }
}

Input Schema

Name	Required	Description
`reason`	No
`outcome`	Yes
`category`	No	Default for outcome:"fail" is app_bug; use mcp_limitation for tool problems.
`workflow`	Yes	e.g. "Delete saved flight"
`sessionId`	Yes
`artifactUris`	No
`requiredState`	No
`recommendedSetup`	No
`verifiedVisually`	No	The pass was confirmed from an attached screenshot.
`missingPrecondition`	No	e.g. "no saved flight exists"

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 11, 2026

TDQS

A3.6/5.0

Behavior4/5

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

Annotations only declare not-read-only, not-destructive, closed-world, non-idempotent. The description goes beyond them by disclosing real side effects: a pass/fail note captures a checkpoint screenshot and links the steps since the last note, and artifactUris outside the current session are silently dropped. It doesn't mention auth, limits, or what a write failure looks like, so not a 5.

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

Conciseness4/5

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

Two dense sentences with the core action front-loaded and the important caveats (blocked-vs-fail, screenshot capture, URI dropping) each attached to the parameter they qualify. The semicolon-chained clauses are slightly packed but no sentence is filler.

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

Completeness3/5

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

For a 10-parameter mutation tool with no output schema and only 40% schema coverage, the description covers the highest-risk semantics (blocked handling, session-scoped URIs, implicit screenshot). It still leaves four parameters unexplained and says nothing about what the tool returns or how failures surface, so an agent would need to experiment.

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

Parameters3/5

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

Schema coverage is 40% across 10 parameters, and the description meaningfully fills some gaps – the outcome/missingPrecondition pairing and the session-scoped restriction on artifactUris, which the schema doesn't state. reason, sessionId, requiredState, and recommendedSetup get no explanation anywhere, leaving a substantial documented-vs-undocumented imbalance.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource – 'Record the outcome of one workflow for the report' – which tells an agent this is the per-workflow result-writing tool rather than an issue logger or test runner. It doesn't explicitly differentiate from siblings like qa_issue_log or qa_test_feature, so it falls short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a concrete decision rule for one ambiguous case: use outcome:"blocked" with missingPrecondition instead of a false failure, and category explains why. That is enum-selection guidance, not tool-selection guidance; nothing says when to call qa_note versus qa_issue_log or qa_flow_check.

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