mcp-testops

Overview Schema Source Related Servers Discussions Admin

get_test_case_history

Retrieve the launch history for a test case, including each run's status, timing, and result details. Filter by launch or search result text to see where and how the case was executed.

Instructions

Which launches ran a test case, and with what result.

Answers "where was this case run": each row is {testResultId, launchId, launchName, status, start, stop, duration, message, testedBy}. launch_id narrows to one launch, search narrows by result text. project_id defaults to TESTOPS_PROJECT_ID. For the full result of one row use get_test_result(testResultId).

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": {
      "test_case_id": "<test_case_id>"
    },
    "name": "get_test_case_history"
  }
}

Input Schema

Name	Required	Description	Default
`page`	No
`size`	No
`sort`	No
`search`	No
`launch_id`	No
`project_id`	No
`test_case_id`	Yes

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.5Nov 9, 2026

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations, the description carries the full burden, and it does disclose the per-row field list and the project_id default. However, it never states that this is a read-only operation, nor does it mention pagination behavior or result-volume expectations for a history query that could return many rows.

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?

The purpose is front-loaded in one sentence, followed by output shape and parameter notes in a compact block. The inline field-list brace notation is dense but efficient; no filler sentences are present.

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 seven-parameter tool with zero schema descriptions and no annotations, the description covers the differentiating parameters well and an output schema exists so return values need not be explained. The unaddressed pagination and sort parameters, plus the absence of any safety/read-only signal, leave real gaps.

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 description coverage is 0%, so the description must compensate. It explains launch_id, search, project_id (including its TESTOPS_PROJECT_ID fallback), and implicitly test_case_id, but says nothing about page, size, or sort, leaving three of seven parameters with no semantic guidance anywhere.

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 opening line states a specific verb-plus-resource ('which launches ran a test case, and with what result') and the following sentence clarifies the result shape ('where was this case run'). It also explicitly distinguishes itself from the sibling get_test_result by pointing there for full single-row detail.

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

Usage Guidelines4/5

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

It gives concrete narrowing conditions ('launch_id narrows to one launch, search narrows by result text') and routes the agent to get_test_result(testResultId) when the full result of one row is needed. It lacks explicit when-not-to-use guidance, but the alternative routing is clear.

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