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

With no annotations, the description carries the behavioral burden. It clearly discloses the two main effects: the event is cancelled and attendees are notified. It does not mention permissions, irrevocability, or output, but the core behavior is transparent.

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 a single front-loaded sentence with no filler. It earns its place, though it omits enough parameter context that it is not fully 'appropriately sized' for the schema it accompanies.

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?

As a mutation tool with no annotations and no output schema, the description should provide more operational context. It gives no information about the comment parameter, mailbox behavior beyond the schema, the return value, or any prerequisites, so an agent is left to guess important call details.

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%, and the description adds no parameter-level meaning. eventId and comment are left undocumented; only 'notify attendees' weakly hints at comment's purpose. The schema's mailbox description covers that parameter, but 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?

The description uses a specific verb ('Cancel') and resource ('calendar event'), and adds an important side effect ('notify attendees'). This clearly distinguishes it from sibling create/update/get calendar 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 intended use is implied by the name and description, but there is no explicit guidance about when to choose cancellation over update_calendar_event or other calendar siblings, and no when-not-to-use conditions.

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

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

With no annotations present, the description carries the full burden, and it discloses non-obvious behavior: automatic conflict checking, refusal with conflict:true plus conflicting events, and the force bypass. It could have also covered result-on-success and error behavior, but the most important side effects are transparent.

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 with no filler: purpose first, then approval requirement, then the conflict-check and force override. Every sentence carries useful operational 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?

The description captures the critical conflict-resolution logic, but for a tool with no output schema and nine parameters it is incomplete: it doesn't state the success response shape, the required time format, or the meaning of fields like attendees and isPrivate. It covers enough for basic correct invocation but not full situational confidence.

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%, so the description should compensate. It adds meaning to force and to the startTime/endTime range via the conflict-check behavior, but it leaves subject, startTime, endTime, attendees, body, and location semantics entirely to the schema, which lacks descriptions for most of them.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Create a new calendar event,' which names a specific verb and resource. It clearly distinguishes itself from sibling tools such as update_calendar_event and cancel_calendar_event.

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 establishes clear context: use this tool to create events, and it includes a strong conditional guideline for the force parameter, telling the agent to pass true only after explicit user approval of double-booking. It does not explicitly contrast with update/cancel, but the resource name and creation verb make the usage obvious.

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

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

With no annotations, the description carries the behavioral burden. It states that a draft is created in Outlook Drafts, that it is not sent immediately, and that attachments up to 25MB are supported. However, it does not disclose return value, persistence behavior, side effects, or error conditions.

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 two sentences with no filler. The primary action and location are front-loaded, and the attachment limit is summarized efficiently.

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 tool with 8 parameters, no annotations, no output schema, and several closely related sibling tools, this description is too thin. It does not explicitly differentiate from create_reply_draft or send_email, explain required parameters, or clarify how conversationId fits with 'standalone'.

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%, and the description adds no parameter-level meaning beyond what the schema already provides. Required fields like to, subject, and body remain undocumented, and conversationId is not explained; the only added detail is an attachment-size summary already present 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?

The description uses a specific verb ('Create'), a clear resource ('standalone draft email'), and a precise location ('Outlook Drafts folder'). The qualifier 'standalone' helps distinguish it from reply-draft tools like create_reply_draft.

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?

'For review before sending' gives a clear usage context: use this when a draft should be prepared but not immediately sent. 'Standalone' also differentiates it from reply/thread-based draft creation, though it does not explicitly name sibling tools or state 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?

The description discloses key behaviors: it creates a draft (not sending), supports attachments with explicit size limits, and explains the chunking behavior for larger files. It also mentions the API used, providing full transparency without relying on 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?

The description is succinct but packs essential details—purpose, API, attachment limits, and behavior—into two sentences. The schema is well-structured and follows a logical order, making it easy to parse.

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 the tool's complexity (7 parameters, attachment rules, and draft creation), the description and schema fully cover all necessary context. It clarifies the draft nature, attachment handling, and required messageId, leaving no critical gaps for an agent to invoke it 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?

