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

No annotations are present, so the description carries the behavioral burden. It clearly signals a read-only retrieval through the verb 'Get' and identifies the summary sections returned. However, it does not mention authentication needs, failure modes, or whether any side effects exist, though those are less critical for a simple read-by-ID 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?

The description is one clear purpose sentence plus one concise parameter line. There is no filler, and the key action and content scope are 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?

The input schema and output schema cover most mechanics, and the sole parameter is documented in the description. The main gap is context: the definition does not help an agent decide when to call this tool instead of a closely related sibling, and it lacks any usage exclusions.

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 0%, but the description explicitly explains the only parameter: 'build_id: The CDash build ID.' This adds real semantic meaning over the bare integer schema. It could be a 5 if it also described format or range constraints.

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 uses a specific verb and resource ('Get detailed information about a specific build') and adds the key content areas ('configure/compile/test summaries'), which helps distinguish it from error-only or test-only siblings. It is not a 5 because it does not explicitly name sibling tools or state what it is not for.

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 guidance is provided about when to use this tool versus alternatives. With ten sibling get_* tools that overlap in scope (get_build_errors, get_build_tests, get_test_summary), an agent gets no help choosing among them.

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 provided, the description carries the behavioral disclosure burden. It correctly signals a read-only operation ('View'), describes the output contents, and documents pagination behavior via limit and offset. It does not mention auth requirements or rate limits, but those are less critical for this simple read operation.

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 compact, front-loaded with a clear one-sentence purpose, and followed by a clean parameter list. Every line earns its place with no redundant filler.

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?

Given the tool's simple query nature and the presence of an output schema, the description covers all necessary caller-facing behavior: what it returns, how to switch modes, and how to paginate. It could have strengthened cross-tool orientation, but that is not essential for invoking this tool correctly.

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 0%, so the description must fully document parameter meaning. It does: build_id is identified as the CDash build ID, warnings toggles errors vs warnings, limit caps the result count, and offset is explicitly tied to pagination. This adds significant value beyond the raw 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?

The description uses a specific verb ('View') and resource ('compiler errors or warnings for a build') and includes what information is returned (source file and line info). This clearly differentiates it from sibling tools focused on tests, coverage, or configuration output.

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 makes it clear this tool is intended for retrieving compiler errors or warnings, but it does not explicitly state when to prefer it over alternatives or mention any sibling tools. Usage context is implied rather than formally contrasted.

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 provided, the description carries the full behavioral disclosure burden. It does add useful constraints: status_filter is restricted to 'passed', 'failed', or 'notrun', and limit has an undocumented max of 200, which prevents invalid calls. However, it does not address read-only semantics, behavior on invalid or missing build IDs, or empty-result handling, though the output schema partially covers the return shape.

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 one-sentence purpose is front-loaded, followed by four compact, uniformly formatted argument lines with zero filler. Every line earns its place, especially given the schema's 0% description coverage means this text is the only parameter documentation.

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 4-parameter tool with an output schema, the mechanics of invocation are well covered: all params documented, defaults and caps stated, returns handled by the schema. The notable gaps are the absent sibling differentiation against get_failing_tests/get_test_summary and no hint about where a build_id originates, which an agent would need to chain calls correctly.

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 0%, so the description must compensate, and it does: status_filter gains its valid value set ('passed', 'failed', 'notrun') which the schema leaves as an unconstrained string, limit gains its max-200 cap, and offset gains its pagination purpose. Only build_id ('The CDash build ID') is near-tautological, but the other three parameters get meaningfully enriched.

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 opening sentence 'List tests for a specific build, optionally filtered by status' gives a specific verb, resource, and scope in one line. It is clearly distinct from siblings like get_dashboard and get_configure_output, though it does not explicitly differentiate itself from the closely related get_failing_tests and get_test_summary.

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 no guidance on when to use this tool versus alternatives. Given the sibling get_failing_tests, an agent cannot tell whether to call this with status_filter='failed' or to use the dedicated sibling. The only usage hints are mechanical ('Use for pagination' on offset), not selection criteria.

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 provided, the description carries the full burden of behavioral disclosure. It only says 'View,' implying a read operation, but does not mention whether authentication is required, whether VCS data could be absent, or any other behavioral caveats. Some context is implied by the output schema, but the description itself is minimal.

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 extremely concise and front-loaded, stating the purpose in the first sentence. The Args block is brief and directly explains the only parameter without unnecessary elaboration.

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 tool with a single parameter and an output schema, the description covers the core function and parameter meaning. It lacks explicit usage guidance and behavioral caveats, but the simplicity of the tool and the presence of an output schema reduce the need for extensive additional context.

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 0%, so the description must compensate. It does identify the parameter as 'The CDash build ID,' adding domain meaning beyond the schema's generic 'Build Id' title. However, it provides no additional detail about expected format, range, or source, so the compensation is only partial.

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 ('View') and resource ('source code changes (VCS commits) associated with a build'). This clearly distinguishes it from sibling tools like get_build_details, get_build_tests, or get_build_errors, which cover different aspects of a build.

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 does not explain when to use this tool versus alternatives. It simply states what the tool does, leaving the agent to infer the appropriate context from sibling tool names rather than providing explicit 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 provided, the description carries the full burden, and it does add behavioral value beyond the schema: it discloses the offset/limit pagination mechanism, the 34 KB default bound, and the 'Set to 0 for no limit' behavior. However, it stays silent on invalid build IDs, whether command and output are returned together, and error/truncation handling.

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?

