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 meaningful behavior: the inclusion criterion (last 2+ consecutive failures), what the returned timing fields mean (last_passed_date, first_failed_date), and the diagnostic intent. It omits pagination, ordering, and permission/version-resolution behavior, but the core behavioral profile is present.

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

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

Two tight sentences, zero filler. The core definition, the disambiguation, and the qualification rule are all front-loaded before the optional detail about returned timing fields.

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

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

Five optional parameters are fully covered by the schema and no output schema exists, so the description's job of explaining the return shape (timing fields with their diagnostic purpose) is mostly fulfilled. Missing only peripheral details like result ordering, which is minor for this read-only diagnostic tool.

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

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

Schema description coverage is 100%, so every parameter (days, limit, version, project_id, min_consecutive_failures) is already documented in the schema. The description reinforces the default threshold with 'last 2+ runs have failed' but adds no syntax, format, or edge-case meaning beyond the schema, which is the expected baseline.

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

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

States a specific verb and resource ('get tests that are failing consecutively') and immediately disambiguates the resource with the parenthetical '(broken tests, not flaky)', which cleanly separates it from the get_flaky_tests sibling. The scope rule (last 2+ runs failed) further pins down the resource.

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

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

The 'not flaky' contrast tells the agent when to prefer this over a flaky-test tool, and the mention of identifying 'which merge broke them' frames the diagnostic use case. It stops short of naming concrete alternatives or stating exclusions explicitly, so it is clear context rather than full routing guidance.

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

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

No annotations are provided, so the description carries the disclosure burden. It adds genuine interpretive value by explaining what a high correlation means, but it says nothing about return format, result limits, or ordering, and does not explicitly confirm the read-only nature of the call.

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

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

Two tight sentences; the core operation is front-loaded and the second sentence earns its place by explaining the diagnostic significance of the result.

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

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

For a five-parameter read-only analysis tool with full schema coverage and no output schema, the description covers what the tool does and how to interpret its output. Only the shape of the returned result is left unaddressed.

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

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

Schema description coverage is 100%, with all five parameters (including defaults for days and min_correlation) documented in the schema itself. The description adds no parameter meaning beyond that, so the baseline 3 applies.

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

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

States a specific verb ('Find') and resource ('tests that tend to fail together with a given test'), including the analytical relationship being computed. It does not explicitly differentiate itself from near-neighbors like get_failure_patterns, 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.

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

The second sentence ('shared setup issues, test pollution, or dependencies') implies the diagnostic scenario in which this tool is useful, but there is no explicit when-to-use, when-not-to-use, or named alternative among the nine siblings.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses the analysis dimensions returned (failure rates by hour, day, version, browser/site, duration), implying a read-only aggregate report, but says nothing about permissions, data volume, or how results are shaped.

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

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

Two sentences, front-loaded with the purpose and then the return dimensions, with no filler. Efficient, though it could be tightened into one sentence.

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

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

With no output schema, the description does some work by listing the breakdowns produced, which is the key thing an agent needs to know. However, it omits scoping behavior (does spec_file alone drive the analysis? what happens without project_id?), and gives no hint about result size or how it differs from the nine sibling analysis tools.

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

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

Schema coverage is 100%, so every parameter (days, spec_file, project_id, test_title) is already documented in the schema. The description mentions analysis dimensions but does not clarify how those map to or interact with parameters like test_title or project_id, so it adds little beyond the schema baseline.

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

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

States a specific verb and resource: analyze test failures to identify patterns, and enumerates the dimensions of the analysis (hour, day of week, version, browser/site, duration). It is distinguishable from siblings like get_recent_failures or get_flaky_tests, though it never names or contrasts against them explicitly.

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

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

No when-to-use guidance, no prerequisites, and no mention of the many sibling tools (get_flaky_tests, get_correlated_failures, get_test_trend, etc.) that an agent must choose between. The agent is left to infer that this is the 'pattern analysis' option purely from the verb 'analyze'.

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

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

No annotations provided, so the description carries the full burden. It discloses that it returns presigned S3 URLs and that they can be viewed with the Read tool, which is useful operational context. However, it doesn't mention URL expiration, permissions needed, or behavior when no failures exist.

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

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

Two sentences, front-loaded with purpose, followed by a useful operational note about viewing URLs with the Read tool. No waste.

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

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

For a 5-param read tool with no annotations and no output schema, the description covers the purpose and return type well but omits when to choose it over siblings, any limitations, or error behavior. Adequate but leaves gaps.

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

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

Schema description coverage is 100%, so all parameters are documented in the schema with defaults and meanings. The description doesn't add parameter-level detail beyond saying 'recent test failures', which aligns with the days parameter. Baseline 3 applies when schema fully covers params.

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

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

States a specific verb (get) and resource (failure screenshots from recent test failures). It's clear what it returns, but it doesn't distinguish itself from the many sibling tools like get_recent_failures or get_failure_patterns beyond the 'screenshots' aspect.

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

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

The description implies usage — viewing what the UI looked like when a test failed — but doesn't say when to use this vs. siblings like get_recent_failures. No explicit when/when-not guidance.

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

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

With no annotations, the description carries the behavioral burden and delivers important context: the data source (pre-computed materialized view), caching behavior ('refreshed hourly'), and the output granularity (spec-level, not test-level). It doesn't mention pagination, rate limits, or result format, but given no output schema, the disclosed traits are meaningful and non-obvious.

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

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

Three sentences with zero waste, front-loading the core purpose and speed rationale. Every clause adds distinct value without redundancy.

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

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