All 7 parameters have clear, concise descriptions in the schema, covering CC/BCC, body, mailbox, replyAll, messageId, and attachments. The description adds extra context for attachments (paths, size handling), ensuring the agent understands each parameter's purpose and constraints.

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 clearly states the tool's primary function: creating an unsent draft reply to an existing email thread via the Microsoft Graph createReply API. It also specifies the endpoint and attachment limit, leaving no ambiguity about what the tool does.

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 implies usage by stating 'unsent draft reply,' which distinguishes it from sending a reply directly. However, it does not explicitly contrast with sibling tools like reply_to_email or create_email_draft, leaving the decision to the agent based on implicit context.

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?

There are no annotations provided, so the description carries the full burden of behavioral disclosure. It only says 'get' and the date range; it does not disclose defaults, timezone handling, recurrence behavior, result limits, or what happens when no events exist. This is minimal coverage for a tool with no annotation support.

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 a single, front-loaded sentence with no filler or repetition. Every word contributes meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is minimally viable for a simple retrieval tool, but with no output schema or annotations it leaves behavioral and return-value details undisclosed. An agent can call it correctly based on the schema, but may not know what to expect in response or how edge cases are handled.

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 reinforces that startTime and endTime define a range, but adds no additional meaning beyond the schema, especially for the optional mailbox parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear verb and resource ('Get calendar events') with an explicit temporal scope ('between two datetimes'). It is unambiguous about what the tool does, though it does not directly name or differentiate itself from sibling tools like get_upcoming_events.

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 phrase 'between two datetimes' gives clear context for when to use this tool: when a specific date/time range is needed. It does not mention alternatives or exclusions, but the usage context is evident from the description.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Retrieve' implies a read-only operation, but the description does not clarify whether messages are marked read, how the optional limit affects the 'full' claim, what response shape is returned, or whether mailbox access permissions are required.

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 a single, front-loaded sentence with no filler. It communicates the primary action and scope immediately and every word 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 and no annotations, the description is too thin for reliable invocation: it omits how limit behaves, what the returned conversation history contains, and when to choose this tool over sibling email search/retrieval tools. The word 'full' also sits awkwardly with the optional limit 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 schema already documents conversationId and mailbox, so the description adds little beyond restating that retrieval is by conversation ID. The limit parameter has no schema description and the tool description does nothing to explain its meaning or default 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?

The description states a specific verb ('Retrieve'), a specific resource ('full email conversation history'), and the required identifier ('by conversation ID'). This clearly distinguishes it from sibling tools like search_emails or get_recent_emails, which target individual emails or folder scans rather than a conversation thread.

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 implies the appropriate use case: when an agent has an Outlook Conversation ID and wants the full thread history. However, it does not explicitly state when to prefer this over sibling tools such as search_emails, nor does it mention exclusions such as needing a mailbox or limits on large threads.

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

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

With no annotations provided, the description carries the full burden. It clearly communicates a read-only fetch operation and discloses the exact return shape including contentBytes. It does not mention potential caveats such as base64 encoding, size limits, or behavior when the message has no attachments, which keeps it 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?

The description is two short clauses with zero filler. The core action is front-loaded in the first sentence, and the compact return-array declaration adds concrete value. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter read operation with no output schema, the description is largely complete: it specifies purpose, input, and the exact return structure. It omits minor edge-case details like no-attachment behavior and the encoding of contentBytes, but the field names make those mostly self-evident. No output schema raises the burden slightly, and this description meets it well.

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. The description adds little beyond schema: it rephrases the id parameter as 'given Outlook messageId' and does not mention the mailbox parameter at all. The schema already documents both parameters adequately, so no deduction is warranted.

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 ('Fetches'), a specific resource ('file attachments'), and the exact input ('given Outlook messageId'). It also distinguishes the tool from all sibling email tools by clarifying that it returns the content of attachments, not emails or folders. No sibling covers attachments, so no ambiguity remains.

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 implies a clear context: use this tool when you need the actual attachment content for a particular Outlook message. It does not state any exclusions or alternatives, but none of the sibling tools handles attachments, so no routing guidance is necessary. Lacks explicit when-not-to-use statements, preventing 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly indicates a read-only listing operation and mentions unread counts, but it does not describe the response format, ordering, pagination, or any edge-case behavior. This is adequate but not deeply transparent.

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 dense, front-loaded sentence with no filler. Every word contributes to the tool's purpose and primary output.

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 list operation, the description covers the core purpose and the main returned data (folder list with unread counts). There is no output schema, and some details like exact response shape or mailbox scoping are implied rather than explicit, but the description is still reasonably complete for this simple tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter, mailbox, is fully described in the schema, including its default behavior. Since schema coverage is 100%, the description does not need to add parameter details, and it does not; 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?

