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

With no annotations, the description carries the full burden and does substantial work: it discloses that cron evaluation is done by a built-in implementation honouring the day-of-month OR day-of-week rule, that next 5 run times are returned in UTC, and that it emits warnings about congested schedules and intervals under 5 minutes. It also surfaces the GitHub platform constraints (default branch only, disabled after 60 days inactivity). What it omits is the read-only nature and what happens for an invalid or non-workflow path.

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 sentence, front-loaded with the core action, and every clause names a distinct capability rather than padding. The parenthetical about the cron implementation and the day-of-month OR day-of-week rule is dense but earns its place by explaining an easily-misread edge case.

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 needn't be described, and the behavioural surface is well covered for a read-style inspection tool. The unresolved 'path' argument is the main completeness hole, since an agent cannot tell from the definition what to pass.

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?

The sole parameter is 'path' with 0% schema description coverage, and the description never mentions it — it does not say whether path is a workflow file, a directory of workflows, or repo-relative. For a single-parameter tool the description is the only place this could be clarified, and it isn't.

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 and resource — 'Explain in plain English when each workflow runs' — and enumerates exactly which trigger facets are covered (push/PR filters, fork behaviour, workflow_run chains, cron). It is clearly distinct from lint_workflows or job_graph by scope, though it never names a sibling to route against.

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: an agent can infer this is the tool for understanding trigger configuration, but there is no explicit 'use this when...' statement, no exclusion (e.g. 'for validation errors use lint_workflows'), and no note on prerequisites such as needing a checked-out repo.

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 burden and does so well: it discloses the read-only guarantee explicitly, describes the internal verification loop ('re-linted to prove the findings disappear and none are introduced'), and notes that unfixable items are reported separately. These are non-obvious behavioral traits an agent could not infer from the name.

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?

Front-loaded with the core action and a concrete enumeration of fix kinds, then closed with the two most decision-relevant facts (no writes, manual items listed). The middle sentence is dense but every clause maps to a distinct behavior; no filler sentences.

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 need not be explained. Given the tool's simplicity (one path parameter, no nested objects), the description covers scope, fix categories, safety posture, verification, and follow-up action — sufficient for an agent to call it 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% and the single `path` parameter has no schema documentation, so the description must compensate. It does: 'a workflow file (or every workflow under a directory)' clarifies that the argument accepts either a file or a directory and implies recursive scope, which is meaningful semantics beyond the bare string type.

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?

Opens with a specific verb and artifact: 'Show a unified diff of the safe automatic fixes for a workflow file'. It then enumerates exactly which fix categories are covered (permissions scoping, expression injection into env, set-output replacement), which distinguishes it from lint_workflows (finding problems) and pin_actions_plan (pinning actions) without ambiguity.

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?

'Never writes the file: apply the diff yourself' gives a clear operational contract, and 'Lists what needs a manual change' tells the agent this is a proposal, not an application. It stops short of naming an explicit alternative or prerequisite (e.g. run lint_workflows first), so the routing signal is strong but not fully spelled out.

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 burden, and it does disclose meaningful behavior: it reports cycles, computes a worst-case duration bound from timeout-minutes, and emits both textual and Mermaid output. It stops short of stating that the operation is read-only and whether it scans all workflow files beneath the given path.

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 dense sentence front-loads the core action and then lists the derived analyses, with no filler. It is slightly packed but every clause adds a distinct capability.

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 not required, and the description covers the analytical features well. The remaining gap is scope: how `path` selects inputs and whether the tool is read-only, which matters for an agent deciding whether to call it freely.

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?

The single parameter `path` has 0% schema description coverage and defaults to '.', yet the description never mentions it or explains whether it points to a repo root, a workflow directory, or a specific file. With only one parameter and no schema help, the description should compensate and does not.

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?

