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

Annotations only declare readOnlyHint and openWorldHint; the description adds substantial context beyond them: PII is stripped (emails/phones removed, requester shortened to first name + last initial), user-authored content is wrapped in <ticket_text> tags and must be treated as data not instructions, and a nonexistent ticket returns a readable error rather than throwing. The prompt-injection warning is especially valuable for an open-world read 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?

Four short sentences, each earning its place: returned fields first, then the use case, then the safety contract, then the failure mode. The field enumeration is dense but necessary because there is no output schema, and nothing is repeated from the annotations or input schema.

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 correctly compensates by listing return contents, and it covers redaction, injection safety, and error behavior. The one gap is scope/volume: "every comment" may be large, and there is no mention of truncation, pagination, or size limits on long conversations.

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 only one parameter and schema description coverage is 100% ("The Atera ticket number, e.g. 2043"), so the schema already carries the full burden. The description adds no additional semantics about the ticket_id beyond what the schema states, which makes the baseline 3 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?

The description opens with a specific verb+resource ("One ticket's details and full conversation") and enumerates exactly what is returned: site, status, priority, requester, technician, urgency with reasons, and all comments. This clearly separates it from aggregate siblings like morning_brief or triage_queue, though it never names those siblings 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?

"Use this to summarize a ticket or draft a reply" gives a downstream task context, which implies when to reach for it. However, with six siblings in the toolkit, it offers no selection guidance, no "when not to use," and no prerequisites (e.g., needing a ticket_id from another tool first).

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 and openWorldHint=true, so the safety profile is covered. The description adds genuine behavioural detail beyond that: exactly what aggregates come back (open/critical/waiting-on-IT counts, top three tickets with rationale, device totals and worst offline site, alert counts by severity). It stops short of noting any freshness/caching or cost considerations, but with no output schema this return description carries most of the load.

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 paragraphs: purpose and routing first, return contract second. Every sentence carries distinct information, and the 'use this first' instruction is front-loaded ahead of the sibling pointers.

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?

Although there is no output schema, the description enumerates the returned aggregates precisely enough for an agent to know what it will get and when to escalate to the detail tools. For a zero-parameter read-only summary tool this is 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; it correctly avoids inventing any. The baseline for a no-parameter tool applies, and the description spends its words instead on output shape, which is the right trade-off.

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 ('start-of-day summary of the whole help desk in one call') and explicitly scopes it as an aggregate rather than a list. It names the sibling tools that give the per-item detail, so an agent can distinguish it from triage_queue, site_health and open_alerts 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?

Gives explicit when-to-use triggers ('Use this first when the user asks "what needs me?"...') and names three alternatives for when the full lists are needed. Both the selection and the exclusion conditions are stated.

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 and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the sort order (most severe first, newest within a severity) and the exact return payload (total count plus list with id, severity, title, machine, site, creation time). It stops short of stating that results are truncated by limit or what happens when there are no alerts.

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, front-loaded with scope and examples, then ordering, then return shape. Every clause carries information an agent needs; the field enumeration earns its place because no output schema exists.

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 correctly compensates by naming the returned fields and total count. Filtering, limits and defaults are covered by a fully documented two-parameter schema, and both ordering dimensions are stated, so an agent has everything needed to call and interpret this read-only 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 100%, with both 'limit' (1-100, default 25) and 'severity' (enum plus null for all) fully documented in the schema. The description adds nothing parameter-specific; 'most severe first' loosely hints at severity ordering but not at how filtering behaves. 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 resource (active/unarchived Atera monitoring alerts) with concrete examples (low disk space, failed backups, machines offline) and defines the exact ordering semantics. None of the siblings (morning_brief, triage_queue, get_ticket, site_health, technician_workload) is an alert-listing tool, so there is no ambiguity to resolve.

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: the tool surfaces active alerts, which an agent can infer is for monitoring/incident triage. There is no explicit when-to-use statement, no mention of when to prefer a sibling like triage_queue or site_health, and no note that archived alerts are excluded except through the '(unarchived)' parenthetical.

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 and openWorldHint=true, so safety is covered. The description adds real behavioral value by disclosing the ordering rules (longest offline first, sites with most offline devices first) and the shape of what comes back, but says nothing about volume, pagination, or freshness of the underlying data.

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 and returned fields are front-loaded in the first clause, followed by ordering rules and then usage triggers. There is no filler, though the single long opening sentence packs several distinct ideas together where a short break would read faster.

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 one optional parameter and no output schema, the description carries the return-value burden itself and does so: it lists the metrics, the per-machine detail, and the sort order. Nothing an agent needs to call this correctly or interpret the result 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 coverage is 100% and the schema already explains the case-insensitive substring match with a concrete example, so the description need not repeat it. The description's only related signal is 'check one site before a visit', which does not add syntax or semantics beyond the schema; baseline 3 applies.

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 ('Device health per site (Atera customer)') and enumerates exactly what is reported: total devices, online count, and each offline machine with last-seen age. This is clearly distinct from the ticket-, alert-, and workload-oriented siblings, so an agent can route to it 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?