The description uses a specific verb ('List') and resource ('Outlook mail folders') and adds the key output detail ('unread counts'). It is clearly distinct from siblings like get_recent_emails_all_folders, which concern email messages rather than folder metadata.

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 guidance is given about when to use this tool versus alternatives such as get_unread_emails or get_recent_emails_all_folders. The use case is only implied by the description, with no explicit exclusions or conditional 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It conveys a read-only fetch operation but does not specify sorting, the meaning of 'recently', or whether both read and unread emails are included.

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 a single, front-loaded sentence with no filler or repetition. It is efficient, though slightly too terse to carry all useful context.

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 tool with fully documented optional parameters, the description is minimally viable: it states the inbox scope and the 'recently received' intent. However, with no annotations and no output schema, the vague recency window and lack of ordering details leave 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 description coverage is 100%, with both limit and mailbox documented. The description itself adds no parameter-level detail, 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?

The description names a specific verb ('Fetch') and resource ('recently received emails from Outlook inbox'), and the inbox qualifier distinguishes it from sent/all-folder tools. It does not explicitly differentiate from get_unread_emails, since received and unread overlap conceptually.

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 about when to use this tool versus get_recent_emails_all_folders, get_unread_emails, or search_emails. No alternatives, exclusions, or conditions are mentioned; the agent must infer context from sibling tool names.

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

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

With no annotations provided, the description carries full burden. It transparently states the operation is a fetch (read-only), describes the return format (bodyPreview instead of full HTML), and lists exclusions. It does not mention any side effects or error conditions, but as a read operation, those are not expected. The description is sufficiently transparent about the tool's 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?

The description is two sentences, covering the core functionality and key exclusions without unnecessary detail. Every word contributes to the meaning, and there is no repetition or fluff.

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 straightforward read operation, the description provides sufficient context: what it fetches, from where, what it excludes, and what the response contains. It does not require additional explanation about return format or filters. It could be slightly more explicit about sorting order, but that is a minor omission given the simplicity of the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema covers both parameters (limit and mailbox) with descriptions. The tool description does not add any additional semantics beyond the schema, so the baseline of 3 is appropriate. No extra nuance is provided that would elevate the score.

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?

Clearly states the tool fetches recently received emails across all folders, explicitly distinguishing it from the sibling get_recent_emails by noting 'all folders, not just Inbox'. The exclusion of Deleted Items, Junk, and Drafts further refines the scope.

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 explicit guidance on when to use this tool by contrasting with the Inbox-only variant and listing the folders that are excluded. Also mentions the bodyPreview payload choice, which helps the agent decide based on response size needs. Does not explicitly state 'use this when you need emails from any folder except exclusions', but the implication is clear.

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

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

With no annotations, the description carries the full behavioral burden, but it only restates the operation ('Fetch sent emails') and gives a purpose. It does not disclose ordering, default limit behavior, how mailbox selection affects results, or the shape of the returned 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 filler. The verb-resource pair appears first and the purpose clause earns its place by clarifying intent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple and callable with zero required parameters, so the description is minimally viable. Yet without an output schema or annotations, it should also clarify return behavior or at least distinguish itself from sibling email-fetching 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 50% and the description adds nothing about the parameters. An agent cannot tell from the description what 'limit' means or how it interacts with the optional 'mailbox' parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Fetch'), a clear resource ('sent emails'), and an actionable purpose ('track outbox and detect missing replies'). This clearly distinguishes it from siblings like get_unread_emails or get_recent_emails.

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 phrase 'to track outbox and detect missing replies' provides clear context for when this tool is appropriate. However, it does not explicitly mention alternatives or exclusions, such as when to prefer search_emails or get_recent_emails_all_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?

