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

Annotations already declare readOnly, idempotent, non-destructive behavior, so the description is not required to cover safety. It adds real behavioral context beyond that: a three-state result model ('unknown vs not_met') and a warning not to read checklist_complete as launch approval. That interpretation guidance is valuable and not derivable from the structured fields.

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, front-loaded with the capability and followed by the key semantic caveat. Nothing is wasted, though the phrasing is terse enough that a little more structure could have been added without padding.

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 the safety profile. The description supplies the critical interpretation caveat about checklist_complete; the only real omission is parameter meaning, which is scored separately.

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 required parameter integration_id has 0% schema description coverage, so the description must compensate and largely does not. 'per app/platform' hints at scoping but never explains what an integration_id is or where it comes from, leaving the one input undocumented.

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 ('Check six scoped requirements per app/platform'), which tells an agent exactly what the tool returns. It does not explicitly differentiate from siblings, but the sibling set (draft_ticket, triage_issue, etc.) is functionally distinct enough that this is a minor gap.

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 clarifies how to interpret the result ('checklist_complete means only this project's checklist; it is not launch approval'), which is a genuine usage caveat. However, there is no guidance on when to call this versus alternatives or what prerequisites exist, so usage is only implied.

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 readOnly/idempotent/non-destructive, and the description adds real substance beyond them: it will not send or mutate contact history, and it defines the output contract that a host may reword the text but must preserve uncertainties and source references. That is a genuine behavioral constraint an agent needs to respect.

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 no filler, and the core purpose plus the negative constraint are front-loaded. The split into two paragraphs is slightly awkward for such a brief definition but nothing is wasted.

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 the behavioral constraints are covered. The remaining gap is the required integration_id, undocumented in both schema and description, which leaves the caller guessing what evidence source to bind.

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. 'Bilingual' loosely signals that a language choice exists (matching the lang enum), but the required 'integration_id' is never explained and no format, source, or selection guidance for lang is given.

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 ('Prepare') and resource ('evidence-bound bilingual template'), so the agent knows it produces a draft artifact rather than sending anything. However it never names 'follow-up' explicitly nor distinguishes itself from the sibling draft_ticket, so an agent cannot tell the two drafts apart from the text alone.

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?

'Does not send or update contact history' implicitly scopes usage to a preparation-only step, and the name suggests drafting a follow-up. But it never says when to prefer this over draft_ticket, validate_draft, or triage_issue, nor any prerequisite or ordering 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. 'Does not submit' adds a useful drafting semantic that reinforces the non-write nature, and 'expose absent fields' hints at the response shape, but neither goes far beyond the annotations.

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 clauses with the purpose front-loaded and the non-submit constraint attached. Efficient, though 'expose absent fields' is slightly cryptic and could be clearer or dropped.

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 low-complexity surface (one param, read-only) plus an existing output schema means return values need not be explained. Still, the definition leaves the draft-vs-followup-vs-validate routing and the meaning of issue_id unaddressed, so it is only minimally 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 0% and the single parameter issue_id is never named or explained. 'From a recorded issue' only loosely implies the parameter refers to an existing issue, adding minimal meaning beyond the schema 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?

The description gives a specific verb+resource combo ('Prepare a technical handoff from a recorded issue') and even hints at output ('expose absent fields'). However it never distinguishes itself from siblings like draft_followup or validate_draft, so an agent can't reliably route to it over those alternatives.

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 and no alternative named. 'Does not submit' implies a drafting-vs-submitting distinction, but no submit tool exists among the siblings, so the agent is left to infer its place in the workflow.

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 read-only, idempotent, non-destructive, closed-world behavior, yet the description adds genuinely new traits: the output is a fixed snapshot, counts are de-duplicated per distinct account/integration, and nothing is logged or submitted. The only missing behavioral note is what the fixed snapshot's recency/window is.

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, zero filler, with the core action stated first and the constraints/non-goals following. Every clause ('fixed snapshot', 'counts distinct accounts and integrations separately', 'does not log or submit feedback') carries distinct decision-relevant 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-value shape needn't be explained, and the description adequately covers scope, determinism, non-goals, and side-effect absence for a simple read-only aggregate. The one real hole is the unexplained 'include_live' parameter, which is enough to keep it short of 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 0% and the description never mentions the single parameter 'include_live', nor what toggling it does (e.g. whether it mixes live data into an otherwise fixed snapshot). A one-parameter tool with an undocumented, non-obvious boolean leaves the agent guessing at invocation, so the description fails to compensate for the coverage gap.

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 concrete verb and object: 'Aggregate recurring checklist gaps and failures into Product review questions.' It also implies scope ('counts distinct accounts and integrations separately'), so an agent can tell it is an analytical summary rather than a listing or triage tool. It never names a sibling tool, so differentiation is inferential rather than explicit.

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?

Negative routing exists ('Not a trend, defect diagnosis or model-generated clustering', 'Does not log or submit feedback'), which rules out several plausible misuses and implies this is for snapshot-style review question generation. However, it never says when to reach for this over triage_issue, draft_ticket, or get_account_context, so usage is only implied.

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 readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds the scope of what is read (integrations, issues, attributed synthetic evidence), which is genuinely useful beyond the annotations. It does not disclose volume, pagination, or auth requirements, but with an output schema present the return shape is handled 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?

A single compact sentence with the verb front-loaded and zero filler. The comma-separated resource list is slightly dense but every element 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?

The tool has a full output schema and strong annotations, so the description does not need to explain returns or safety. What it lacks is positioning among the seven siblings, leaving the agent without guidance on sequencing. Adequate but with a clear gap for a context-priming read 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 single parameter account_id carries no description in either place. The description mentions 'for an account' but never explains the identifier's form (ID vs name, source system). With only one parameter the burden is light, but the definition still does not compensate for the coverage gap.

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 clear verb ('Read') and a specific resource set: app/platform integrations, issues, and attributed synthetic evidence for an account. This distinguishes it from list_accounts (which enumerates accounts) and triage_issue, though it does not explicitly name any sibling. Purpose is understandable 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?

No when-to-use or when-not-to-use guidance, and no alternatives are named despite a crowded sibling set (check_readiness, triage_issue, friction_digest). Usage is only weakly implied by the resource list. An agent must guess whether this is a first-step context gatherer or a follow-up to something else.

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 substantial behavior beyond the readOnly/idempotent annotations: fixed synthetic snapshot, as_of recalculates elapsed time from the same dataset without refreshing records, generated drafts are never contacts, and missing contact history is explicitly unknown. These are non-obvious rules an agent could not infer from annotations or schema.

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 is front-loaded in the first sentence and each subsequent sentence carries a distinct rule. Some fragments are telegraphic, but none are redundant with the schema or annotations.

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 the filtering, default, and edge-case rules are well covered. The remaining gap is the meaning of stale_days relative to the 'contact threshold'.

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%, so the description must compensate, and it does for two of three params: as_of semantics (null/omitted = snapshot, later value recalculates, empty strings invalid) and include_live's default exclusion of live accounts. stale_days is only obliquely referenced via 'contact threshold', leaving the threshold value itself unexplained.

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 scope: find accounts past a contact threshold, ranked by planned launch date. This is enough for an agent to distinguish it from get_account_context, which plainly retrieves one account's context, though the description never names a sibling 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?

Gives conditions (live accounts excluded by default, omit as_of for the snapshot) but never states when to choose this over get_account_context or check_readiness. Usage is implied by the filtering semantics rather than routed.

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 readOnly, idempotent, closed-world and non-destructive, and the description adds substantive behavioural context beyond them: it is a lexical (not semantic) baseline, negation and paraphrases can cause failures, and it returns candidates rather than a confirmed root cause. That sets accurate expectations about reliability and output nature.

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?

Four short sentences, each earning its place: scope, input requirement, alternative routes, and known limitations. The most decision-critical content (what it returns and what it does not) is front-loaded and there is no 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?

An output schema exists, so return values need not be spelled out, and the description still usefully summarises the candidate-level output. Input semantics, limitations and alternative tools are covered; the only gap is the undocumented optional integration_id parameter.

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 carries the burden. It does explain issue_text richly (customer prose vs issue ID), but integration_id is never mentioned, leaving half the parameters undocumented anywhere. Partial compensation for the coverage gap.

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 with narrow scope: retrieve candidate checks for blank Offerwall or reward callbacks. It also distinguishes itself from neighbours by describing what it returns (candidate categories, questions, sources) versus a confirmed diagnosis. The term "checks" is slightly abstract, so it falls just short of a fully self-explanatory purpose.

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 states the input precondition (issue_text must be customer prose, not an issue ID) and names the alternative routes for a recorded issue: get_account_context or draft_ticket(issue_id). This is precisely the when-to-use / when-not-to-use routing an agent needs to avoid calling it with a wrong identifier.

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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world). The description adds a genuinely useful behavioral caveat that annotations cannot convey: passing the lint does not certify factual or semantic correctness. That manages agent expectations about the check's limits, which is exactly the added value this dimension rewards.

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 with no filler, and the core action leads. The terseness borders on cryptic — 'narrow promise patterns' is never unpacked — so it pays a small clarity cost for its brevity.

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 explained. For a single-parameter lint tool that is mostly sufficient, but the description omits the calling context (when in a workflow to validate, what a flag means in practice) that an agent would want.

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 the single 'text' parameter, so the description must carry the load. It implies the input is draft text to be linted, which is inferable, but it gives no format, length, or content requirements. Minimal compensation for a low-documentation 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 gives a specific verb ('Lint') and target ('narrow promise patterns'), which is more than a restatement of the name. However, 'narrow promise patterns' is undefined jargon, and the description never says it operates on the draft's text or how it relates to draft_ticket/draft_followup. An agent gets a rough sense of the function but not a crisp one.

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 statement of when to call this versus the sibling drafting tools, nor any prerequisites. The second sentence only clarifies how to interpret a clean result, which is a scope caveat rather than usage routing. Guidance is essentially absent.

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