Higgs Hub

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the mutation/safety profile is covered. The description adds nothing on top: it doesn't say what happens if a tab with the same title already exists, where the new tab is positioned, or whether the workbook is returned.

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 front-loaded sentence with no filler, and the scope qualifier ('existing workbook') lands immediately. It is efficient, though its brevity is partly the source of the missing detail rather than pure conciseness.

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 three-required-parameter mutation tool with no output schema and only one-third of parameters documented, the description is too thin. It omits the mailbox/workbook scoping requirements and any mention of the sibling Google Sheets equivalent.

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 only 33% — just the mailbox parameter is documented, and even that only points at list_authorized_mailboxes. The description does not explain what 'title' controls (tab name, uniqueness constraints) or how 'workbookId' is obtained, so it fails to compensate for the low 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 ('Add') and resource ('a new worksheet tab') scoped to 'an existing workbook', so the operation is unambiguous. However, it never distinguishes itself from the near-identical sibling add_google_sheet_tab, leaving the agent to infer the Excel-vs-Google-Sheets split from the tool name 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?

There is no guidance on when to use this versus add_google_sheet_tab, nor any prerequisite about the workbook needing to already exist beyond the phrase 'existing workbook'. No exclusions or alternatives are named.

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=false, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds nothing beyond the annotations: it doesn't say what happens when a tab with the same title already exists, whether the tab is created empty or active, or what the response contains.

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 front-loaded sentence with no filler; the verb and resource lead. It is efficient, though its brevity is also the source of the missing detail elsewhere.

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 mutation tool with no output schema and 67% of parameters undocumented, the description is too thin. It omits the mailbox scoping requirement, collision behavior for the tab title, and any return expectation, so an agent cannot call it fully confidently.

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 only 33% – only 'mailbox' is documented. The description explains none of the three parameters, leaving 'spreadsheetId' and 'title' semantics (target spreadsheet, tab name) undocumented in both places, so it fails to compensate for the low 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 names a specific verb ('Add') and resource ('a new worksheet tab to an existing spreadsheet'), which is unambiguous. It clearly reads as the Google Sheets variant distinct from add_excel_sheet, though it does not explicitly name that sibling.

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 when-to-use guidance, no prerequisites, and no mention of alternatives such as create_google_spreadsheet or add_excel_sheet. The agent gets a purpose but no routing logic.

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 declare non-read-only, non-destructive, but say nothing about type coercion. The description discloses a genuinely useful behavior: values parse as if typed, a leading "=" becomes a live formula, and there is no raw-text escape hatch. That is real context beyond the annotations, though it omits error/permission behavior.

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, front-loaded with the core append behavior and no wasted preamble. Slight redundancy: the first and third sentences both restate that values are interpreted as typed.

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 mutation tool with no output schema and two undocumented parameters, the description covers value interpretation well but is silent on what happens on failure, whether the target sheet must exist, and what the call returns. Adequate but with clear gaps.

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 50% (workbookId and sheet are undocumented), and the description adds meaning only about how values are interpreted rather than clarifying the undocumented parameters. The value-interpretation detail is helpful but 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?

"Add rows after the last row holding data" states a specific verb (add/append), resource (worksheet rows), and a precise insertion point, which implicitly separates it from overwrite-style siblings like update_excel_range. It stops short of naming an alternative sibling explicitly, so an agent must still infer the contrast.

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 usual way to add records to a tracker" gives implied usage context for appending records. There are no explicit when-not conditions or named alternatives (e.g. use update_excel_range when you want to overwrite an existing range), leaving routing 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 non-read-only, non-destructive, closed-world profile, so the description goes further by disclosing the value-coercion behavior: numbers and dates parse and a leading '=' becomes a live formula. That is genuine behavioral context beyond structured data, though the response shape (rows appended, range written) is not mentioned.

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 sentences with zero filler; the core append semantics come first and the value-interpretation caveat follows. Every clause carries actionable 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?

For a 5-parameter mutation tool with no output schema, the definition covers placement, value interpretation, and the RAW escape hatch, and the mailbox parameter routes to list_authorized_mailboxes. Only the result payload and the fact that pre-existing rows are untouched are left implicit.

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 60% and the valueInput enum has no schema description, but the description compensates by explaining that values are parsed as if typed and that RAW stores text exactly as given — meaningful semantics the schema omits. The undocumented spreadsheetId is largely self-evident, and mailbox/range are covered in 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?

States a specific verb and resource with positional semantics ('add rows after the last row that holds data'), which cleanly separates it from the overwriting update_google_sheet_range sibling. It never names the alternative tool outright, so an agent must infer the append-vs-update distinction.

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 usual way to add records to a tracker' implies the intended use case, and the value-input guidance hints at the RAW alternative. However, no sibling tool is named and no explicit when-not-to-use condition (e.g., use update_google_sheet_range to modify existing cells) is given.

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=false, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond that: the 1000-message batch ceiling and the combined add/remove semantics. It does not say whether the operation is idempotent or what happens if a label ID is invalid.

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 sentences, front-loaded with the action and scale, followed by the folder-move analogy. 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 4-parameter mutation tool with 25% schema coverage and no output schema, the description covers the operational model and batch limit but leaves the mechanics of messageIds and label IDs unaddressed. Adequate as a minimum, not 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 only 25% (mailbox only), so the description must carry more weight. It explains the intent of addLabelIds/removeLabelIds qualitatively and caps messageIds scope at 1000, but adds no format or source details — e.g., where label IDs come from (list_gmail_labels) or what messageIds accepts.

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 pair (add/remove), the resource (labels), and the scope (up to 1000 messages at once). The 'Gmail's equivalent of moving messages between folders' framing also separates it from sibling label tools like create_gmail_label or rename_gmail_label.

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 operating pattern — 'add the destination label and remove INBOX (or the source label) in the same call' — which is real when-to-use guidance. It stops short of naming a sibling alternative (e.g., move_messages or update_agentmail_labels) or stating when not to use this tool.

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 flag it as a destructive, non-readOnly mutation. The description goes well beyond that, disclosing the staging workflow (a request is queued, not applied), the human approval via owner's browser and agent PIN, and the safety rule 'Never ask for or accept the PIN in chat.' This is exactly the kind of context annotations cannot carry.

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 tight sentences, front-loaded with the action, then constraints, then the owner exception, then the staging/PIN behavior. No filler and the critical safety instruction is placed last for emphasis.

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 one-request mutation with no output schema, the definition covers target selection, exclusivity, the owner edge case, and the asynchronous approval flow. Nothing needed to invoke it correctly 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%, so the baseline is 3, but the description adds meaning the schema lacks: the mutual-exclusion rule ('exactly one of member or apiKey') is not encoded in the schema, and role=null is explained as the default role. The workspace parameter's necessity condition is left to the schema 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 (move) plus the two target resource types (member by email, API key by name) and the two possible destinations (a named access role or the workspace default via role=null). An agent can distinguish this from create_access_role, rename_access_role, or set_member_workspace_role without opening 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?

Gives explicit operating constraints: 'Give exactly one of member or apiKey' and 'Owners can't be given a role', plus the role=null escape hatch. It does not explicitly name alternative tools or the precondition for choosing this over set_access_role_capability/set_member_workspace_role, so it stops just 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?

Goes well beyond the annotations (readOnlyHint=false, destructiveHint=true) by disclosing that the call only stages a request requiring out-of-band owner approval with a PIN in a browser, and by giving an explicit security instruction never to request or accept the PIN in chat. That is exactly the kind of non-obvious workflow and auth detail annotations cannot convey.

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 the action and scope, followed by the approval-flow caveat and the security rule. Every sentence earns its place with 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?

For a two-parameter mutation with no output schema, the description covers the crucial missing pieces: that the effect is deferred pending owner approval, and the PIN handling rule. Nothing an agent needs to invoke this correctly is absent.

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 (email, workspace) are already documented, including the multi-workspace note and the pointer to list_workspaces. The description adds only that the email is the invited address, which is a restatement, 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 (Cancel) and resource (a pending invitation) plus the targeting key (the invited email) and the ownership precondition. This clearly separates it from invite_member (which creates the invitation) and remove_member (which removes an existing member, not a pending invite).

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 context for use: only pending invitations, only workspaces you own, addressed by email. It stops short of explicitly naming the adjacent tools (invite_member, remove_member) or stating when this is the wrong choice, so the agent must infer the boundary.

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 destructiveHint=true and readOnlyHint=false, so the mutation profile is covered. The description adds real value beyond that by specifying exactly what survives the operation — formatting and the rows themselves — which is the key behavioral question for a 'clear' tool. It omits auth requirements, rate limits, and whether the operation is reversible.

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 tight sentences, both front-loaded: the semantic effect first, the safety requirement second. No filler, no repetition of 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?