There are no annotations, so the description carries the full behavioral burden. It only says the tool 'gets' data and gives no hint about whether emails are marked read, what time ranges are used, how results are combined, or what the response structure looks like. This is a gap for a tool with no annotation safety hints.

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 a single efficient sentence that front-loads the tool's purpose and the 'one call' value proposition. It is concise and free of filler, though it could arguably include more structured guidance without becoming bloated.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool aggregates two different data types, has no output schema, and no annotations describing behavior or response format. The description is enough to pick the tool but not enough for an agent to understand what a returned briefing contains, how results are structured, or what side effects may occur.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter is fully documented in the schema with 100% coverage, so the baseline applies. The description adds no extra meaning about mailbox resolution, defaults, or how the mailbox parameter affects both emails and calendar events beyond what the schema already says.

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 ('Get') and resource ('today's unread emails and calendar events'), and the phrase 'in one call' distinguishes it from the many sibling tools that fetch emails or events separately. It is not perfectly precise about whether 'today's unread emails' means unread emails received today or all currently unread emails, so it falls just 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 phrase 'in one call' implies this is the combined/aggregate alternative to separate email and calendar tools, but the description never explicitly states when to prefer this tool over get_unread_emails, get_calendar_events, or search_emails, and provides no 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?

With no annotations provided, the description carries the full burden. It indicates a read operation via 'fetch' but does not explicitly state side effects, permissions, rate limits, or whether it modifies any state. This lack of transparency is a 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?

The description is only one short sentence, concise and to the point. It conveys the essential information without unnecessary detail, making it highly efficient.

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 fetch operation, the description is complete. It specifies the target resource and purpose, and with no output schema, there is no need to detail return values. The tool is straightforward and the description covers what an agent needs.

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 schema description for the 'mailbox' parameter is clear and complete, covering its type, purpose, and default behavior. Since schema coverage is high, the description adds no additional value beyond the schema, warranting the baseline score of 3.

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 clearly states the action (fetch), the resource (unread emails from Outlook inbox), and the purpose (for triage). It is specific enough to differentiate from broader email tools, though it does not explicitly name a sibling tool.

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 provides only a generic purpose ('for triage') but lacks explicit guidance on when to use this tool versus alternatives like search_emails or get_recent_emails. No prerequisites or constraints are mentioned.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says events are upcoming and within N days, but does not explain what 'upcoming' means regarding the current time, default day range, ordering, timezone handling, or output shape. Given the lack of annotation support, this is minimal transparency.

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 a single, front-loaded sentence with no wasted words. It communicates the core operation and time window efficiently, though it may be too terse to fully compensate for missing behavioral and usage details.

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 tool with two optional parameters and no output schema, the description leaves critical invocation details unspecified: whether 'days' has a default, what range of events qualifies as 'upcoming', and how this tool differs from get_calendar_events. An agent would need to inspect sibling tool definitions or make assumptions to select and call this 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 description coverage is 50%: 'mailbox' is documented in the schema, but 'days' has no schema description. The description's 'next N days' adds some meaning to the days parameter, but it does not specify defaults, constraints, or how N maps to the exact parameter behavior. The description does not add any semantics for 'mailbox' 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 action ('Get'), a resource ('calendar events'), and a time boundary ('next N days'). It is clearly a read operation distinct from calendar creation/update/cancel siblings, though it does not explicitly differentiate itself from the closely named sibling get_calendar_events.

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 phrase 'upcoming calendar events' implies a temporal use case, but the description gives no guidance on when to prefer this tool over get_calendar_events, get_todays_briefing, or other calendar-related tools. There is no exclusion criteria or alternative 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?

Annotations are absent, so the description must carry the full behavioral burden. It only states the mutation ('Mark') without disclosing side effects, prerequisites, default behavior when isRead is omitted, or the response behavior. This is thinner than the update_drive calibration example.

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 a single short sentence with no filler or redundant wording. It is front-loaded and efficient, though its brevity borders on under-specification rather than being a complete description.

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 annotations and no output schema, the description is not complete enough. It does not clarify what happens if isRead is omitted, how the email is identified, or what the result of the operation is. Given the simple schema, it is adequate only at a surface level.

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 only), so the description must compensate for the undocumented emailId and isRead parameters. The phrase 'read or unread' partially maps to isRead, but emailId remains unexplained, and no parameter formats or defaults are provided.

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 uses a specific verb ('Mark') and a clear resource ('an email') and even covers both directions ('read or unread'). It is unambiguous at a basic level, though it does not explicitly distinguish itself from sibling tools beyond the action itself.

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 about when to use this tool versus alternatives like triage_email, get_unread_emails, or move_email. An agent is left to infer that this is the correct tool for changing read state.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals that the email will be moved, but does not mention side effects, permissions, whether the move is reversible, what happens to the email in its source folder, 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?

