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

readOnlyHint=true is consistent with 'read from', so no contradiction. The description usefully discloses the data source (pytest-cov report in logs), which implies results are unavailable if logs are absent or the project doesn't use pytest-cov, but it never says so outright or describes the failure mode.

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?

A single front-loaded sentence with zero filler; the resource and its source are both stated 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?

The output schema covers the return shape, so that need not be explained. However, with 0% parameter coverage and no note on scope (the description says 'per job' while the input only accepts a run_id, implying a per-job breakdown of an aggregate call), an agent must guess at the mapping.

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% for two required parameters, so the schema gives no semantics for repo or run_id. The description does not mention either parameter, leaving the agent to infer that run_id is a CI run and repo scopes it.

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?

Specific verb and resource: reads total line coverage, and names the data source (pytest-cov report in job logs). It differentiates itself from generic siblings like job_log by being a derived metric, though it never explicitly contrasts with them.

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?

Usage is only implied: it should be used when you want coverage numbers, and the 'read from job logs' phrasing hints that logs must exist first. No explicit when-not or alternative (e.g. use job_log for raw output) is 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?

Annotations declare readOnlyHint and openWorldHint. The description adds the output limit (up to 30) and an important security note treating log text as data, not instructions. This goes beyond structured fields, though it omits auth or rate-limit details.

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, then usage guidance, then safety note. No wasted words; every sentence contributes.

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?

Output schema exists, so return values need not be explained. However, with 0% schema coverage and no parameter descriptions, the definition is incomplete for an agent needing to know how to supply 'repo' (e.g., owner/repo) and 'run_id'.

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 does not explain the 'repo' or 'run_id' parameters. It only implies a 'run' context, leaving the agent to infer format and meaning from parameter names.

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 (summarizes) and resource (why a run failed), and enumerates output (failed jobs, steps, error lines). The phrase 'Start here when a build is red' distinguishes it from sibling log tools like job_log, though it doesn't name 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?

'Start here when a build is red' gives explicit when-to-use guidance. It implies alternatives for deeper log inspection (e.g., job_log) but does not name exclusions or alternatives explicitly.

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?

Annotations already establish that this is a read-only, open-world operation. The description adds useful context about the response shape by mentioning jobs and failed steps, but it says nothing about error behavior, missing runs, or access requirements.

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 no wasted text. Its brevity is efficient, though it may be too sparse given the undocumented parameters.

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?

An output schema exists, so return-value detail is less critical. However, the description leaves both required inputs completely unexplained and provides no usage context or error semantics, which is a significant gap for an agent invoking 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 never explains the two required parameters. An agent must infer that 'repo' identifies the repository and 'run_id' identifies the run, with no format or scoping guidance.

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 clearly identifies a single-run retrieval tool and names the nested content it returns (jobs and failed-job steps). It does not explicitly contrast itself with siblings like list_runs or job_log, so it stops short of full sibling differentiation.

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 explicit when-to-use guidance, no mention of alternatives such as list_runs or failure_summary, and no stated preconditions. Usage is only implied by the name and the phrase 'One run'.

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?

Adds real context beyond readOnlyHint/openWorldHint: output is normalized (no timestamps/colors), tail is capped at 500, and log content is explicitly framed as untrusted data with an instruction not to follow anything inside it. That injection warning is valuable safety context for an open-world read. It stops short of saying what happens when tail exceeds 500 or whether truncation is signaled.

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 tight sentences, each doing distinct work: what the output is, how the two optional params modify it, and how to treat the content. The safety note is placed last, after the functional facts are already 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?

An output schema exists so return shape needn't be described, and the description covers normalization, filtering, and trust boundaries. Minor gaps remain: whether truncation is visible in the result and what errors occur for an unknown job_id or over-limit tail.

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 0% — properties carry only titles — so the description carries the load, and it does well for the two non-obvious params: pattern is a Python regex that keeps matching lines, tail keeps the last N with a 500 ceiling. repo and job_id are left entirely undefined, though their meaning is largely self-evident from context.

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?

Names the resource precisely ('lines from one job's log') and the transformation applied (timestamps and color codes removed), which distinguishes it from get_run and failure_summary. It never states the operation as a verb (fetch/read) and leaves the repo/job_id scoping implicit, but the identity is unambiguous.

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?

Explains how the optional modifiers behave (pattern filters, tail truncates to the last N) but never says when to choose this tool over get_run or failure_summary. An agent must infer that this is the raw-log view while siblings offer structured summaries.

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?

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds the sort order ('newest first'), which is genuinely beyond the annotations, but says nothing about how many runs are returned, whether 'recent' is a bounded window, or how the default limit of 10 truncates results.

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 short sentences, zero filler, with the ordering constraint front-loaded. Nothing could be cut without losing 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?

An output schema exists, so return values need not be described, and annotations cover safety. But for a listing tool with a defaulted limit and zero schema descriptions, the omission of limit/pagination behavior and sibling routing leaves real 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 0%, so the description must carry parameter meaning. It explains only the branch filter (optional, narrows results); 'limit' — the parameter that controls result size — is never mentioned, and 'repo' is only implied by 'for a repo'.

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?

Specific verb+resource: lists workflow runs for a repo, with a stated ordering (newest first). It implicitly separates itself from get_run by being the plural/listing form, but never names the sibling or states the boundary 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 guidance on when to call this versus get_run, job_log, or failure_summary. The only conditional language is 'Optionally filter by branch', which describes a parameter, not a usage situation.

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?

The annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds useful context that results are limited to the latest commit and include status/conclusion fields. It does not mention pagination, auth requirements, or behavior when no checks 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?

A single front-loaded sentence with zero wasted words. It states scope and returned fields efficiently.

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?

An output schema exists, so return value explanation is unnecessary. However, with two required, undocumented parameters and no usage context, the definition is only minimally adequate for correct invocation.

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 for undocumented parameters. It does not explain the required repo format (e.g., owner/name) or that pr is a pull request number, leaving both required parameters underspecified.

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 names a specific resource and scope: all CI checks on a pull request's latest commit, including status and conclusion. It is clear what the tool returns, though it does not distinguish itself from siblings like list_runs or job_log.

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 such as list_runs or failure_summary, nor any prerequisites or exclusions. The agent must infer usage from the name alone.

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