For a destructive, no-output-schema tool the description covers effect and confirmation adequately, and the absence of return values is fine. It falls short on the three undocumented parameters, where an agent gets no help on range syntax or workbook/sheet identification.

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 only 25% — just 'mailbox' is documented — and the description adds nothing about workbookId, sheet, or range. For a destructive tool, the missing guidance on range notation (e.g. A1 style) and sheet naming is a meaningful gap that the schema does not fill.

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: 'Empty the values in a range' on an Excel workbook, which is concrete and not a restatement of the title. It does not, however, distinguish itself from the close siblings clear_google_sheet_range (other platform) or update_excel_range (overwrite vs empty), leaving that routing to the agent's inference.

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 confirmation instruction ('Ask the user to confirm before clearing anything they did not just create') is genuine usage guidance about a prerequisite step. However, it gives no when-to-use vs alternatives guidance, e.g. clear_google_sheet_range or update_excel_range, so the routing question is left 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 destructiveHint=true and readOnlyHint=false, so the description need not restate danger; instead it adds real value by specifying what is destroyed (values only) versus preserved (formatting, rows) and by adding a user-confirmation workflow. It still says nothing about reversibility or how irrecoverable the cleared data 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?

Two sentences, no waste, and the payload-preserving constraint leads ahead of the confirmation advisory. 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 destructive, 3-required-parameter mutation with no output schema, the safety and preservation semantics are covered, but two of three parameters remain unexplained (notably range format) and there is no note on failure behavior for invalid ranges or missing permissions.

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 only 33%: mailbox is documented in the schema, while range and spreadsheetId carry no description at all. The description mentions "a range" but never gives A1 notation syntax or explains where spreadsheetId comes from, e.g. list_google_spreadsheets, so it 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?

Specific verb + resource ("Empty the values in a range") with a precise scope qualifier: formatting and the rows themselves are preserved. This separates it cleanly from clear_excel_range (different platform) and update_google_sheet_range (which writes rather than blanks values).

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 a clear usage condition, namely that the range's formatting should survive, plus a when-to-be-cautious rule (confirm before clearing anything the user did not just create). It does not explicitly route to a sibling such as update_google_sheet_range or delete-oriented tools, so it stops short of a full when/when-not/alternatives statement.

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 a non-read-only but non-destructive, non-open-world mutation. The description adds one genuinely useful behavioral fact: Google sets the completion timestamp server-side, so no time value is passed. It says nothing about idempotency, whether re-completing is an error, or permission requirements.

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, front-loaded sentences with zero filler; the action comes first and the behavioral note second.

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 three-parameter mutation with no output schema, the description covers the core action and the server-side timestamp, but leaves the identity of listId/taskId and the result of the call unspecified. Adequate but with clear gaps.

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 only 33% — only 'mailbox' is documented (pointing at list_authorized_mailboxes). The description does not explain listId or taskId at all, so it fails to compensate for the undocumented parameters as the low-coverage rule requires.

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 ('Mark a task done') that an agent can map directly to the Google task object. It is reasonably distinguishable from create/delete/update_google_task, though it never explicitly names those siblings as alternatives or boundaries.

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 guidance, no prerequisites, and no routing to alternatives such as update_google_task (for un-completing) or delete_google_task. The agent must infer the usage context entirely from the name.

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?

The annotations already declare readOnlyHint=false and destructiveHint=false, so the agent knows this is a non-destructive mutation. The description adds one useful behavioral detail: completed tasks are filtered out of list_outlook_tasks by default. It omits idempotency, behavior if already completed, and permission requirements.

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 core action and followed by the most relevant side effect. No filler or redundancy.

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 mutation tool with three required parameters and no output schema, the description is too thin. It doesn't explain listId or taskId, doesn't state what success returns, and gives no guidance on alternatives or error conditions.

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 only 33%: mailbox is documented, but listId and taskId have no descriptions. The description provides no additional semantics for these parameters, leaving two required identifiers ambiguous beyond what their names imply.

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: 'Mark a task as done' on an Outlook task. This distinguishes it from siblings like delete_outlook_task or update_outlook_task, though it does not explicitly name 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?

It gives a clear use case (marking a task done) and notes that completed tasks drop out of list_outlook_tasks. However, it does not state when to use this versus delete_outlook_task or update_outlook_task, nor any prerequisites, 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 only say it is a non-destructive, non-read-only, non-open-world write. The description adds substantial behavior beyond that: the new role defaults to all eight capabilities on and full mailbox read & write, and the call is a staged request requiring out-of-band browser approval with an agent PIN. It even gives a security constraint (never request the PIN in chat).

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, all front-loaded and purposeful: purpose, defaults, follow-up tools, approval model. Nothing is wasted, though the follow-up and approval sentences are dense relative to a simple two-parameter creation call.

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 burden and does explain the staged-approval outcome, which is the important behavioral result. It does not state whether the role identifier needed by set_access_role_capability is returned, a small remaining gap for a create-then-configure workflow.

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 the two parameters (name with length bounds and example, workspace with name-or-id guidance) are already fully documented in the schema. The description adds only contextual framing ("a workspace you own") and no new syntax or format detail, 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 with scope: "Create a named access role in a workspace you own." This clearly separates it from siblings such as list_access_roles, rename_access_role, delete_access_role, and assign_access_role, all of which act on existing roles or members.

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 workflow: create first, then narrow with set_access_role_capability and set_access_role_mailbox_access, then populate with assign_access_role. It also frames the boundary of this tool (only stages a request; approval happens elsewhere), so the agent knows what this call does and does not accomplish.

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 write/non-destructive/non-open-world. The description adds real behavioral context: the message is not sent, a human reviews and sends it from the console, and it works even when sending is disabled. The reply-derivation behavior (recipients/subject inherited) is also disclosed, which is more than the annotations carry.

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 tightly packed sentences, front-loaded with the core action and constraint, then the review workflow, then the reply special case. No filler; every clause carries 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?

With no output schema, the description need not explain return values, and it covers purpose, the review guardrail, and reply behavior adequately for a 7-parameter creation tool. Minor omission: nothing about cc/bcc or confirmation of a successful draft creation, but the essentials for correct invocation are present.

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 57%, and the description compensates for the key gap by explaining replyToMessageId beyond its terse schema text: recipients and subject are derived from the original message. It does not cover cc/bcc/body, but for the highest-value parameter it adds semantics the schema 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?

States a concrete verb+resource ('Write a draft into the AgentMail inbox') and immediately scopes it with 'without sending it', which cleanly separates it from the send_agentmail_message / send_agentmail_reply siblings. It does not name a sibling explicitly, but the 'without sending' qualifier makes the distinction unmistakable.

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 a clear conditional for reply mode ('For a reply, set replyToMessageId') and implies the review workflow as the reason to draft rather than send. However, it never states when to prefer a draft over send_agentmail_message or send_agentmail_reply by name, leaving the alternative-selection 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 cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false). The description adds placement behavior (top level of drive by default) and, with no output schema present, usefully discloses the return values (id and link). It stops short of noting permissions or whether the name needs an extension.

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 with the core purpose front-loaded and zero filler. The final sentence's em-dash clause is slightly convoluted but still earns its place by flagging the conditional requirement.

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 3-param creation tool with annotations and no output schema, the description covers purpose, default placement, conditional param requirement, and return shape. Only the naming/extension convention of 'name' is left 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 coverage is 67%; the description restates the parentFolderId condition already present in the schema and adds nothing about the undocumented 'name' parameter (e.g., extension handling). Baseline 3 is appropriate since the schema carries most parameter meaning.

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+format+location: 'Create a new empty .xlsx workbook in the user's OneDrive.' An agent can distinguish it from create_google_spreadsheet (Excel vs Sheets) and create_onedrive_folder (workbook vs folder) without opening 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?