For a parameterized query tool with complete schema coverage and no output schema, the description covers the essential context: data source, freshness, and granularity. It omits return structure, but lacks an output schema to define it. The definition is sufficient for correct invocation, missing only secondary details like pagination.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters with types and defaults. The description adds no parameter-level information (e.g., how min_flaky_percent interacts with min_flaky_count). Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description states a specific verb (Get) and resource (flaky specs), and crucially distinguishes itself from the sibling get_flaky_tests by clarifying the granularity: 'spec-level flakiness (not individual test level)'. This differentiation is exactly what an agent needs to choose between the two sibling tools.

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

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

It explicitly says to use this over get_flaky_tests when speed matters ('Faster than get_flaky_tests'), providing a clear conditional selection rule. However, it doesn't state when NOT to use this tool (e.g., when fresher, non-cached data is required), which prevents a full 5.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses a cost/performance trait (full project scan, smaller windows are faster), but says nothing about permissions, pagination beyond the limit param, or what fields are returned. Partial behavioral disclosure for an annotation-free tool.

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

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

Two tight sentences: the core purpose and the flakiness definition come first, followed by the scan-cost caveat. No filler, and the highest-value information is front-loaded.

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

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

For a four-parameter, annotation-free list tool with no output schema, the description covers purpose and cost behavior but omits what the returned list actually contains and whether results are paginated or limited by anything besides 'limit'. Adequate but with clear gaps for an agent that needs to interpret the output.

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

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

Schema description coverage is 100%, so all four parameters including defaults and the days tradeoff are already documented in the schema. The description's re-statement of the days hint adds no meaning beyond the schema, so the baseline of 3 applies.

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

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

The description states a specific verb and resource ('get a list of flaky tests') and even defines the term ('tests that fail then pass on retry') plus the sort order by flakiness rate. It is clear on its own, but it does not distinguish itself from the nearby sibling get_flaky_specs, which an agent could easily confuse it with.

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

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

There is a useful performance hint ('this scans all tests - use smaller days values for faster results'), which is implied usage guidance around the days parameter. However, there is no explicit when-to-use statement and no named alternative among the many siblings (get_flaky_specs, get_test_history, get_failure_patterns), so selection is left to inference.

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies read-only retrieval with recency ordering and a performance trait ('faster results' with spec_file), but discloses nothing about pagination, result caps, permissions, or return format. Given the higher bar with zero annotation coverage, this is only partially met.

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

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

Three short sentences with the core purpose front-loaded and zero filler. The performance tip is placed last, where it reads as a secondary detail.

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

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

For a low-risk, fully-schema-documented, all-optional read tool this covers the essentials: what it returns and how to speed it up. The lack of an output schema and any sibling differentiation keeps it from being fully complete.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters and the baseline is 3. The description only adds meaning for spec_file ('for faster results'), a performance rationale not present in the schema, while hours/limit/project_id semantics rest entirely on the schema.

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

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

States a specific verb and resource ('Get the most recent test failures') and scopes it with 'most recent' and 'quick triage', which separates it somewhat from history/trend siblings. However, it never names or differentiates from near-neighbors like get_consecutive_failures or get_failure_patterns, leaving the agent to guess which failure-listing tool fits.

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

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

'Useful for seeing what's currently broken' implies a usage context and the spec_file tip implies a performance scenario, but there is no explicit when-to-use-vs-alternatives guidance among the nine sibling tools. No exclusions or prerequisites are stated.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the returned health_status values (healthy/flaky/broken/disabled/insufficient_data) and the test_health view source, but says nothing about read-only safety, result volume, or pagination.

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

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

Three short sentences, front-loaded with the purpose before the usage hint and output detail. The health_status enumeration is the only mildly dense element and it earns its place by naming concrete return values.

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

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

For a read-only stats tool with no annotations and no output schema, the description covers purpose and one output field but leaves return shape, data volume, and time-window semantics largely unspecified. Adequate but not thorough for the complexity level.

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

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

Schema description coverage is 100%, so all four parameters (days, spec_file, project_id, test_title) are already documented in the schema. The description adds no syntax, format, or default guidance beyond what the schema provides, so the baseline of 3 applies.

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

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

The description gives a specific verb (Get) and resource (historical pass/fail/flaky statistics) scoped to a single test, which an agent can distinguish from siblings like get_flaky_specs or get_test_trend. It does not explicitly name a sibling to contrast against, 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.

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

'Use this to understand how often a test fails and its overall reliability' implies the use case but never states when to prefer this over get_test_trend, get_flaky_tests, or get_recent_failures. No exclusions or prerequisites are given.

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

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

No annotations are provided, so the description carries the full behavioral disclosure burden. It implies a read operation via 'Get,' but does not state read-only status, authentication needs, rate limits, result shape, or any other behavioral trait beyond the basic purpose.

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

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

The description is a single, front-loaded sentence with zero waste. It states the core action and its primary value immediately.

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

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

For a 5-parameter tool with no annotations and no output schema, the description is too thin. It does not explain what trend data is returned, how to interpret it, or when to prefer alternatives, leaving significant contextual gaps.

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

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

Schema description coverage is 100%, so the schema already fully documents all five parameters. The description adds no additional parameter meaning, such as format or interaction details, making the baseline of 3 appropriate.

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

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

The description states a specific verb and resource: 'Get trend data for a test over time,' and adds a clear use case ('seeing if a test is getting more or less reliable'). It does not explicitly distinguish itself from similar siblings like get_test_history or get_flaky_tests, 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.

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

It provides an implied usage context ('useful for seeing if a test is getting more or less reliable') but gives no explicit when-to-use guidance, no exclusions, and does not name alternative tools. This is adequate but leaves routing decisions to inference.

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