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

Annotations already declare readOnly, idempotent, closed-world and non-destructive, so the safety profile is covered; 'Read-only, no arguments, no network' largely restates them. The description earns credit by disclosing the actual content of the returned rules (grouping the prior day by theme, deriving today from open merge requests, reporting a blocker from its job log), which the agent cannot learn elsewhere.

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-loads what is returned, then the workflow guidance, in two tight sentences with no wasted preamble. The 'Read-only, no arguments, no network' clause is partially redundant with the annotations and schema, which keeps it from a 5.

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 carries the burden of conveying what comes back, and it does so by enumerating the three rule areas the playbook covers. An agent knows what it gets and how to use it; only the exact response format is left unspecified, which is minor for an instruction-fetch 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 are zero parameters, so the baseline is 4. The description's 'no arguments' is consistent with the empty input schema and leaves no ambiguity about how to call 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?

States a specific verb+resource (returns note-writing rules) and immediately scopes it as the playbook for transforming get_standup_data output into a standup note. This distinguishes it cleanly from the siblings get_standup_data and post_standup_note without the agent needing to open any 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?

Explicitly says to call it once before writing the first note and that the rules do not change between calls, which tells the agent when to invoke it and when not to repeat it. It does not explicitly name the alternative tools for other workflow steps, so it falls just short of full when/when-not/alternatives coverage.

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?

Goes well beyond annotations: credentials come from the environment or a gh/glab session and never from an argument, failures (rejected token, refused resource, rate limit) surface the host's own message after two retries on transient server errors, and a blocker whose log could not be read is still returned with job: "unknown" so failures are never silently dropped. This is exactly the operational context an agent cannot get from readOnlyHint/openWorldHint.

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-loads what it collects and returns, then usage, then behavior; each sentence carries information. The return-shape enumeration is long, but it substitutes for a missing output schema, so it largely earns its space.

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 supplies the return structure, and it covers auth sourcing, retry policy, error surfacing, and degraded-output behavior. Nothing an agent needs to call this correctly appears to be 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 100%, and each of host/lang/provider is fully documented in the schema, including auto-detection order and enum values. The description adds only the tangential note that credentials are not a parameter, so baseline 3 is 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?

States a specific verb and resource (collect merge-request standup data from GitLab/GitHub) and enumerates the returned buckets (today, myMrs ready/blocked/draft/stale, reviews, blockers). This clearly separates it from the sibling post_standup_note, which writes rather than reads.

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?

Gives an explicit when ('Call it once at the start of a working day, to write a standup note') and explicit when-not ('it cannot fetch one named merge request, reach further back than the previous working day, or filter by project'). The boundaries of the tool are stated rather than 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?

Annotations already declare the mutation/open-world/non-idempotent profile, but the description adds real context on top: the message is publicly visible, the webhook URL is a credential read from STANDUP_WEBHOOK_URL and deliberately not an argument, host-based payload inference, and that failures surface as errors rather than silent success. Only rate limits or partial-failure semantics are left unstated.

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 safety-critical side effect is front-loaded in the first sentence, which is exactly right. The second paragraph is dense with parentheticals about Mattermost/Rocket.Chat and proxy hosts, but each clause carries real operational information, so nothing is wasted — only mildly over-packed.

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 two-parameter mutation tool with no output schema, the description covers consent, credential sourcing, payload-shape inference, and the failure mode. Nothing an agent needs to call this correctly is missing, and return-format detail is unnecessary since there is no 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 coverage is 100%, so the baseline is 3, but the description adds the non-obvious semantic that the webhook endpoint is not a parameter at all and comes from an environment variable, plus the rationale for `kind` being optional. That is genuine meaning beyond the schema text.

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 ('Posts a finished standup note to a chat webhook') and implicitly contrasts with sibling get_standup_data by telling the agent to send the written note rather than its raw JSON. An agent can tell this is the outbound/send step of the workflow 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?

Gives an explicit permission gate ('only call it on a note the user has agreed to send') and an explicit conditional for the one optional parameter ('pass it only when the host is not recognisable'). The when-to-use and when-not-to-use conditions are both stated rather than left to inference.

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