Skip to main content
Glama

search_tests

Read-onlyIdempotent

Search automated tests by title, file, or tag, and retrieve their recent execution status, pass rate, and flakiness over a configurable window to identify problem tests.

Instructions

Search AUTOMATED tests by title, file path or tag, and get how each has been doing. Each row carries titlePath (an array; get_test_history wants ONE segment of it), filePath, lastStatus, reliability, totalExecutions, passedCount, failedCount, passRate, avgDurationMs and lastSeen. IMPORTANT: days defaults to 7 here, the shortest window of any tool - a test that has not run in the last week is simply absent, which reads as does not exist rather than has not run lately. Pass days explicitly whenever the question is not about this week. The counts are of ATTEMPTS, so a retried test contributes more than one, and passRate is passedCount divided by totalExecutions on that basis; reliability is derived from the same rows, reading flaky when both a pass and a failure appear in the window. It returns NO linkage information at all, so it cannot answer whether a test is tied to a manual case: use get_test_case with includeRecentExecutions for that. Use get_test_history for one test in full detail over a longer window - it takes the segment as titlePath, where this tool takes query - and get_launch_tests for every test in one launch.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
daysNoLookback period for recent executions
limitNoMaximum number of tests to return
queryYesSearch query (case-insensitive substring of the title-path array or the file path). Pass ONE title segment, e.g. "should validate credentials"; a " > "-joined path matches nothing.
statusNoFilter by what happened in the WINDOW, not by how the test stands now, and the two ends are not symmetrical: failed selects tests with AT LEAST ONE failed attempt, while passed selects only tests where EVERY attempt passed. So a test that failed once a month ago and has been green since is returned by failed and withheld by passed. It cannot answer what is failing now. lastStatus on each row comes closest: it is the FINAL attempt of the most recent launch in the window, so a test that failed and then passed on retry reads passed. But the window is still the window - a test that has not run since it was fixed carries whatever it last did - so for the present state take the newest launch from get_launches_statistics and read it with get_launch_tests. flaky selects tests with both a pass and a failure in the window.all
projectIdYesProject UUID

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.5.3
    • changedInput schema / properties / status / description
      Previous value: -"Filter by recent execution status"New value: +"Filter by what happened in the WINDOW, not by how the test stands now, and the two ends are not symmetrical: failed selects tests with AT LEAST ONE failed attempt, while passed selects only tests where EVERY attempt passed. So a test that failed once a month ago and has been green since is returned by failed and withheld by passed. It cannot answer what is failing now. lastStatus on each row comes closest: it is the FINAL attempt of the most recent launch in the window, so a test that failed and then passed on retry reads passed. But the window is still the window - a test that has not run since it was fixed carries whatever it last did - so for the present state take the newest launch from get_launches_statistics and read it with get_launch_tests. flaky selects tests with both a pass and a failure in the window."
  2. First observedv1.5.0

TDQS

A4.9/5.0
Behavior5/5

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

Despite strong annotations (readOnly, idempotent, non-destructive), the description adds substantial behavioral context: it reveals that counts are attempts (retries inflate counts), explains passRate and reliability computation, highlights the asymmetry between failed/passed filters, and clarifies what lastStatus means. This goes far beyond annotations.

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 description is dense and front-loaded with the core purpose, then covers edge cases and alternatives. Every sentence serves a purpose; there is no fluff. It is long because the tool's behavior is complex. A slight structural improvement could be grouping related concepts, but the existing organization is functional and efficient.

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?

Given there is no output schema and 5 parameters plus complex semantics, the description fully compensates: enumerates every row field (titlePath, lastStatus, reliability, etc.), explains absence semantics, distinguishes attempts from test cases, and explicitly states what the tool cannot answer (linkage, current failing status) while providing the correct tools to route those cases. Nothing needed for correct use is missing.

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?

Although the schema already covers all params at 100%, the description adds deep semantics: days is the shortest window and must be extended unless the question is about the current week; query should be a single titlePath segment rather than a joined path; status filtering is window-based and asymmetric, with failed selected by at least one failure while passed requires all attempts passed. This is meaningful value over the schema.

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 states a precise action ('Search AUTOMATED tests'), the search dimensions (title, file path, tag), and what results include (pass rate, reliability, etc.). It explicitly names sibling tools it is not (get_test_case, get_test_history, get_launch_tests), so an agent can disambiguate immediately.

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 gives explicit when-to-use and when-not-to-use guidance: it notes the default 7-day window, warns that absence means 'not run' rather than 'nonexistent', and routes to get_test_case for linkage, get_test_history for one test in detail, and get_launch_tests for a full launch. This leaves no ambiguity.

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