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 one genuinely valuable behavior: the label is created if it does not exist. It still omits whether labels are additive or replace existing ones, permission/scope requirements, the 500-message cap behavior, and what the call returns (no output schema exists to cover that).

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 core action front-loaded and the side effect (auto-creation) immediately after. Every clause 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?

For a two-parameter mutation with no annotations and no output schema, the description covers the action and the auto-create side effect but leaves the agent guessing about mutability semantics (additive vs. replacing), auth scope, and the return value. Adequate but with real gaps given the absence of structured behavioral metadata.

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%, so both parameters are already documented in the schema; baseline is 3. The description adds only example label values ('Newsletters', 'Receipts', 'To Review'), which reinforces the label-name format but adds no constraint or semantics beyond the 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 states a specific verb and resource ('Apply a label to the given messages') and adds the non-obvious auto-creation behavior. It does not differentiate from the specialized sibling operations (gmail_star, gmail_archive, gmail_mark_read), which are all label-style mutations, so an agent gets no help choosing between the generic and the specialized tools.

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 clearly by the verb and the mention of example labels, so an agent can infer when to reach for it. However, there is no explicit when-to-use statement, no exclusion, and no mention of the specialized siblings that might be preferable for system labels.

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 provided, the description carries the full burden and does disclose the two most consequential traits: the operation is non-destructive ("kept, never deleted") and it works by inbox-label removal. It omits permission/auth requirements, batching limits, and whether the change is reversible, which would matter for a bulk mutation.

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, no filler, with the core action and the safety guarantee front-loaded before the usage guidance. Every sentence 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?

For a single-parameter, no-output-schema tool this is nearly complete: action, mechanism, and non-destructiveness are all covered. Minor gaps remain around bulk behavior (up to 500 ids) and authorization context, which the absence of annotations leaves unaddressed.

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 the single `ids` parameter is documented there, including the 1-500 bounds. The description adds no format or constraint detail beyond the schema, so the 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?

States a precise verb (archive) plus the mechanism (removing the INBOX label), which is exactly the operation that separates it from siblings like gmail_apply_label and gmail_mark_read. An agent can tell what this does and how it differs from label/star/read tools 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?

"Use for newsletters, promotions, notifications and other noise after triage" gives clear, actionable context for when this tool is appropriate. It does not name an alternative (e.g., delete or apply_label) or state exclusions, so it stops short of full routing 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?

No annotations are supplied, so the description carries the full burden. It discloses the safe-read nature implicitly via 'Fetch', the ordering guarantee (newest first), and — most usefully — that the payload is deliberately partial (metadata + snippet, not full bodies), which tells the agent what it will and won't see. It stops short of stating read-only status explicitly, permission/auth requirements, rate limits, or how results behave when more than maxResults match, leaving some gaps for a no-annotation 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?

Three sentences, zero filler, and the highest-value information (what it returns and its scope vs. gmail_get_message) is front-loaded. Each sentence changes how an agent would use the tool.

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 enumerating the returned fields (id, from, subject, date, snippet, labelIds, attachment flag). What's missing is behavior when the result set exceeds maxResults (pagination/truncation) and how hours and query combine, but for a triage-oriented reader the definition is nearly self-sufficient.

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% — hours, query, and maxResults all carry their own descriptions and bounds — so the schema already does the heavy lifting and 3 is the correct baseline. The description adds only the 'newest first' ordering constraint, which is not attached to any specific parameter.

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 (fetch) and resource (recent Gmail messages) plus the payload shape (metadata + snippet, newest first) and the intent (triage). It also distinguishes itself from the sibling gmail_get_message by naming the escalation condition, so an agent can pick between them without opening either 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 scopes itself to triage and names the alternative ('Use gmail_get_message when the snippet is not enough to judge a message'), giving both the when-to-use and the when-to-escalate condition. This is the exact kind of routing guidance the dimension rewards.

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?

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that the body is returned already decoded, but says nothing about side effects (does reading mark the message as read?), auth requirements, rate limits, or what else is returned besides the body — notable given siblings like gmail_mark_read imply state-changing operations 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?

Two short sentences, fully front-loaded: the core action first, the routing guidance second. Nothing is redundant with the schema or the title.

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?

There is no output schema and no annotations, so the description must carry more than it does. It mentions the decoded body and implies truncation, but never describes the shape of the response (headers, metadata, attachments) or any state side effect, leaving gaps for an agent that needs to know what it will actually receive.

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%, so both parameters (id, maxChars with default and bounds) are already fully documented in the schema. The description adds no syntax or constraint detail beyond what's there, which is the expected baseline when 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 ('Fetch a single Gmail message') and adds a meaningful qualifier ('with its decoded body text') that tells the agent no further decoding is needed. The second sentence separates it from the list-style sibling gmail_fetch_recent, so an agent can route between the two 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?

