mcp-testops

Overview Schema Source Related Servers Discussions Admin

list_test_plans

Retrieve test plans for a project, including IDs, names, base RQL, and test case counts. Filter by project or plan name and paginate results.

Instructions

List test plans of a project: id, name, projectId, baseRql, testCasesCount.

project_id defaults to TESTOPS_PROJECT_ID; search narrows by name.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_test_plans"
  }
}

Input Schema

Name	Required	Description	Default
`page`	No
`size`	No
`search`	No
`tree_id`	No
`project_id`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.5Nov 9, 2026

TDQS

B3.2/5.0

Behavior3/5

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

No annotations exist, so the description carries the full burden. It usefully discloses the implicit project_id fallback to an environment variable, which an agent could not infer from the schema, but it says nothing about pagination behavior despite page/size parameters, nor about ordering or result limits.

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 short lines with the resource and return fields first, then the parameter caveats. No filler, though the field enumeration duplicates the output schema and the line break is slightly awkward.

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?

An output schema exists, so listing return fields is redundant rather than harmful. The real gaps are the undocumented page/size/tree_id parameters and no mention of how paging works, which an agent needs to call this list tool correctly.

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

Parameters2/5

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

Schema description coverage is 0% across 5 parameters, so the description must compensate. It only clarifies search (name matching) and project_id (default resolution); page, size, and especially tree_id are left entirely unexplained, including whether tree_id filters plans by folder.

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 ("List test plans of a project") and enumerates the returned fields, which clearly distinguishes it from get_test_plan or create_test_plan by name alone. It does not explicitly name a sibling to contrast with, but the purpose is unambiguous.

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?

The description gives two useful usage facts: project_id falls back to TESTOPS_PROJECT_ID, and search narrows by name. It offers no guidance on when to prefer this over get_test_plan or list_test_cases, and no exclusions or prerequisites beyond the default behavior.

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