The description gives one useful precondition (parentFolderId is mandatory under limited folder access) but never states when to pick this over sibling creators such as create_google_spreadsheet. Usage is implied by the name 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 already declare this is a non-destructive, non-read-only, closed-world write, so the safety profile is covered. The description adds one genuinely useful behavioral fact — that the parent defaults to My Drive root — but says nothing about permissions required, duplicate-name handling, or what is returned.

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 front-loaded sentence with the verb and resource first and the parent-default caveat second; no filler, no redundancy.

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 create operation with annotations covering the safety profile and no output schema to explain, the description is nearly sufficient — it covers scope and the parent default. The remaining gap is the undocumented parentItemId semantics and collision behavior, which is minor for this tool's complexity.

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 only 33%: only 'mailbox' is documented in the schema, and 'parentItemId' has no description at all. The description partially compensates by explaining that the parent argument defaults to My Drive root, but 'name' and the ID format/expected values for parentItemId remain unspecified.

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 (Create) and resource (folder in Google Drive), making the operation immediately identifiable and distinguishable from the OneDrive/mail-folder siblings by the explicit Google Drive scope. It stops short of naming alternatives or contrasting conditions, so it is clear but not fully sibling-differentiating.

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 when-to-use guidance, no mention of prerequisites (e.g. that the mailbox must be authorized), and no exclusion or alternative tool. The only usage-adjacent detail is the parent default, which is a behavior note rather than selection 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=false, destructiveHint=false and openWorldHint=false, so the bar is lower, yet the description still adds real behavioral context: nothing is sent, the human completes the send, and the tool remains functional even when workspace sending is disabled. It stops short of saying where the draft lands (Drafts folder), whether it can be edited afterwards, or what is returned.

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, front-loaded with the core action and no filler. Minor redundancy: 'The person opens and sends it themselves' largely restates 'without sending it', though it does clarify the human-in-the-loop step.

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 7-parameter, 4-required mutation tool with no output schema, the description covers the key safety-relevant behavior (non-sending) but omits return information (e.g. draft identifier), where the draft is stored, and any parameter-level detail. Adequate as a minimum viable definition, incomplete for the tool's actual complexity.

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 only 29% (2 of 7 params), so the description is expected to compensate and does not — it mentions no parameter at all, not even the required mailbox/to/subject/body. Notably it never surfaces replyToMessageId's threading behavior, which is the one parameter with meaningful semantic consequence, leaving that entirely to 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?

States a specific verb+resource ('Write a draft into the mailbox') and the defining constraint 'without sending it', which implicitly separates it from send_gmail_message/send_gmail_reply. It does not, however, name or distinguish itself from the close siblings create_outlook_draft or create_agentmail_draft, so the Gmail-specific routing is left to the tool name.

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 agent must infer that this is the right tool when it wants to prepare mail for human review rather than deliver it. The line 'Works even when a workspace has switched sending off' is a genuine usage condition but is framed as a capability, not as guidance on when to pick this over send_gmail_message. No exclusions or prerequisites 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 declare a non-read-only, non-destructive, closed-world mutation, and the description adds real context beyond them: the filter lives server-side in Gmail and keeps running when the tool is not invoked, and archiving is the default outcome. It still omits whether the filter applies retroactively to existing mail or how it interacts with delete_gmail_filter.

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 sentences, front-loaded with the action and resource, followed by the one non-obvious behavioral fact (server-side persistence). No filler, nothing redundant.

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 6-parameter mutation with no output schema, the description covers purpose, default archiving, and persistence well. The main omission is that it does not state whether the new filter is applied to already-received mail, which an agent would need to set expectations 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 100%, so the baseline is 3. The description echoes the criteria dimensions (sender/subject/query) and confirms the default archive behavior already documented on the archive property, adding only marginal meaning 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 ('Create a Gmail filter') plus the behavior it produces (labels and by default archives matching mail). It is unambiguous about what the tool does, but it never differentiates itself from near-neighbors like create_inbox_rule, create_gmail_label, or list_gmail_filters, so it stops 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 when-to-use / when-not-to-use guidance and no stated prerequisites. Notably it never says a label must already exist (create_gmail_label) or that addLabelId is required, nor does it distinguish this from create_inbox_rule or other mail-organization siblings. Usage is only implied by the phrase 'incoming mail matching ... criteria'.

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=false and destructiveHint=false, so the safety profile is covered. The description usefully adds that a "/" in the name produces a nested label, but it omits duplicate-name behavior, idempotency, and the fact that creating a label does not apply it to any messages.

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 zero filler, and the core action is front-loaded ahead of the optional nesting syntax detail.

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 and annotations covering safety, the description supplies the one non-obvious input behavior (nested naming). It is nearly complete for a two-parameter creation tool, lacking only duplicate-handling guidance.

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 only 50% (mailbox is documented, name is not), so the description must compensate for the gap. It does so by defining the naming syntax for nested labels, though it adds nothing about length limits or reserved names.

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 ("Create a new Gmail label"), which cleanly separates it from rename_gmail_label, delete_gmail_label, and list_gmail_labels. It does not, however, explicitly name or contrast itself with a sibling, 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?

The creation intent is implied by the name and description, but there is no when-to-use/when-not guidance: nothing about what to do if the label already exists (find_duplicate_gmail_labels / merge_duplicate_gmail_labels exist) or the difference between creating a label and applying it via apply_gmail_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?

Annotations already declare a non-read-only, non-destructive, non-open-world write. The description adds one behavioral fact beyond them: that the created calendar is a secondary one, not the primary. It says nothing about permissions, quota limits, or whether the new calendar is immediately usable, so it is only modestly additive.

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 sentence with the action front-loaded and the rationale following a dash. No filler, no repetition of 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?

With no output schema, the description omits what the call returns — notably the new calendar's ID, which the agent would need to add events to it. Combined with 50% parameter coverage and minimal annotations, a competent but incomplete picture.

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 only 50%: mailbox and timeZone are documented in the schema, but name and description are bare. The description mentions no parameters at all, so it does not compensate for the undocumented half or clarify naming conventions for the calendar.

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 ("Create a new secondary calendar") and adds the scope qualifier "secondary," which distinguishes it from primary-calendar operations. It does not explicitly differentiate itself from the near-identical sibling create_outlook_calendar, 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?

The clause "useful for keeping a client's or project's events separate from the personal one" implies a use case but never states when to use this versus create_outlook_calendar, or that the mailbox must be authorized first. Usage is inferred rather than directed.

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 cover readOnly=false, destructive=true and openWorld=true, so the safety bar is already met, yet the description adds real side-effect context: inviting guests emails them an invitation, the reverse case notifies nobody, and addVideoMeeting creates a link without recording or joining. That is meaningful external-effect disclosure 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?

Four tight sentences, front-loaded with the core action, and each sentence carries distinct information (date formats, guest side effect, video flag). No padding or restatement of the 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 10-parameter destructive, open-world mutation with no output schema, the description covers the highest-risk behaviors (outbound invitations, video attachment). It omits where the event lands by default and any recurrence/calendarId guidance, but nothing an agent must know to call it safely 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?

With 60% schema coverage the description usefully adds the guest-notification consequence and the Meet-link behavior for addVideoMeeting, and clarifies the date-format contract for start/end. It leaves calendarId, location, timeZone and description semantics to the schema, so it compensates but does not fully cover the 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+resource ("Create an event") that distinguishes it from the nearest lookalike, create_google_calendar. It does not explicitly differentiate from the parallel create_outlook_calendar_event sibling, but the resource name makes the provider obvious.

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?