Gives clear selection context: use it after gmail_fetch_recent when a snippet is insufficient to decide what to do, which names the alternative and the trigger condition. It stops short of stating explicit exclusions or prerequisites (e.g. that the id must come from that fetch, or when the full body is unnecessary).

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?

No annotations are provided, so the description carries the full burden. It usefully discloses that both system and custom labels are returned and that ids are included, but says nothing about ordering, pagination, or auth requirements. Low risk for a list operation, hence mid-range rather than low.

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 short sentence with the scope qualifier front-loaded and zero filler. 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?

For a no-argument, no-output-schema read tool, the description is nearly sufficient: it names the resource, the scope, and the key returned field (ids). Only edge details such as ordering or pagination are absent, which is acceptable given the simplicity.

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?

Zero parameters, so the baseline is 4. There is no argument surface to document and the description correctly adds nothing spurious about inputs.

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 Gmail labels) plus scope (system and custom) and return content (ids). It is trivially distinguishable from siblings like gmail_apply_label or gmail_get_message, which operate on messages rather than enumerating labels.

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 explicit when-to-use, prerequisites, or named alternatives. For a zero-parameter enumeration tool the usage is strongly implied (fetch label ids before labeling), but the description leaves that inference to the agent.

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. It usefully discloses the underlying mechanism (UNREAD label removal) rather than just restating 'mark read', which is real added value. However it omits relevant behavioral context for a mutation: required Gmail modify scope, idempotency/repeat-safety, and the 500-id batch ceiling.

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 short, front-loaded sentence with zero filler; every word earns its place. It is arguably under-specified rather than padded, which is a completeness issue rather than a conciseness one.

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 simple single-parameter mutation with no output schema, the description is minimally adequate, but with no annotations and no output schema it should at least note permission requirements or that the operation is idempotent. Nothing an agent needs to call it is strictly missing, but the safety context is thin.

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 a single well-documented 'ids' parameter, so the baseline is 3. The description's 'given messages' adds no format, ordering, or batching detail beyond the schema's own 'Message ids to mark as read.'

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 operation (remove the UNREAD label) applied to a specific resource (given messages), and the Gmail label mechanic distinguishes it from gmail_apply_label or gmail_archive. It does not explicitly name a sibling or state why one would choose this over gmail_apply_label with the UNREAD label id, so it falls short of a 5.

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 versus gmail_apply_label (which could achieve the same label removal) or when it is inappropriate. The agent must infer the intended context from the tool name 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?

No annotations are provided, so the description carries the full behavioral burden. "Add" implies a Gmail state mutation, but there is no mention of idempotency (re-starring an already-starred message), permission/scope requirements, how invalid ids are handled, or that the change is reversible via unstar. That is a real gap for a write operation with zero annotation coverage.

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 waste, with the action front-loaded before the usage hint. Every clause 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?

For a trivial one-parameter tool the essentials (what it does, when to use it) are present. But with no annotations and no output schema, an agent still lacks confirmation of the mutation's safety profile and idempotency, so it is adequate rather than 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?

With schema description coverage at 100% and a single well-documented `ids` array (including maxItems 500 and minItems 1), the schema already does the heavy lifting. The description adds only "given messages," which reiterates rather than extends the schema, so the 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?

States a specific verb and resource (adding the STARRED label to messages) that an agent can act on immediately. However, it never distinguishes itself from the sibling gmail_apply_label, which can plausibly achieve the same effect via the STARRED label, so the boundary between the two is left implicit.

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 for urgent or action-needed mail" gives a usage scenario, which is more than nothing. But it offers no alternatives or exclusions — notably it never says to prefer gmail_apply_label (or vice versa) when a generic label operation would do, leaving the choice 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 burden. It usefully discloses mrkdwn formatting support and the default-channel fallback behavior, but says nothing about auth requirements, rate limits, whether messages can be edited/deleted after posting, or what happens on delivery failure.

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, each earning its place: purpose and targeting first, formatting second, default behavior last. No filler or restatement of the tool name.

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 write tool with no annotations and no output schema, the description covers purpose, formatting, and targeting adequately, but omits the return shape (e.g., whether a message timestamp/id comes back) and permission expectations, which are the remaining gaps an agent would want closed.

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 already 100%, so the baseline is 3. The description goes slightly beyond the schema by disclosing the omitted-channel fallback to SLACK_DEFAULT_CHANNEL, a behavior the schema does not state, and restates the mrkdwn formatting allowance that also appears in the text parameter description.

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 ('Post a message to a Slack channel') and extends it to the DM case via user id, which the name alone doesn't convey. It is trivially distinguishable from the sibling set, which is entirely Gmail-based, so an agent can route between them immediately.

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 by the name and the description confirms the DM-vs-channel targeting, plus the default-channel fallback. However, there is no explicit when-to-use/when-not guidance, no mention of alternatives for richer Slack actions, and no prerequisites such as required scopes.

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