The description is a single, front-loaded sentence with no filler. It efficiently communicates the core operation and destination in six words.

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 annotations, no output schema, and low schema coverage, the description is too sparse. It does not explain how to identify the email, how to obtain a valid destination folder ID, or what a successful move returns, leaving an agent to rely on implicit naming conventions.

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%, and the description does not compensate: it adds no meaning for emailId or mailbox, and 'specific folder' merely mirrors destinationFolderId. The parameter names are self-descriptive, but the description provides almost no additional semantic value.

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 action ('Move an email') and a destination ('to a specific folder'), so an agent can identify the resource and operation. It is distinguishable from sibling email tools like send_email or mark_email_read, though it does not explicitly name or differentiate against any 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 guidance about when to use this tool versus alternatives, nor any exclusions such as 'do not use for drafts' or 'use get_email_folders first to resolve a folder ID'. The intended use is only implied by the tool's name and one-line description.

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?

Even though no annotations are provided, the description discloses notable behaviors: prior approval is required, and attachments over 3MB go through an internal draft-then-send step while reaching the same result. This goes beyond basic schema info and sets accurate expectations.

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 a single concise sentence with one clarifying parenthetical. It conveys the primary purpose and key constraints without unnecessary detail, making it easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema and no explicit return-value description, but for a send-type action, the absence may be acceptable. The description covers what the tool does and important edge cases (attachment size limits and internal handling), giving enough context for an agent to call it 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 57%; emailId, body, and replyAll lack descriptions. While their meanings are fairly obvious from the tool name and context, the description does not add further semantics for these missing fields. The attachment constraints are well documented, but overall parameter clarity is moderate.

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?

Description states a specific verb and object: 'Reply to an existing email thread.' It clearly distinguishes from sending a new email or creating a draft, though it does not explicitly name the sibling alternatives. The sibling list includes create_reply_draft and send_email, making the intent reasonably clear.

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 implies when to use it via 'existing email thread' but does not explicitly state 'use this instead of send_email for replies' or compare with create_reply_draft. The 'Requires prior approval' note gives a condition, but usage guidance is left 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state whether this is a read-only operation, what scope it searches (current mailbox vs all folders), whether results are limited, or what the output looks like. The word 'search' suggests non-mutation, but key behavioral context is missing.

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 a single, front-loaded sentence with no filler words. It is concise and easy to parse, though it could have used the saved space to add a bit more operational context without becoming bloated.

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 tool with no annotations and no output schema, the description is too sparse. It does not explain search scope, default mailbox behavior beyond the schema, whether all folders are included, what 'limit' means, or what a result looks like. Sibling tools like get_recent_emails_all_folders suggest scope is a relevant distinction that this description leaves unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema covers 67% of parameters, with mailbox already well described. The description adds useful meaning to 'query' by enumerating keyword, sender, subject, and topic, but it does not clarify the 'limit' parameter at all. It partially compensates for the generic 'Search query' schema text.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies a specific operation—searching emails—and lists the search dimensions (keyword, sender, subject, topic). It does not explicitly differentiate from sibling tools like get_recent_emails or get_unread_emails, 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?

The verb 'search' implies this tool is for query-based lookup rather than simple listing or folder retrieval, but the description gives no explicit guidance on when to prefer it over siblings like get_recent_emails_all_folders or get_sent_emails. Usage context 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?