One purpose sentence followed by a compact three-bullet Args section; information is front-loaded and every line earns its place. It slightly repeats default values already present in the schema, but that redundancy is offset by the added '34 KB' interpretation and the '0 = no limit' clarification.

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-complexity three-parameter read tool with an output schema present, the description covers purpose and all parameter semantics including pagination. The main gaps are the absence of usage-routing context and edge-case behavior, both minor given the simple call surface and the output schema covering return values.

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 0%, so the description must fully compensate, and it does. All three parameters receive meaningful semantics: build_id ('The CDash build ID'), output_offset ('Character offset into the configure output'), and output_limit ('Maximum characters of output to return... Set to 0 for no limit'). This adds far more than the bare integer types and defaults in 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?

The description opens with a specific verb-object pair — 'View CMake configure command and output' — scoped to a build via build_id. This targets the configure step's command and output, which is clearly distinct from siblings like get_build_details, get_failing_tests, or get_build_errors, so an agent can tell them apart without inspecting schemas.

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 no guidance on when to use this tool versus alternatives. It never references a sibling, states an exclusion, or explains how it differs from get_build_details or get_build_update. The Args block documents parameters only; it does not convey when an agent should reach for this tool.

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 does disclose meaningful traits: the with/without-build_id behavioral fork, the Nightly-only limitation, default date behavior, and pagination via limit/offset. It does not describe the output shape (delegated to the output schema) or edge-case/error behavior, so transparency is adequate but not comprehensive.

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 front-loaded with a one-sentence purpose statement followed by a compact, scannable Args block. Every line adds information—defaults, constraints, and behavioral notes—with no filler or repetition of schema content.

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, 1-required tool with an output schema present, the description covers purpose, all parameters, defaults, constraints, and the conditional build_id behavior—enough for an agent to invoke it correctly. Minor omissions, such as how date and build_id interact and edge-condition behavior, keep it just short of fully comprehensive.

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?

With 0% schema coverage, the description fully compensates: project gets a concrete example ('PublicDashboard'), date gets a format and default, build_id gets a behavioral explanation plus recommendation, and limit/offset get meaning, defaults, a max cap, and a pagination hint. Every parameter is documented well beyond the bare schema titles.

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 opening line 'Compare code coverage across builds for a project' pairs a specific verb with a specific resource and scope, and 'detecting coverage regressions' states the tool's purpose. No sibling tool covers code coverage, so the description differentiates it from the get_build_details/get_dashboard family by its cross-build focus.

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 gives clear invocation context: 'Useful for detecting coverage regressions' and advises 'provide a build_id from the dashboard for reliable results,' including the constraint that cross-build comparison 'only works for Nightly builds.' It stops short of explicitly naming when to choose this tool over a sibling, so it doesn't reach the explicit-alternatives bar of a 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?

With no annotations, the description must carry behavioral transparency. 'Get' implies a read operation and the default date behavior is disclosed, but the description does not mention authentication, error behavior, caching, or explicitly state non-mutation. It is minimally transparent but not rich.

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 compact: one sentence for purpose, then two argument lines with no filler. The most useful information is front-loaded and every sentence earns its place.

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?

Given the low parameter count and existing output schema, the description covers the essential invocation details. It lacks explicit sibling routing and a stated read-only guarantee, but the output schema supplies return-structure information and the parameters are fully documented.

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 0%, so the description must compensate, and it does: both parameters are explained with format ('YYYY-MM-DD'), an example project name, optionality, and the default-to-today behavior. This adds real semantic value beyond the raw 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?

The description uses a specific verb ('Get'), names the resource ('CDash dashboard'), scopes it to 'for a project', and specifies the content ('showing build groups and status'). This distinguishes it from siblings like get_build_details or get_project_overview, which target different artifacts.

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 the tool is for retrieving a project dashboard, but it gives no explicit when-to-use guidance or alternatives. There are ten sibling tools, and the description does not explain when get_dashboard should be preferred over get_project_overview or get_build_details.

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?