It gives concrete when-to-use triggers ('which store has machines down?' and 'check one site before a visit'), which is stronger than most definitions. It stops short of explicit exclusions or naming an alternative sibling (e.g. open_alerts for alert-driven triage), so it is not a full 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?

Annotations only declare readOnlyHint and openWorldHint; the description adds the substantive behavior an agent needs — sort order (busiest first), the exact overloaded threshold, per-technician field contents, and that unassigned tickets appear in a separate urgency-labeled section. It also discloses the core computation (1.5x team average), which cannot be inferred from any structured field.

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 purpose and use cases, then the return contents, then sort order and the unassigned case — a logical progression with no filler. The quoted example phrasings and the parenthetical threshold are dense but each earns its place; a slightly tighter sentence structure would push this to 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 return-value burden well, enumerating each per-technician field and the separate unassigned section. The remaining gap is scope: it doesn't say whether tickets are all-time or current open state only, nor how it relates to the sibling triage/queue tools, which matters for an openWorld data source.

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 tool takes no parameters, so the schema carries no semantics to supplement and the baseline of 4 applies. Nothing in the description is needed to explain inputs, and it correctly avoids describing nonexistent ones.

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 resource and metric set: open tickets per technician, including counts waiting on IT, critical counts, oldest ticket, and an overloaded flag. The definition of the overloaded flag (3+ open and 1.5x team average) and the handling of unassigned tickets make the scope unambiguous and distinguishable from a plain ticket list.

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?

Names concrete scenarios that select it — "who's overloaded?", "who should take this?", team check-in — which gives an agent a clear trigger. It stops short of naming siblings (triage_queue, open_alerts) or stating when not to use it, so routing versus alternatives is inferred rather than explicit.

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 only declare readOnlyHint and openWorldHint; the description goes well beyond them with ranking semantics, the four level definitions, the explicit reasons tickets surface, and the deduplication rule ('same title from the same requester are folded into one'). It also discloses the return payload ('total count and the ranked tickets'), which is essential given there is no output 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?

Front-loads the core purpose in the first sentence, then the level taxonomy, then the dedup rule and return value. The level enumeration is long but each definition earns its place by explaining ranking. Slight room to trim the illustrative reason 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?

With no output schema, the description still tells the agent what comes back (total count plus ranked tickets with reasons) and what the urgency levels mean. Combined with 100% schema coverage for the two optional parameters, an agent has everything needed to call this correctly on the first try.

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 schema already explains both the site substring match and the 1-100 limit range. The description adds only a light gloss by framing site as 'one store's queue,' which is mild added meaning rather than new syntax or behavior. Baseline 3 is appropriate since the schema does the heavy lifting.

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 in the first clause: 'Open and pending tickets ranked by urgency, most urgent first,' and even describes what each row contains ('plain reasons such as ...'). It is clearly separable from siblings like get_ticket and morning_brief, which do not return a ranked working queue.

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 concrete usage context ('decide what to work on next, or to see one store's queue') and explicitly routes to a sibling for a different need ('call get_ticket for a ticket's conversation'). It does not contrast against morning_brief, open_alerts, or site_health, so the alternative-selection guidance is clear but not exhaustive.

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