With no annotations, the description carries the full disclosure burden. It reveals the client-approval prerequisite and the internal draft-then-send mechanism for attachments over 3MB, explicitly noting the result is identical and usage is unchanged. It does not cover failure modes or delivery guarantees, but the key behavioral traits are disclosed.

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 purpose and the approval requirement, followed by the attachment constraint. No filler or redundant explanation; every clause contributes value.

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 send tool with no annotations, the description covers the most critical contextual points: client approval and attachment limits/behavior. It does not describe the return value or delivery status, but no output schema exists and this is not essential for invoking 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 57%; the schema documents cc, bcc, mailbox, and attachments in detail, while to, subject, and body are left to their self-evident names. The description adds no parameter-level meaning beyond the schema; it restates attachment limits that the schema already covers.

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 clearly states a specific verb and resource: 'Send an approved email.' It signals a send operation rather than a draft, which distinguishes it from sibling draft tools, but it does not explicitly name any sibling or state what it is not.

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 an important usage gate: 'Requires explicit approval from the client first.' It provides clear context for when this tool is appropriate, but it does not explicitly describe when to use it over alternatives like create_email_draft or reply_to_email, nor does it list 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?

No annotations are provided, and the description does not clarify whether this tool has side effects (e.g., modifies email state) or if it is a read-only operation. It also does not mention any required permissions or potential impacts.

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 brief and to the point, using a single sentence to convey the core functionality. It is appropriately concise, though it could benefit from a bit more 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?

Given the tool's complexity (classification and suggestion), the description lacks necessary context such as input requirements, output format, or how the reply suggestion is generated. It does not provide enough information for an agent to use it effectively without additional assumptions.

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 schema provides no descriptions for the five parameters (id, sender, subject, body, senderName), and the description does not explain their meaning or usage. Parameter semantics are entirely 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?

The description clearly states the action ('classify') and the resource ('an email'), and specifies the outputs: urgency, category, and reply suggestion. However, it does not distinguish this tool from sibling tools like search_emails or get_recent_emails, which also operate on emails.

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 implies a use case (classification and reply suggestion) but does not explicitly state when to use this tool versus alternatives like search_emails or get_conversation_thread. No conditions or prerequisites are mentioned.

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

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

With no annotations, the description carries full behavioral disclosure. It reveals the automatic conflict check, the refusal behavior with conflict:true and conflicting events, and the force bypass. This is substantial transparency for a mutation tool, though it does not cover permissions or what happens on successful update.

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 tightly written sentences. The purpose is front-loaded and the conflict-check/force behavior is explained without redundancy or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The conflict behavior is well covered, but the tool has 9 parameters, no annotations, and no output schema. The description does not describe success return values, time format expectations, or what happens when only one time is changed, leaving some important context 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 only 33%, so the description must compensate. It does add meaning for startTime, endTime, and force by explaining their interaction in conflict checking, but leaves body, subject, location, and eventId without any descriptive help beyond their 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?

The description opens with 'Update an existing calendar event', which is a specific verb plus resource. It clearly distinguishes this from sibling tools like create_calendar_event and cancel_calendar_event.

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 provides concrete guidance on when force:true may be used ('only pass force:true after the user has explicitly approved double-booking') and explains the conflict-check behavior. It does not explicitly contrast with create/cancel tools, but the usage context is clear enough.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It communicates that the operation mutates a draft via 'Update/edit' and PATCH, but it does not state whether unspecified fields are preserved, whether the draft must remain unsent, what permissions are required, or what the response contains. This is a notable gap 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?

The description is a single sentence that front-loads the verb and resource, then adds the endpoint for technical precision. Every word is informative and there is no filler or repetition 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?

The input schema fully documents all 7 parameters, so invocation details are well covered. However, with no output schema and no annotations, the description does not address what the tool returns, error conditions, or side effects on unspecified fields. For a straightforward draft update, this is partially complete but missing behavioral context.

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 even without parameter details in the description. The description adds little beyond naming 'subject, body, or recipient', which overlaps with existing schema descriptions. It does not clarify formats or relationships beyond what the schema already 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 ('Update/edit'), a specific resource ('an existing email draft'), and the affected fields ('subject, body, or recipient'). The PATCH endpoint further reinforces that this is a modification operation, clearly distinguishing it from siblings like create_email_draft and create_reply_draft.

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 phrase 'existing email draft before sending' provides clear context that this tool is for modifying drafts already created, not for creating new ones or sending messages. It does not explicitly name alternative tools or exclusions, but the context is sufficient for an agent to select it correctly over create_email_draft or send_email.

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