There are no annotations, so the description carries the behavioral disclosure burden. It discloses useful pagination behavior for limit/offset, including default and maximum values. It does not mention errors, empty results, or performance implications, but it does provide more than a bare getter statement.

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 compact: a one-sentence purpose followed by a clean Args block. Every line earns its place, and the key purpose is front-loaded before parameter details.

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 simple read-style getter with an output schema present, the description is complete. All three parameters are fully documented, the pagination semantics are clear, and the output schema covers return values. Nothing needed to call the tool correctly is missing.

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 0%, so the description fully compensates. It explains build_id as the CDash build ID, limit as maximum defect entries with default and max, and offset as entries to skip with pagination guidance. This adds meaning far beyond the bare integer properties in 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?

The description states a specific verb and resource: "Get dynamic analysis results (e.g. Valgrind, sanitizers) for a build." This clearly differentiates the tool from siblings like get_build_errors, get_test_summary, and get_build_details, which target other build artifact types.

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: an agent should call this when it needs dynamic analysis results (Valgrind, sanitizers) for a specific build. However, it does not explicitly compare against sibling tools or state when not to use this tool, leaving the routing decision mostly to the tool name and examples.

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 behavioral disclosure. It covers default behavior (date defaults to today), filter semantics (test_name is a substring match), and pagination via offset/limit. It stops short of stating side-effect/read-only guarantees explicitly, but the "Find" verb makes the intent clear.

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 front-loads the core behavior and use case, then uses a tidy Args block. Every sentence adds value: defaults, constraints, and pagination are all included without fluff.

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?

The description is complete for a query-type tool: scope, all parameters, defaults, and pagination are covered, and the output schema handles return-value details. It does not explicitly route to siblings for single-build or summary use cases, which would strengthen completeness further.

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 0%, so the description must explain the parameters, and it does: project name with an example, date format and default, substring filtering behavior, limit with max value, and offset for pagination. This fully compensates for the empty schema descriptions.

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 opening sentence uses a specific verb and resource: "Find non-passing tests across all builds for a project." This clearly distinguishes the tool from siblings like get_build_tests, which is build-specific, by emphasizing the cross-build scope.

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?

"Most useful for CI triage" gives a concrete use context. It does not explicitly name alternatives or say when not to use the tool, but the scope wording helps an agent infer when this is the right choice.

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?

There are no annotations, so the description carries the full burden. It discloses the default-date behavior and that the statistics are aggregates, which adds some transparency. However, it does not mention permissions, whether data is live or cached, or any edge-case behavior around the optional date. This is adequate but not rich.

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 compact and front-loaded with the core purpose, followed by a clean parameter list. Every sentence earns its place, and there is no redundant or vague filler.

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 simple two-parameter read tool with an output schema, the description covers the essential invocation details: what the tool does, what project to pass, how to format the date, and the default behavior. It lacks sibling-selection guidance, which keeps it from being fully complete, but nothing critical is missing for calling the 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 0%, and the description fully compensates by documenting both parameters. It explains that 'project' is a CDash project name with a concrete example, and that 'date' is optional, formatted as YYYY-MM-DD, and defaults to today. This gives an agent everything needed to fill the parameters correctly.

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 uses a specific verb and resource: 'Get project overview with aggregate build/test/coverage statistics.' This clearly distinguishes it from sibling tools like get_build_details or get_failing_tests by focusing on high-level aggregate data. The purpose is immediately understandable.

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 does not state when to use this tool versus alternatives like get_dashboard or get_test_summary. It provides no exclusion criteria, no prerequisite context, and no explicit guidance on when the project overview is the right choice. The use case is only implied by the tool's name and the word 'overview'.

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 and handles it well: it discloses the date default ('Defaults to today'), the limit bound ('max 200'), and pagination mechanics ('Use for pagination' via offset). The behavior is read-only by implication ('Get'), and no side effects are claimed; the only gap is silence on empty-result behavior when a test has no history.

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 purpose statement is front-loaded in one tight sentence, followed by a compact Args block where each line earns its place with defaults, examples, or bounds. There is no filler, repetition of schema titles, or tangential information.

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 read-only query with an output schema available, the description covers everything needed to invoke the tool correctly: required vs. optional params, formats, defaults, and pagination. The only omissions are minor — expected behavior for unknown test names and the exact shape of the summary payload, the latter being reasonably delegated to the output schema.

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 0%, and the description fully compensates by documenting all five parameters with added meaning: a concrete example for project ('PublicDashboard'), the exactness requirement for test_name, the YYYY-MM-DD format plus default for date, the 50/200 default/max bounds for limit, and the skip semantics for offset. This goes well beyond the bare schema titles.

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 opens with a specific verb-resource pair ('Get summary of a test across builds') and states the analytical purpose ('shows pass/fail history to detect flaky tests'). The cross-build scope clearly differentiates it from build-scoped siblings like get_build_tests and get_build_details.

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 stated purpose ('pass/fail history to detect flaky tests') gives clear context for when to invoke this tool, and the cross-build framing implies it is for historical analysis rather than single-build inspection. However, it never names alternative tools or states when not to use it, so it stops short of explicit exclusions.

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