Uses a specific verb and resource ('Draw each workflow's job `needs:` graph') and enumerates concrete outputs (text, Mermaid diagram, waves, critical path, duration bound, cycle reporting). This is distinct in kind from siblings like lint_workflows or workflows_overview, though no sibling is named 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?

The description implies when the tool is appropriate (dependency/parallelism analysis and visualization), but gives no explicit 'use this instead of X when...' guidance and no exclusions, despite six plausible alternative analysis tools in the sibling list.

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 zero annotations the description carries the full burden and does so well: it declares read-only behavior explicitly ('Never modifies anything'), documents the suppression mechanism and its exact syntax, and states the shape of each finding (rule id, severity tiers, file:line including the exact line inside multi-line `run: |` blocks, explanation, fix). These are the behavioral facts an agent needs before deciding to run it in a pipeline.

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?

Purpose, severity model and read-only guarantee are front-loaded, which is good. But the middle is one very long sentence enumerating ~25 checks, several of which (cache keys, matrix size, unquoted 3.10) add little to an agent's decision to invoke the tool and could be compressed to a summary plus examples.

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 linter with an output schema already defined, the description covers scope, severity vocabulary, suppression, and a clear mutation guarantee. The one real hole is `path` semantics (what is scanned, recursion, default behavior), which is exactly the information an agent needs to call it 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% and the description never mentions the single `path` parameter — not whether it is a file, directory, or glob, whether traversal is recursive, or what the default '.' expands to. Given only one self-evidently named parameter, the omission is not fatal, but no meaning is added beyond the bare 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 opening sentence gives a specific verb and resource ('Lint workflows and composite actions'), names the exact rule set (33 rules, GHA1001-GHA1033), and the description scopes it clearly against siblings like fix_preview and pin_actions_plan by being purely diagnostic. An agent can distinguish it from every other tool in the list without opening a schema.

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 implied rather than stated: the long 'Covers:' list tells the agent what problems this detects, which implicitly tells it when the tool applies. However, there is no explicit when-to-use/when-not-to-use statement and none of the six siblings (e.g., fix_preview, pin_actions_plan) are named as follow-ups or alternatives, so routing 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?

With no annotations, the description carries the full disclosure burden, and it does fairly well by explaining the resolution rule (job-level replaces workflow-level; absent means repo default) and the heuristic nature of inference, including that partial results are flagged. It falls short of a 5 because it never states that the tool is read-only and does not scan or modify files, nor what happens when no workflows are found, both of which an agent would want to know before calling.

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?

It is a single dense sentence that front-loads the main action and enumerates sub-behaviors in order, with no filler. The run-on structure with multiple em-dash and parenthetical clauses makes it slightly harder to parse than short separate sentences would.

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 values need not be explained because an output schema exists, and the description covers the analysis logic, the resolution rule, and heuristic limits well. The remaining gap is the undocumented path parameter and the absence of any statement about read-only behavior, which leaves the definition slightly incomplete for a repo-scanning analysis 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?

There is one optional path parameter with a default of '.' and 0% schema description coverage, and the description never mentions it. An agent reading only the description would not know what path refers to (a repo root, a workflow file, or a directory of workflows), which is exactly the kind of gap the description should close at low schema coverage.

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: it shows the effective GITHUB_TOKEN permissions of every job, infers what each job needs, flags mismatches, and prints a least-privilege permissions block. That is far more concrete than the sibling names (workflows_overview, lint_workflows, job_graph) and makes it clear this tool is the permissions analyzer rather than a general linter or graph view.

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 when it is useful by describing the permissions analysis, but it never says when to choose it over lint_workflows or workflows_overview, nor when not to use it. No prerequisites or scope conditions are stated, so the agent has to infer usage from the purpose alone.

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 supplied, the description carries the full burden and does so thoroughly: network isolation by default, the exact host contacted when online, annotated-tag dereferencing, caching, honest rate-limit messaging, and GITHUB_TOKEN handling scoped to that host only. It also states the operation is non-mutating ('nothing is written').

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?

Front-loaded with the core promise, then the mode contrast, with no filler sentences. It is dense with parentheticals, which makes it slightly harder to scan than necessary, but each clause carries real 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, yet the description still usefully characterizes the return as a text plan. Network, credential, and mutation behavior are all covered; the only real gap is the unexplained `path` input, which matters for a tool whose scope depends on where it scans.

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 fully specifies the semantics of `online` (default false, what each mode does, which host is contacted), but the `path` parameter — which determines the repository root scanned — is never mentioned or clarified beyond its schema default of '.'.

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 — list every `uses:` not pinned to a full commit SHA — plus the output shape (grouped by action version, with file:line) and an added deliverable (how to pin each). This is clearly distinguishable from siblings like lint_workflows or fix_preview.

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?

Explicitly lays out the two operating modes: online=false (default, no network, `git ls-remote` instructions) versus online=true (resolve tags/branches via api.github.com). It also signals via 'Output is a plan as text: nothing is written' that this is advisory rather than a fixer, implying fix_preview for application, but it never names that sibling or states an exclusion.

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 burden well: it discloses that secret values are never read (only names), that invalid YAML is reported with a line number rather than failing, and that local composite actions are included. It never explicitly says the operation is read-only or requires no authentication, which keeps it from a 5.

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?

Front-loaded with the scope enumeration and closed with the actionable 'Start here', with no filler. The middle sentences are dense and run long, but every clause adds real information about coverage or behavior.

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, and the description covers scope, input forms, and error behavior for a fairly complex analysis tool. The missing pieces are minor: no explicit read-only assurance and no mention of the '.' default, both of which an agent would otherwise have to infer.

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: `path` is defined as a workflow file, a repo root containing .github/workflows, or the workflows directory. The default value of '.' is never mentioned and no example path is given, so a small gap remains.

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 (Summarize) and resource (GitHub Actions workflows) and then enumerates exactly what is covered: triggers, jobs with runners and needs, per-job permissions, actions with pin status, environments, secret names, and local composite actions. An agent knows precisely what this returns without opening the schema.

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 closing 'Start here' gives clear entry-point guidance that positions it ahead of the sibling tools (lint_workflows, job_graph, permissions_review, etc.), and the path sentence explains the three accepted input shapes. It stops short of naming any sibling or saying when to prefer a narrower tool, so it falls short of a 5.

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