Provides conditional guidance on date formats (all-day vs timed) and implies guest behavior, but never states when to prefer this over create_outlook_calendar_event or update_google_calendar_event. Usage is inferable 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 the safety profile (non-read-only, non-destructive, closed-world), so the description carries the rest. It adds the default placement behavior (top-level Drive) and the folder-scoped-access caveat, which an agent needs before calling. It does not mention permissions/scopes required or quota considerations, so it is not exhaustive.

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 sentences, front-loaded with the core action and return values, with no filler. The em-dash clause in the second sentence is slightly convoluted but still earns its place by encoding the conditional requirement.

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 usefully states the return values (id and link), covers the required mailbox/title context implicitly, and flags the parentFolderId dependency. A note on where the spreadsheet lands relative to list_google_spreadsheets would make it fully self-contained.

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 75%, so most parameters are already documented, and the description largely restates the schema's own text (parentFolderId's folder-restricted requirement, sheetTitles as tabs). It confirms the meaning but adds no new syntax, format, or ordering nuance beyond what the schema provides.

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 ('Create a new spreadsheet in the user's Drive') plus the optional tab behavior and the returned id/link. It is unambiguous on its own, though it never explicitly contrasts itself with the adjacent create_excel_workbook / create_gdrive_folder siblings, relying on the tool name to disambiguate the Google product.

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 a concrete conditional rule: the file lands at the top level unless parentFolderId is supplied, and that parameter becomes required when mailbox access is folder-restricted. That is real when-to-use guidance, but it stops short of naming an alternative tool or an explicit when-not-to-use case.

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 cover the write/safe profile; the description adds genuinely non-obvious behavior: due time is discarded, no priority field, and how to make a subtask. This is real context beyond annotations, though it does not mention auth or error behavior.

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, each earning its place: creation, Google-specific due-date caveat, and subtask routing. Front-loaded with the core action.

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 6-param tool with a partial schema and no output schema, the description covers the key Google Tasks quirks and subtask behavior. It leaves auth/mailbox selection to the schema but is otherwise sufficient to call 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 coverage is 50%, and the description compensates by explaining dueDate time-discarding, the absence of a priority field, and parentTaskId's subtask effect. It does not mention notes or mailbox, but the mailbox schema already points to list_authorized_mailboxes.

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 (add/create) and resource (task to a list), and is distinguishable from siblings like create_outlook_task by naming Google Tasks in the title and due-date semantics. The parentTaskId note clarifies scope beyond a plain add.

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?

Implied usage by mentioning due-date handling and subtasks, but no explicit when-to-use vs create_outlook_task, update_google_task, or list_google_tasks. No prerequisites or exclusions 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?

The annotations already declare that this is a non-read-only, non-destructive, non-open-world operation. The description adds nothing beyond the bare action, saying nothing about whether the list must be unique, what happens on naming conflicts, or what the caller needs to supply.

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 description is one front-loaded sentence with no filler, which is structurally fine. But it is so terse that it omits useful context rather than being optimally concise for a two-parameter create 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?

Given two required parameters, no output schema, and a create operation, the description is under-specified. It does not mention the required mailbox context, the title parameter, or the distinction from Outlook task lists.

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 only 50%: the mailbox parameter is documented in the schema, but the required title parameter has no description. The description's phrase 'new task list' hints at a title but provides no formatting, length, or uniqueness constraints to compensate.

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 clear verb and resource: 'Create a new task list.' An agent can tell this creates a list rather than a task. However, it does not differentiate from the sibling create_outlook_task_list, relying on the tool name to convey that it is Google-specific.

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 tool instead of alternatives such as create_outlook_task_list, nor any prerequisites or exclusions. The agent must infer usage 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?

Annotations declare it is a non-read-only, non-destructive write with no open-world side effects, and the description goes beyond them by disclosing that the rule persists server-side in Exchange and keeps firing after the session ends. It omits permission requirements and any limits on rule count or duplicate names.

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 and effect front-loaded and the required-condition caveat at the end where it is easiest to act on.

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?

Covers action, persistence behavior, and the minimum-condition rule for an 8-parameter write tool; annotations already carry the safety profile and no output schema exists, so return values need not be explained. Minor gaps: no mention that the mailbox must be connected (only hinted in the schema) or of duplicate-name handling.

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 baseline is 3. The description adds a cross-parameter constraint not expressed in the schema (no anyOf/oneOf present): at least one match condition must be supplied, and it names the sender/subject/destination roles, which maps the fields to the described behavior.

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 ("Create an inbox rule") and the effect (auto-move matching mail into a folder). Saying it "Runs server-side in Exchange" implicitly separates it from the Gmail counterpart create_gmail_filter, but 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?

Adds a real prerequisite ("At least one condition is required"), which tells the agent when the call is valid. However, it never says when to prefer this over create_gmail_filter/create_mail_folder or lists the alternatives, 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 readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the mutation/safety profile is covered structurally. The description adds the nesting behavior of parentFolderId, which is useful, but says nothing about idempotency or duplicate-name handling — relevant given find_duplicate_mail_folders and merge_mail_folders 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 tight sentences with the core action first and the optional-parameter behavior second; nothing is padded and the key decision (pass or omit parentFolderId) is front-loaded.

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 low-complexity, 3-parameter mutation with no output schema, the description covers the essential call shape. It still omits the created folder's identifier/return behavior and any hint about name collisions, which an agent would need to chain a follow-up rename_mail_folder or move_messages call.

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 only 33%: only mailbox is documented in the schema. The description does compensate for parentFolderId by stating its nest-vs-top-level semantics, but displayName is left entirely undefined in both places, so the description only partially fills the 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+resource (create a mail folder) that an agent can distinguish from create_gmail_label or create_gdrive_folder. However it never names a sibling or scopes itself to Outlook/M365 mail, so differentiation relies on inference from the mailbox parameter.

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 explains the parentFolderId mechanic but gives no when-to-use guidance: it doesn't say when to create a folder vs. a Gmail label, nor mention prerequisites like calling list_authorized_mailboxes or checking for an existing folder via find_duplicate_mail_folders.

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 a non-read-only, non-destructive write, so safety is covered. The description adds a genuinely non-obvious behavioral trait beyond annotations: duplicate names are resolved with a suffix rather than merged, which prevents the agent from assuming an upsert/merge. It stops short of mentioning permission/auth requirements or error modes.

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 sentences, no filler, with the scope/default front-loaded and the collision semantics immediately after. Every clause carries information an agent needs.

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 create operation with no output schema and no annotations covering the result, the description should at least indicate that a new folder (and presumably its ID) is returned so it can be used by rename_onedrive_item / move_onedrive_item. It also omits the mailbox-authorization prerequisite. Adequate but with real gaps.

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 only 33% (only 'mailbox' is documented), so the description has to compensate. It usefully explains that 'parentItemId' is optional and defaults to the drive root, and its collision note implicitly covers 'name', but it never says how to obtain a valid parent item ID or what format it takes.

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 (Create) and resource (a folder in OneDrive), plus the scoping detail that the parent defaults to the drive root. Combined with the name, this clearly separates it from the sibling create_gdrive_folder / create_mail_folder 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?

The intent is obvious enough that usage is implied, and the collision behavior ('created with a suffix rather than merged') tells the agent what happens if the folder already exists. However, there is no explicit when-to-use vs. alternatives guidance, no prerequisite about needing an authorized mailbox, and no pointer to list_onedrive_items for resolving a parent ID.

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=false, destructiveHint=false and openWorldHint=false, so the safety profile is covered structurally. The description adds nothing beyond that – no mention of required mailbox authorization, duplicate-name behavior, or what is returned – which meets the minimum bar given 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?

A single front-loaded sentence with the action first and rationale second; nothing is wasted. Slightly more context could have been added without bloat, so it is efficient but not maximally informative.

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 two-parameter creation tool with annotations covering safety and no output schema, the description is adequate but thin. It omits the mailbox prerequisite, does not address the undocumented 'name' parameter, and does not indicate that the created calendar's identifier is likely needed for follow-up calls such as create_outlook_calendar_event.

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 only 50%: the mailbox parameter is well documented in the schema, but the required 'name' parameter has no description anywhere. The description says only "a new calendar" and never clarifies what the name parameter represents or its constraints, so it 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?

States a specific verb and resource ("Create a new calendar"), and the name makes the Outlook variant identifiable against create_google_calendar. However, it never explicitly contrasts itself with the Google or other sibling calendar tools, so an agent must rely on the name 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?

The clause "useful for keeping a client's or project's events separate from the default one" gives an implied use case, which is more than nothing. But there is no explicit when-to-use-vs-alternatives guidance and no mention of prerequisites such as needing a connected mailbox or how this differs from create_google_calendar.

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 flag destructiveHint=true and openWorldHint=true, so the safety profile is partly covered; the description adds the key hidden side effect — guests trigger external invitation emails, and an event with no guests notifies nobody. It stops short of saying what is returned or which calendar the event lands on by default.

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, action first, then side effects, then the video-meeting flag. No filler and nothing buried.

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 10-parameter mutating tool with no output schema, the description covers the notification side effect but omits the return value (does it hand back an event ID?) and defaults such as which calendar is used. It is adequate but leaves meaningful gaps.

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 60% and the description only elaborates on attendees and addVideoMeeting, both of which are already documented in the schema. Half the parameters (location, calendarId, description, title) get no added meaning from the description, so it 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 specific verb and resource ("Create an event"), which the name/title refine to Outlook Calendar. It could have named the relevant sibling (create_google_calendar_event) explicitly, but the purpose is unambiguous.

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 conditional behavior for guests (invitations sent vs. nobody notified) and when to set addVideoMeeting, which implies usage. It never states prerequisites (e.g., a connected mailbox) or when to prefer this over create_google_calendar_event or update_outlook_calendar_event.

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=false, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: the draft is not transmitted, the human sends it, and the tool still works when sending is disabled — all non-obvious operational traits.

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, front-loaded with the core action and its key constraint ('without sending'). No filler; each sentence adds distinct 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?

For a 7-parameter mutation tool with no output schema and sparse schema descriptions, the behavioral side is well covered but the parameter side is essentially absent — an agent gets no guidance on cc/bcc/to arrays or the reply-threading parameter from the description. Adequate but with a clear gap.

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 only 29% (7 params, only mailbox and replyToMessageId documented). With that low coverage the description should compensate, but it mentions no parameters at all — no hint about to/cc/bcc arrays, subject/body limits, or how replyToMessageId changes behavior. The burden is not met.

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 ('Write a draft into the mailbox') and immediately clarifies the key differentiator from send tools: 'without sending it.' An agent can tell this apart from send_outlook_message/send_outlook_reply. It does not, however, name its sibling create_gmail_draft/create_agentmail_draft as the parallel drafts, so sibling differentiation is only partial.

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 gives one useful usage condition ('Works even when a workspace has switched sending off'), which hints at when to prefer a draft over sending. But it never explicitly names the alternative (send_outlook_message) or states when-not to use this tool, leaving the routing decision largely implicit.

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 a non-read-only, non-destructive, closed-world mutation, so the safety profile is covered. The description adds nothing beyond that: no statement about prerequisite state, whether the task is immediately persisted, or how failures surface. It largely restates the schema's optional 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?

A single tight sentence with the verb and resource front-loaded and the optional fields trailing. Efficient, though the trailing enumeration duplicates what the schema already lists.

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 9-parameter creation tool with no output schema, the description omits the mailbox authorization requirement, the need for a pre-existing list, and the timezone caveat that the schema raises. An agent must open the schema to call this 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 coverage is 56% and the description only echoes the same fields already named (due date, reminder, importance, notes) without adding format or constraint meaning. It provides no semantics for undocumented parameters such as title, listId, or categories, so it 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 specific verb and resource ('Create a task in a To Do list') and enumerates the optional fields, so an agent knows exactly what operation is performed. It does not distinguish itself from close siblings like create_google_task or create_outlook_task_list, 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 when-to-use guidance, no mention that the target listId must already exist (create_outlook_task_list), and no note that the mailbox must be an authorized one. The description offers no routing help versus create_google_task or create_outlook_task_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?

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds nothing beyond that: no note on duplicate-name handling, return value, or whether the list becomes immediately visible. Minimal value beyond structured 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?

A single, front-loaded sentence with no wasted words. It is appropriately sized for a simple create operation, though it is arguably too terse given the missing guidance.

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 create tool with annotations and no output schema, the description is minimally viable, but it omits displayName semantics and any usage context. It leaves the agent without enough to handle parameters or edge cases confidently.

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 only 50%: mailbox is documented inline (including a pointer to list_authorized_mailboxes), but displayName has no description or constraints. The description does not compensate by explaining what displayName should contain or any naming rules.

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 (Create) and resource (Microsoft To Do task list), which is clear and distinguishable from create_google_task_list by provider qualifier. It does not, however, explicitly contrast with sibling operations on Outlook tasks/lists.

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 when-to-use guidance, no prerequisites (e.g., mailbox must be connected), and no mention of alternatives such as create_google_task_list or create_outlook_task. The agent must infer usage entirely from the name.

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 destructiveHint=true and readOnlyHint=false; the description goes well beyond by disclosing that this merely stages a request, that the owner must open a link, review, and approve with their agent PIN, and that the PIN must never be handled in chat. This is exactly the kind of non-obvious behavioral context the agent needs.

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 tight sentences, front-loaded with the action and its key precondition, then the safety-critical approval flow. Every sentence earns its place with 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?

For a destructive, approval-gated operation with no output schema, the description covers the precondition, the exclusion, and the full staged-approval lifecycle. Nothing an agent needs to invoke it safely 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 description coverage is 100%, so both `name` and `workspace` are already documented in the schema, and the description adds no syntax or format detail beyond that. Baseline 3 is appropriate when the schema carries the parameter burden.

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?

Specific verb+resource (delete an access role) with the added scope constraint that the role must have no followers, which immediately distinguishes it from creation/rename siblings. An agent knows exactly what this does and what state the target must be in.

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?

States the prerequisite explicitly (move members and API keys first via assign_access_role) and the exclusion (workspace default role can't be deleted), which is strong when/when-not guidance. It names a related tool for the prerequisite step but no true alternative deletion path, so it falls just short of 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 already declare destructiveHint=true, so safety is partly covered, but the description adds the crucial detail that deletion is permanent and bypasses the trash (i.e., not recoverable) plus a confirmation requirement. It does not discuss permissions/ownership constraints on shared items, so it falls short of 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?

Two short sentences with zero filler; the permanent/bypasses-trash fact is front-loaded and the confirmation instruction follows. 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 destructive two-param tool with no output schema, the description covers irreversibility and user-confirmation, which is what an agent most needs. The remaining gap is itemId semantics, which neither schema nor description addresses.

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 50%: mailbox is documented in the schema, but itemId has no description and the tool description says nothing about it. The only hint is 'file or folder', which loosely implies itemId accepts either type but adds no format or sourcing guidance beyond that.

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 (delete) and resource (Google Drive file or folder), and makes the scope explicit with 'Permanently' and '(bypasses trash)'. An agent can immediately tell this apart from recoverable-delete semantics and from sibling tools like move_gdrive_item or rename_gdrive_item.

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 a concrete operational instruction ('Ask the user to confirm before calling this') and warns that trash is bypassed, which effectively signals when-not-to-call-carelessly. It stops short of naming an alternative (e.g., a non-permanent removal path), so it is clear context rather than a full when/when-not routing rule.

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 destructiveHint=true and readOnlyHint=false, so the safety profile is covered structurally. The description adds nothing beyond that: it does not state that deletion is permanent/irreversible, nor any auth or scoping requirements. The word 'existing' is the only marginal addition.

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 front-loaded sentence with zero filler. Its brevity is efficient, though it borders on under-specification for a destructive operation.

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 destructive, 2-required-param tool with no output schema, the description omits the irreversibility warning, the means of obtaining filterId, and any distinction from other delete_* siblings. The annotations cover only the safety hint, so the description's gaps are material.

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 50%: mailbox is documented (with a pointer to list_authorized_mailboxes), but filterId — the parameter that actually selects what gets destroyed — has no schema description and no description text here. The description does nothing to compensate for this 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+resource ('Delete... Gmail auto-filing filter'), which is unambiguous. It does not differentiate from near-siblings such as delete_gmail_label, delete_inbox_rule, or delete_mail_folder, all of which are deletion tools in the same mailbox namespace.

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 guidance, no prerequisites, and no mention of the natural companion flow (list_gmail_filters to discover a filterId). The agent is left to infer that the filter must already exist and how to find it.

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 supply destructiveHint=true and readOnlyHint=false, and the description goes beyond them by defining the blast radius: the deletion is permanent, but messages are only unlabeled rather than removed. The explicit confirmation requirement is additional behavioral context. It stops short of 5 because it says nothing about reversibility of recovery beyond "permanently" or about failure modes.

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 zero filler; the destructive scope is front-loaded and the safety instruction follows immediately. Nothing is repeated from the title or 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?

For a two-parameter mutation with no output schema, the description covers the essentials: what is destroyed, what is not, and the confirmation gate. It is slightly incomplete in that it never tells the agent where labelId comes from or that the operation is scoped to a single mailbox, both of which are discoverable only from sibling tools.

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 only 50%: mailbox is described and even points to list_authorized_mailboxes, but labelId is a bare string with no description. The tool description adds nothing here — it never says whether labelId is an opaque ID or a label name, nor how to obtain a valid one (e.g., via list_gmail_labels), which is exactly the gap the 50% coverage leaves.

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 pairs a specific verb ("Permanently delete") with a specific resource ("a Gmail label") and immediately clarifies scope by noting the messages themselves survive and are only unlabeled. That scope note cleanly separates it from delete_gmail_filter, delete_mail_folder, and delete_gmail_message-style siblings.

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 one concrete procedural rule — confirm with the user first — which is real usage guidance for a destructive tool. However, it names no alternative or routing condition (e.g., rename_gmail_label for a rename, merge_duplicate_gmail_labels for consolidation), so an agent must infer when deletion is the right choice.

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 destructiveHint=true, so the bar is lower, yet the description still adds substance the annotations cannot carry: cascade behavior ('every event on it'), the hard restriction that the primary calendar is ineligible, and an explicit non-recoverability warning plus a confirmation protocol. That is exactly the pre-call context an agent needs before issuing an irreversible 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, front-loaded with what is destroyed, then the eligibility constraint, then the warning and confirmation instruction. No filler and nothing buried.

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 irreversible delete with no output schema, the description covers impact, eligibility, and the human-confirmation requirement well. The one gap is mechanical: how to obtain a valid calendarId and how the tool fails when an invalid or primary id is supplied.

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 50%: mailbox is documented and even points at list_authorized_mailboxes, while calendarId has no description at all. The description contributes indirectly by defining the target as a 'secondary calendar', but never tells the agent where to source a valid calendarId (list_google_calendars) or what happens if a primary id is passed.

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 (delete_google_calendar) plus the exact scope: only secondary calendars, and every event on the calendar goes with it. That scope statement distinguishes it from delete_google_calendar_event (single event) and from the parallel delete_outlook_calendar sibling without the schema needing to be opened.

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 a real precondition ('the primary calendar cannot be deleted') and an explicit operational instruction ('ask the user to confirm before calling this'), which is the correct routing signal for a destructive tool. It stops short of naming an alternative path (e.g., deleting events individually with delete_google_calendar_event) when the user only wants to clear the calendar.

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 destructiveHint=true and openWorldHint=true, but the description goes beyond them by disclosing that guests are emailed a cancellation and that the action cannot be undone, plus a human-confirmation requirement. That is meaningful consequence disclosure an agent cannot get from the annotations alone.

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, front-loading what is deleted, then the side effects, then the safety requirement. Every sentence earns its place with 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?

For a destructive, open-world mutation with no output schema the description covers consequences and confirmation well, but it leaves the parameter story thin (calendarId unaddressed) and gives no guidance on recurrence/occurrence identification or error cases when no guests exist.

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 only 33%: mailbox is documented in the schema (with a pointer to list_authorized_mailboxes), but eventId and calendarId carry no description anywhere. The description adds no parameter meaning — it doesn't explain how to identify an occurrence or which calendar defaults apply — so it 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?

States a precise verb+resource and even narrows the scope to 'one event or one occurrence', which tells an agent it is deleting a single calendar entry rather than a whole calendar (delete_google_calendar) or a task. It does not name an alternative sibling explicitly, so it stops 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?

Gives one clear operational rule — ask the user to confirm before calling — which is real usage guidance, but says nothing about when to prefer this over delete_outlook_calendar_event or when calendarId vs the default calendar matters. Usage context is implied rather than 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?

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description adds a valuable behavioral warning that deletion should be a last resort because completion is usually intended, going beyond the annotations, though it does not detail irreversibility, auth requirements, or side effects.

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 sentences, front-loaded with the action and immediately followed by the crucial usage warning. Every sentence earns its place with 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?

For a simple destructive mutation with annotations covering safety and no output schema, the description covers the key risk of misuse. However, it leaves the sourcing and meaning of listId and taskId unexplained, which is a clear gap for an agent needing to invoke 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 only 33%: mailbox is documented, but listId and taskId have no descriptions. The description adds no parameter meaning at all, failing to compensate for the low schema coverage and leaving two required parameters semantically opaque.

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 'Delete' and resource 'task', and explicitly contrasts with completing, which disambiguates from complete_google_task. However, it does not say 'Google task', so ambiguity with delete_outlook_task remains and it relies on the tool name/title for full precision.

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 condition to use it ('only delete when they say delete') and the alternative behavior ('completing') that is almost always intended. This is a strong when/when-not rule that directly addresses the most common misuse.

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 flag destructiveHint=true, but they don't say what the destruction covers or whether it is reversible. The description supplies both: the entire task list contents are removed, and there is no recycle bin, so the operation is irreversible. It stops short of disclosing permission or auth requirements, so it earns 4 rather than 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?

Two short sentences with zero filler; the destructive scope lands first and the irreversibility warning follows immediately. Nothing is redundant with 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?

For a destructive mutation with no output schema, the description covers the two things an agent most needs: what is destroyed (the whole list) and that it cannot be undone, plus a confirmation requirement. The remaining gap is how to obtain a valid listId, which is left entirely to the undocumented 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 only 50%: mailbox is documented in the schema (including a pointer to list_authorized_mailboxes), but listId carries no description at all. The description adds nothing about parameters – notably it never tells the agent where listId comes from (list_google_task_lists) – so it 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?

States a specific verb and resource ('Delete a task list') and goes further by naming the cascade scope ('and every task in it'), which cleanly separates it from delete_google_task and delete_outlook_task_list. An agent can route correctly 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 description gives a real usage constraint – 'ask the user to confirm first' – which is actionable behavioral guidance. However, it never states when to prefer this over siblings (e.g. delete_google_task for a single task, or emptying a list instead of deleting it), so the routing guidance 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 destructiveHint=true and readOnlyHint=false, so the safety profile is covered structurally. The description adds nothing on top: it does not say whether deletion is permanent, whether it can be undone, or what permissions the mailbox requires. With annotations carrying the load, the description contributes no incremental behavioral context.

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 front-loaded sentence with no wasted words, but the brevity stems from under-specification rather than disciplined conciseness. There is no structural issue, just very little content.

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 destructive, irreversible-by-implication mutation with no output schema and an undocumented required ruleId, the description should at minimum note the permanence of the action and how to source the ruleId. None of that is present, leaving the agent under-informed for correct invocation.

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 only 50%: mailbox is documented in the schema (with a pointer to list_authorized_mailboxes) but ruleId has no description anywhere. The description never mentions parameters or how to obtain a valid ruleId (e.g., from list_inbox_rules), so it 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 specific verb (Delete) and resource (inbox rule), so the agent knows exactly what operation it performs. It does not distinguish itself from its closest siblings (create_inbox_rule, list_inbox_rules), but the resource noun is specific enough to separate it from the many delete_* tools for other resource types.

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 tool versus alternatives such as delete_mail_folder or delete_gmail_filter, and no mention of the prerequisite that the rule must exist or how to discover it. The description offers no context beyond the operation itself.

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 flag destructiveHint=true, so the safety profile is known, yet the description adds a non-obvious consequence: contained messages are deleted too, with no automatic unfiling. That is exactly the kind of behavioral detail annotations cannot express, plus an explicit human-confirmation requirement.

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 action, then the warning, then the prerequisite and confirmation ask in a single tight sentence. No filler; every clause carries actionable 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?

With no output schema and only two params, the description covers the destructive semantics and confirmation duty well. The one gap is sourcing folderId, which is undocumented in both the schema and the description.

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 only 50%: 'mailbox' is well documented (including a pointer to list_authorized_mailboxes), but 'folderId' has no schema description at all and the description does not explain where to obtain it (e.g. list_mail_folders). The description adds no parameter meaning of its own.

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 ('Delete a mail folder'), which cleanly separates it from sibling deletes of other resource types. It does not explicitly distinguish itself from adjacent folder tools such as merge_mail_folders or rename_mail_folder, though the verb makes the distinction obvious.

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 preconditions: relocate anything worth keeping first and get user confirmation before calling. It implies move_messages as the alternative action but never names it, so the routing guidance is contextual 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 already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description adds genuinely new behavioral context: the item goes to the recycle bin and remains recoverable for the tenant's retention window, which materially changes how an agent should reason about reversibility. It stops short of stating permission requirements or behavior on non-empty folders.

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 redundancy, and the operation is front-loaded ahead of the recoverability note and the caution. Every sentence carries distinct information (action, consequence, advice).

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 destructive tool whose annotations already flag destructiveness and which has no output schema, the description covers the essentials: what is deleted and that it is recoverable. Remaining gaps are permission requirements and handling of non-empty folders, which are useful but secondary.

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 50% – mailbox is well documented but itemId has no description at all. The description's 'file or folder' phrasing gives a faint hint that itemId may reference either type, but it adds no format, ID-source, or resolution guidance to compensate for the undocumented required identifier.

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 ('Delete a OneDrive file or folder') and names the target scope, so it is immediately distinguishable from sibling deleters such as delete_gdrive_item, delete_mail_folder, and delete_outlook_task. No ambiguity about what is being operated on.

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?

Offers one piece of actionable guidance ('still worth confirming with the user first'), which is real usage advice for a destructive operation. However, it never names an alternative (e.g., move_onedrive_item or unshare_onedrive_item) or states when deletion is inappropriate, so the routing guidance is implied 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 already flag destructiveHint=true, but the description adds non-derivable behavior: the deletion cascades to every event, it is irreversible ('not recoverable'), and one calendar class is protected. These are exactly the facts an agent needs before a destructive call and cannot be inferred 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?

Three short sentences, front-loaded with the effect, then the constraint, then the confirmation requirement. No filler and nothing buried.

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 destructive tool with no output schema, the description covers effect, irreversibility, and the protected-default constraint. The remaining gap is where calendarId comes from and whether permissions are required, but the core 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?

Schema coverage is only 50%: calendarId has no description and the description adds no meaning for either parameter, no format, no source for the ID, no hint that list_outlook_calendars supplies it. The mailbox field's own schema description already covers its guidance, so the description compensates for nothing.

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 ('Delete') and resource ('a calendar') plus the cascade scope ('and every event on it'), which cleanly separates it from delete_outlook_calendar_event in the sibling list. No ambiguity about what gets removed.

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 a real precondition ('the default calendar cannot be deleted') and a mandatory pre-call workflow ('Ask the user to confirm before calling this'), which is strong usage guidance. It stops short of naming an alternative tool or stating when another deletion route would be preferable, so not a 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 already declare destructiveHint=true and openWorldHint=true, so the safety profile is partly covered. The description adds genuinely non-obvious behavior: cancellation emails are sent to every guest, and the deletion is 'immediately and irreversibly.' That external side effect cannot be inferred from the annotations. It doesn't cover error cases or recurring-series semantics.

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 tight sentences with no filler; the destructive consequence and the confirmation requirement are front-loaded and easy to scan.

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 does the necessary work of flagging irreversibility, guest notifications, and the confirm-first requirement. An agent can call it correctly, though the undocumented eventId parameter and lack of guidance on recurring events leave a small gap.

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 only 50% — eventId has no description at all, while mailbox documents itself and points to list_authorized_mailboxes. The description supplies no parameter guidance (no format, no how-to-obtain an eventId), so it 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?

States a specific verb+resource ('Delete one event or occurrence') with useful scope detail — the 'or occurrence' phrasing signals single-occurrence deletion. It doesn't explicitly differentiate itself from delete_google_calendar_event or delete_outlook_calendar, but the Outlook naming and event-level target make the intent unambiguous.

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 a concrete usage precondition: 'Ask the user to confirm before calling this.' That is real routing/behavioral guidance for a destructive action. It stops short of naming alternatives (e.g., delete_outlook_calendar for the whole calendar, or cancel_invitation) or stating when not to use it.

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 destructiveHint=true and readOnlyHint=false, but the description adds the non-obvious operational fact that To Do has no recycle bin, i.e. the deletion is unrecoverable. It does not address permissions beyond what the mailbox schema field already hints at (list_authorized_mailboxes), so it falls short of 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?

Two short sentences, zero filler. The irreversible-deletion warning is front-loaded and the alternative-tool guidance follows immediately.

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?

No output schema exists, and the safety profile is carried by annotations plus the explicit no-recycle-bin warning, so the behavioral story is complete. The remaining gap is the undocumented listId/taskId semantics, which an agent must infer from sibling tools.

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 only 33% (mailbox is documented), leaving listId and taskId undocumented in both schema and description. The description adds no meaning at all for the parameters, so it fails to compensate for the coverage gap; an agent gets no help on identifying the target task or list.

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 ("Permanently delete a task") and immediately differentiates the action from the sibling complete_outlook_task by naming that alternative. The word "permanently" also disambiguates it from update/complete operations at a glance.

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 routing rule: prefer complete_outlook_task, except when the task was created in error. That is a clear when-to-use and when-not-to-use statement with the alternative named, which is exactly the burden this tool should carry.

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 flag destructiveHint=true, but the description adds information the annotations cannot carry: the deletion cascades to all contained tasks and there is no recycle bin, so the data is permanently unrecoverable. It also specifies a required confirmation step before invocation, which is exactly the kind of behavioral context an agent needs for a destructive 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 short sentences: action first, then the destructive consequence as a capitalized warning, then the required confirmation. Nothing is wasted and the most important/surprising fact (irreversible cascade) is front-loaded.

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 destructive, no-output-schema tool this covers what is destroyed, that it is irreversible, and that user confirmation is required — the core behavioral burden. The only meaningful gap is not telling the agent how to source the listId 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?

The description names no parameters at all. 'mailbox' is well documented in the schema including the list_authorized_mailboxes resolution path, but 'listId' has no schema description and the description offers no hint about where to obtain it (e.g., list_outlook_task_lists). At 50% schema coverage the description fails to compensate for the undocumented identifier.

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 ('Delete a To Do list') and immediately clarifies scope by noting it removes every task inside the list, which separates it from delete_outlook_task (single task) and delete_outlook_task_list vs. the Google counterpart. An agent knows exactly what is affected 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 a concrete operational precondition — 'Ask the user to confirm before calling this' — which is real usage guidance for a destructive operation. It does not name an alternative (e.g., delete_outlook_task for removing individual items), so it stops short of explicit when-not routing.

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 the annotations (destructiveHint=true, readOnlyHint=false) by disclosing exactly what is destroyed (grant revoked at the provider, stored tokens deleted), that the action is reversible via dashboard reconnection, the owner/OAuth requirement, and the two-phase approval flow (stages a request, owner approves in-browser with an agent PIN, never collect the PIN in chat). This is unusually rich behavioral disclosure for a mutation 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 sentences, each carrying distinct information: the action and its effect, reversibility, auth constraint, and the approval-flow safety rule. The critical effect and constraint are front-loaded with 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?

For a destructive, multi-step mutation tool with no output schema, the description covers everything an agent needs: what gets destroyed, reversibility, permission/auth requirements, and the staging/approval protocol including the PIN-safety rule. Nothing material 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 description coverage is 100%, so all three parameters (mailbox, provider, workspace) are already documented in the schema, including the conditional 'only needed when...' guidance. The description adds no parameter-level detail beyond what the schema provides, so the baseline of 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+resource (disconnect a mailbox from a workspace) and immediately names the concrete effects: revokes the stored provider grant and deletes stored tokens. It is the only disconnect-style tool among the siblings, and the scope ('workspace you own') makes it unambiguous.

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 context for use and prerequisites: owners only, OAuth sign-in (no API keys), and the fact that the mailbox can be reconnected later from the dashboard. It does not explicitly name an alternative tool to compare against, but no close sibling alternative exists in the 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds useful semantics about duplicate criteria and mailbox scoping, but says nothing about how groups are returned or how many, and no output schema exists to fill that gap.

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 tight sentence that leads with the action and resource and immediately pins down the duplicate criterion and scope. 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?

For a simple read-only finder with one fully-described parameter and clear annotations, the description supplies the essential semantics: what a duplicate is and what boundary (mailbox) applies. The absence of any output shape or result-size hint is a minor remaining gap given 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?

Only one parameter, fully documented in the schema (100% coverage) including the list_authorized_mailboxes pointer. The description reinforces the 'within one mailbox' scope but adds no format or selection detail 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?

Specific verb ('find') plus resource ('duplicate Gmail labels') with a precise definition of what counts as a duplicate (groups of user labels sharing the same name) and the scope ('within one mailbox'). It does not explicitly name the sibling merge_duplicate_gmail_labels or list_gmail_labels to differentiate itself, but an agent can tell what it produces.

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 parenthetical 'likely duplicates worth merging' implies this is the discovery step preceding merge_duplicate_gmail_labels, but no explicit when-to-use, prerequisites, or named alternatives are given. Usage must be inferred from the name and 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?

Annotations already establish the safe read-only, closed-world profile, so the bar is lower. The description still adds real behavioral substance by defining the matching rule and the deliberate exclusion, telling the agent exactly what will and will not appear in results — though it says nothing about result shape or size.

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 sentences, both earning their place: the first gives the rule and the motivation, the second the exclusion and its rationale. Front-loaded with 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?

For a single-parameter, read-only detection tool with no output schema, the description covers what the agent needs to decide to call it and to interpret the result set. It could go slightly further by pointing at merge_mail_folders as the follow-up action.

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 a single parameter and the schema fully documents it, including the email pattern and a pointer to list_authorized_mailboxes. The description adds nothing 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?

The description states a specific verb and resource (find duplicate mail folders) and precisely defines what counts as a duplicate: same name within the same parent. That definition is the strongest disambiguation possible, though it never names sibling alternatives like list_mail_folders or find_duplicate_gmail_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?

Usage context is clearly implied — 'likely duplicates worth merging' signals this is the discovery step preceding merge_mail_folders — and the description explicitly states a negative case (same name under different parents is not reported). It stops short of naming the merge tool or listing prerequisites.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds one useful behavioral fact beyond that: the output is times only and never exposes event titles, which matters for privacy/format expectations. It says nothing about pagination, time-range defaults, or permission requirements.

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 operation and its purpose, with zero filler. 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?

With no output schema, the description does some of the return-value work by stating that only times are returned. But it leaves the timeMin/timeMax semantics and default range unspecified, which an agent needs in order to call this correctly for a scheduling query.

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 50%: mailbox and calendarIds are documented (including the default to primary calendar), but timeMin and timeMax are bare strings with no format hint, and the description never mentions the time window at all. For a tool whose core query is a time range, the description fails to compensate for the undocumented half of the parameters.

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 ('Return the busy blocks across one or more calendars') and the second sentence implicitly separates it from event-listing siblings by declaring it returns times only, never titles. It stops short of naming list_google_calendar_events or find_outlook_calendar_busy_times explicitly, so the differentiation is inferential rather than stated.

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?

'so a free slot can be proposed' implies the scheduling/free-busy use case, which is genuine usage context. However, there is no explicit when-to-use-vs-alternative guidance (e.g., versus list_google_calendar_events or search_google_calendar_events) and no stated prerequisites or exclusions.

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, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds a genuinely useful behavioral fact beyond the annotations: the result is privacy-preserving, returning times only and never event titles. It does not, however, disclose default behavior when no range is given.

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 tight sentences, front-loaded with what is returned and immediately qualified with what is not. Zero waste.

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?

No output schema exists, so the description is the only guide to results, yet it omits the time-window semantics that dominate this tool's four parameters (three undocumented). An agent cannot tell whether a range is required, optional, or defaulted.

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 only 25% – just mailbox is documented. timeMin, timeMax, and calendarId have no schema descriptions and the tool description says nothing about them, even though a time window is central to a busy-times query. 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?

States a specific verb+resource ("Return the busy blocks on a calendar") and clarifies the output nature (times only, not event titles), which separates it from list_outlook_calendar_events and search_outlook_calendar_events. It stops short of naming those siblings explicitly, so an agent must infer the contrast.

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?

"so a free slot can be proposed" gives an implied use case (availability/scheduling), which is more than nothing. However, it never states when to prefer this over listing or searching events, nor any prerequisites such as needing a time window.

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 destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavior: HTML-only messages are silently converted to plain text, and the attachment payload always includes the attachmentId needed by read_agentmail_attachment. It omits any note on truncation behavior, which lives only in the 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?

Two sentences, both front-loaded with the payoff (full body + attachment metadata) followed by the id-retrieval hint. No filler, no restatement of 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, so the description must carry the return contract, and it does — body text plus attachment fields. The one gap is that body truncation (maxChars, default 20000) is only discoverable via the schema, and no error behavior (missing message, wrong mailbox) is mentioned.

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 67% and messageId carries no schema description; the description compensates by telling the agent where to obtain the id from search_agentmail_messages. mailbox and maxChars are already documented in the schema, so no further gain is claimed there.

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 ('Read one message in full') and enumerates exactly what comes back: text body plus attachment name, type, size and attachmentId. It also implicitly separates itself from get_agentmail_thread and search_agentmail_messages by naming the latter as the id source.

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 routes the agent to search_agentmail_messages to obtain the required messageId, which is actionable pre-call guidance. It does not, however, state when to prefer this over get_agentmail_thread (full thread vs single message), so the alternatives story is incomplete.

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 destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: messages are ordered oldest-first within a page, long threads return newest page first, and pageToken is used to walk backwards. This ordering/pagination semantics is exactly the kind of trait annotations cannot convey.

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 the core read action, then pagination mechanics, then the id source. No filler or repetition.

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 describing returns, and it does cover decoded bodies and ordering. It stops short of describing the response shape (e.g., message list structure, pagination metadata fields), but for a read-only thread fetch with annotations covering safety, it is nearly 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 coverage is 50%; mailbox and maxCharsPerMessage are documented in the schema, while threadId and pageToken are not. The description compensates well: it explains that olderPageToken should be passed back as pageToken and that threadId comes from search_agentmail_messages, giving the two undocumented parameters real meaning.

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 ('Read a whole conversation... with decoded bodies'), which distinguishes it from the single-message sibling get_agentmail_message by emphasizing the whole conversation. It does not name any sibling explicitly, so the differentiation is implicit rather than crisp.

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 routes the agent to search_agentmail_messages for obtaining the threadId and explains the paging workflow, which is useful usage context. However, it never states when to prefer this tool over get_agentmail_message or the Gmail/Outlook equivalents, leaving alternatives 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 readOnlyHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely non-redundant context: it is a metadata-only read that returns no cell values, which tells the agent it is cheap to call before deciding where to read.

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 sentences, zero waste, front-loaded with the what and immediately followed by the why/when. 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?

Without an output schema, the description usefully summarizes the return shape (worksheets plus occupied ranges) and its role in the read workflow. Only minor gap is where workbookId comes from, which leaves it slightly short of fully 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 coverage is 50%: mailbox is documented (with a pointer to list_authorized_mailboxes) but workbookId has no schema description, and the description adds no format or provenance detail such as obtaining the ID from list_excel_workbooks. Baseline 3 applies since the description does not compensate for the 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 (read), resource (workbook), and precise scope: 'shape without reading cells: its worksheets and, for each, the occupied range.' This cleanly distinguishes it from read_excel_range (reads cells) and list_excel_workbooks (lists workbooks) without needing to open another 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?

'Call this first ... then read from the one you want' gives explicit sequencing and the condition that selects this tool versus the range-reader. It stops short of naming read_excel_range and offers no when-not guidance, but the intended workflow is unambiguous.

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 safe read-only profile, but the description adds real behavioral content: the body is decoded, HTML-only messages are down-converted to plain text, and attachments are returned as metadata with the attachmentId consumed by two named sibling tools. It does not mention auth requirements or attachment-size limits, but the added context is substantive.

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, front-loaded with the core action and scope, then behavior, then the prerequisite. Every clause either distinguishes the tool or changes how an agent calls it; nothing is redundant.

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-shape burden and does explain body and attachment fields. It omits other likely returned metadata (headers, subject, labels), which is a minor gap for a single-message read.

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 67% and messageId has no schema description at all; the description compensates by explaining where that ID comes from. maxChars and mailbox are covered by the schema, so the description's remaining contribution is the attachmentId/parameter linkage.

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?

"Read one message in full, including its decoded text body and its attachments" names a specific verb, resource and scope, and implicitly separates it from get_gmail_thread (whole thread) and list_messages (envelopes). An agent can identify the right tool 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 a clear workflow precondition: get the message ID from search_gmail_messages, which tells the agent this is the step after a search. It does not state when to prefer get_gmail_thread or get_outlook_message instead, so no explicit exclusion is offered.

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 destructiveHint=false, so safety is covered; the description adds genuinely behavioral detail not in the annotations — chronological ordering and decoded message bodies. It does not disclose pagination, thread size limits, or truncation behavior, so it stops short of 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?

Three short sentences, front-loaded with the capability, then the alternative, then the prerequisite. No filler, no repetition of 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?

With no output schema, the description carries the return-shape burden and does convey ordering, completeness ('every message'), and decoded bodies. Gaps remain around output size, truncation when maxCharsPerMessage binds, and behavior on very long threads, but it is sufficient to call the tool 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 coverage is 67%: mailbox and maxCharsPerMessage are documented in the schema, but threadId has no schema description. The description compensates by naming the exact source of threadId (search_gmail_messages), which is the one undocumented parameter that would otherwise cause trial and error.

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 ('Read every message in a conversation') with scope details (oldest first, decoded bodies), and distinguishes itself from the per-message sibling get_gmail_message and the analogous get_outlook_conversation. An agent can pick this over its nearest neighbor 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?

Explicitly names the alternative to avoid ('Use this instead of repeated get_gmail_message calls') and the condition that selects it ('when you need the whole exchange'). It also tells the agent where the required threadId comes from (search_gmail_messages), closing the loop on invocation.

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 establish this is a safe read operation (readOnlyHint=true, destructiveHint=false), so the safety profile is covered. The description usefully discloses that the response includes the guest list with addresses and acceptance status, which is real added context given no output schema, but it says nothing about auth scope, permissions, or rate limits.

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 front-loaded sentence with no filler; the key differentiator (single, full event) comes first and the extra return detail follows. Efficient, though it leans slightly toward describing output rather than splitting purpose and usage.

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 partly carries the return-shape burden by mentioning the guest list and RSVP status. However, two of three parameters are unexplained and there is no routing guidance, leaving meaningful gaps for a tool that must be called with a specific eventId and calendarId.

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 only 33% — just 'mailbox' is documented (with a pointer to list_authorized_mailboxes). 'eventId' and 'calendarId' are undocumented in both schema and description, and since the coverage is low the description needed to compensate but does not mention either parameter at all.

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?

"Read one event in full" gives a specific verb (read) and resource (a single calendar event), and the detail about the guest list sharpens what "in full" means. It implicitly distinguishes itself from list/search siblings by emphasizing a single event, though it never names them 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?

Usage is only implied by "one event" versus the existence of list_google_calendar_events and search_google_calendar_events. There is no explicit when-to-use guidance, no statement of prerequisites (e.g. needing an eventId from a list/search call), and no named alternative.

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