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

No annotations are present, so the description carries the full burden of behavioral transparency. It states the destructive action (deleting cached tokens and pending login state) and adds a 'Development only' caveat, but it does not disclose potential side effects on the current session or clarify that this is local-only, which would be useful for a destructive operation.

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 extremely concise and front-loaded. The first sentence 'Development only.' immediately communicates the context, followed by a precise action statement. The Chinese intent examples add multilingual value without bloat. Every sentence earns its place.

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

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

For a tool with no parameters and no output schema, the description is largely complete. It covers the purpose, the environment restriction, and the exact state cleared. However, it could go slightly further by stating whether this impacts server-side auth sessions or what the expected result is, which would enhance completeness.

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 zero parameters, the schema is trivially 100% covered. The baseline for no parameters is 4, and since there are no parameters to explain, the description does not need to add parameter semantics. It correctly avoids unnecessary detail.

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 purpose: to delete locally cached tokens and pending device-code login state. It uses a specific verb ('Delete') with a clear resource and distinguishes itself from sibling auth tools like auth_start_device_login and auth_complete_device_login.

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 includes a clear usage context: 'Development only.' This indicates when the tool should be used (development environments) but does not explicitly mention alternatives or exclusions beyond environment. The uniqueness of the action makes usage context reasonably 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 transparency burden. It discloses key behaviors: polling, local caching, and that 'Token values are not returned.' It also notes 'Development only,' providing a usage constraint. However, it omits error/timeout 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 concise and front-loaded with the core action. The addition of Chinese intents is supplementary but still compact. Every sentence serves a purpose, though the localization list could be seen as extra.

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-parameter tool with no output schema, the description covers the essential flow (poll, cache, no token return) and the development-only caveat. It could be more complete by explicitly referencing the preceding auth_start_device_login step, but overall it is adequate.

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, timeoutSeconds, is fully described in the schema. The tool description does not add further parameter semantics, but with 100% schema coverage, the baseline of 3 is appropriate.

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

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

The description clearly states the tool's purpose with a specific verb and resource: 'Poll the token endpoint after the user enters the device code, then cache the token locally.' This distinguishes it from sibling auth tools like auth_start_device_login and auth_status.

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 clear context for when to use: after the user enters the device code, and it restricts usage to 'Development only.' It does not explicitly name alternatives, but the sequencing with the device login flow is 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 behavioral burden. It explicitly discloses 'Development only' and that the result is cached locally, which are important behavioral traits. It does not detail the interactive device-code prompt or local cache format, but it provides meaningful transparency beyond a vague verb.

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 front-loaded: a development-only warning, the core action, and the caching result. The Chinese intent list adds value for multilingual intent matching without unnecessary 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 low-complexity tool with one optional parameter and no output schema, the description is largely complete: it states the purpose, context, and side effect. It omits the next step (e.g., use auth_complete_device_login) and what the tool returns, but the sibling list and title make this inferable.

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 100% of parameters and already describes the optional scopes override and its default. The description adds no extra parameter semantics, but the baseline of 3 applies because the schema does the heavy lifting sufficiently.

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 clearly states a specific action: 'Start a 21V Entra device-code login and cache the result locally.' It names the resource (Entra device-code login), the verb (start), and the side effect (cache locally). This differentiates it from sibling tools like auth_complete_device_login and auth_status.

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 clear context with 'Development only' and implies when to use the tool (when initiating a local device-code login). However, it does not explicitly contrast with or point to related tools, such as auth_complete_device_login for finishing the flow, nor does it state 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?

No annotations are present, so the description carries the full burden. It adds a key privacy disclosure that token values are never returned, and the verb 'Inspect' implies read-only behavior. It does not mention network side effects or rate limits, but for a zero-parameter status tool, this is adequate.

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 concise, with key information front-loaded in the first sentence. The Chinese intent mapping adds value without unnecessary bloat, and every sentence earns its place.

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

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

Even without an output schema, the description conveys what information is exposed (auth state, token state, OAuth/OBO configuration, user details) and the critical privacy boundary. It is sufficient for a read-only diagnostic tool with no parameters.

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

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

The tool has zero parameters and schema coverage is 100%, so the baseline is 4. The description adds meaningful context about what the status inspection covers, which is sufficient given no parameters exist.

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 the specific verb 'Inspect' and enumerates the exact resources covered (MCP auth state, local token state, remote OAuth/OBO configuration, current request user details). It clearly distinguishes this tool from sibling auth tools that start, complete, or clear login flows.

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 clear context for when to use it, including '诊断授权问题' (diagnose authorization issues) and checking login status. It does not explicitly name alternatives or exclusions, but the diagnostic intent and read-only scope differentiate it from mutation-focused auth siblings.

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 disclosure burden. It mentions the size limit and base64 encoding, but does not describe the expected outcome (append vs replace), error handling for oversized files, permission requirements, or side effects. This leaves significant behavioral ambiguity 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 two short sentences, front-loading the essential English statement and appending a Chinese translation that aids non-English users. There is no wasted information; every word contributes to clarity.

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 six parameters, no annotations, no output schema, and the presence of sibling tools for attachments (mail_add_file_attachment, calendar_list_attachments, etc.), the description is incomplete. It lacks context on prerequisites, relationship to other attachment tools, and inline attachment behavior, making it insufficient for an agent to fully understand when and how to invoke 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?

Schema description coverage is 100%, so all parameters are already documented in the input schema. The description reiterates the base64/size constraint already present in the contentBase64 field, adding no new semantic meaning 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 clearly states the action: 'Add a base64-encoded file under 3 MB to a calendar event.' It specifies the resource (calendar event) and the operation (add file attachment), distinguishing it from email attachment tools like mail_add_file_attachment because of the explicit 'calendar event' 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?

The description implies its use case—adding attachments to calendar events—but provides no explicit guidance on when to choose this over alternatives such as mail_add_file_attachment. The Chinese intents are simple translations, not usage context. No exclusions or alternative suggestions are 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?

With no annotations, the description carries the full burden of disclosing side effects. It explicitly states that attendees are notified and the required permission, which are critical. It doesn't mention irreversibility or the ultimate fate of the event, but the key behavioral aspects are covered.

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 concise: two sentences covering the core behavior and permission, followed by Chinese intent examples. It is front-loaded and contains no fluff 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 two-parameter cancellation tool with no output schema, the description covers essential context: the action, the actor constraint, required permission, and the notification side effect. It could benefit from explicit mention of when not to use it (e.g., when not the organizer), but it is adequately complete for its simplicity.

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

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

Both parameters are fully described in the schema (100% coverage, each with descriptions). The tool description adds no additional parameter-level meaning beyond what the schema already provides, so the baseline of 3 is appropriate.

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

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

The description clearly states the action (cancel), the target resource (a meeting organized by the signed-in user), and the side effect (notify attendees). This distinguishes it from sibling tools like calendar_delete_event by emphasizing the notification behavior.

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 provides clear context: only meetings organized by the signed-in user can be cancelled, and it requires delegated Calendars.ReadWrite. However, it doesn't explicitly contrast with calendar_delete_event or calendar_respond_to_event, so it lacks explicit when-not guidance.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses that the calendar is 'additional' and scoped to the 'signed-in user,' clarifying that it does not create a shared or delegated calendar. However, it does not mention permission requirements, duplicate-name behavior, or what the response returns, leaving notable gaps for a create operation.

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 core English description is a single, front-loaded sentence that delivers the purpose efficiently. The Chinese intent block is redundant but compact and serves intent-matching for non-English queries, so it does not meaningfully harm readability or structure.

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 one-parameter creation tool, the description plus full schema coverage cover the essential semantics of what the tool does and what input it takes. However, with no annotations and no output schema, the description does not disclose the return value, required auth scopes, or behavior on duplicate names, making it adequate but not fully complete.

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

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

The input schema fully documents the single parameter `name` with 100% coverage, so the schema carries the descriptive burden. The description adds no parameter-level semantics beyond what the schema already states, warranting the baseline score of 3 for high schema 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 'Create an additional calendar for the signed-in user,' providing a specific verb (create), resource (calendar), and scope (additional, user-scoped). This clearly distinguishes it from siblings like calendar_create_event, calendar_list_calendars, and calendar_update_calendar. The Chinese intent phrases reinforce the same meaning without introducing ambiguity.

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 context through 'additional calendar' and 'signed-in user,' suggesting when it applies. However, it offers no explicit when-not-to-use guidance, no exclusions, and no pointer to alternatives like calendar_update_calendar or calendar_delete_calendar for related operations. Usage is inferred rather than 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?

With no annotations, the description carries the full burden. It discloses the permission requirement and default calendar scope, but doesn't mention side effects such as invitation sending to attendees, online meeting creation behavior, or return value. This is a gap for a write 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 two concise sentences, front-loading the primary action and permission requirement. The Chinese intents add multilingual value without unnecessary bulk, and every sentence earns its place.

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

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

The tool has moderate complexity with nested start/end objects, optional attendees, and an online meeting flag. With no output schema or annotations, the description could disclose more about return behavior and side effects, but it's reasonably scoped for a creation 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 input schema covers 100% of parameters with descriptions (e.g., dateTime format, timeZone default, attendee type enum), so the description adds no extra parameter semantics. Baseline 3 is appropriate since the schema does the heavy lifting.

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

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

The description uses a specific verb (create) and resource (event/meeting in the signed-in user's default calendar), clearly distinguishing it from sibling calendar tools like update, cancel, or delete. It also states the required permission, making 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?

It clearly states the tool creates an event/meeting in the default calendar and requires delegated Calendars.ReadWrite, providing a clear context for invocation. It doesn't explicitly mention alternatives, but the action is self-evident compared to other calendar tools.

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 present, so the description must carry the full burden of behavioral disclosure. It only states the action without any details about side effects, permanence, permissions, or error conditions. For a destructive operation like deletion, this is a notable 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 two short sentences, with the primary English statement first and a redundant Chinese translation second. It is front-loaded, uses no filler, and each part serves a purpose (the Chinese aids multilingual intent recognition).

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 a mutation with no output schema and no annotations. The description does not explain what happens after deletion, whether the action is reversible, or any prerequisites. Context such as the need to have an existing attachment ID or the impact on the event would improve completeness, but these are 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?

The schema provides descriptions for both parameters ('Event ID.' and 'Attachment ID.'), yielding 100% coverage. However, these descriptions are tautological with the parameter names. The tool description itself adds no further meaning about where to find these IDs or how they relate, but since the schema covers them, the baseline of 3 is appropriate.

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

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

The description clearly states the action: 'Delete an attachment from a calendar event.' It uses a specific verb and resource, distinguishing it from siblings like mail_delete_attachment and calendar_list_attachments. The Chinese intent phrase reinforces the purpose without adding ambiguity.

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 provided on when to use this tool versus alternatives. For example, it does not mention that one first needs to obtain attachment IDs via calendar_list_attachments, or that deletion is permanent. There is no exclusion or alternative context, leaving the agent to infer usage solely from the name and 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?

With no annotations, the description must disclose behavior fully. It does state the significant side effect that deleting the calendar also deletes its events, which is useful. However, it does not mention irreversibility, permission requirements, or other potential impacts like shared access removal, leaving gaps in 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 core description is a single, front-loaded sentence: 'Delete an additional calendar and its events.' It is concise and free of fluff. The Chinese intents line is a compact, purposeful addition for multilingual support without 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 delete operation with one parameter, the description is mostly complete. It covers the primary action and the cascade to events. However, it lacks an explicit warning about permanence or any prerequisites. Since there is no output schema and the main effect is clear, it is reasonably complete but could be stronger.

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 input schema provides 100% coverage with a clear description for calendarId ('Calendar ID to delete.'). The tool description adds no further meaning, format, or usage detail for the parameter. Per the rubric, with high schema coverage, a baseline of 3 is appropriate.

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

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

The description clearly states the tool's action with a specific verb ('Delete') and resource ('calendar'), and adds the key detail that it also deletes the calendar's events. This distinguishes it from sibling tools like calendar_delete_event and calendar_update_calendar. The qualifier 'additional' also hints at scope, making the purpose 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?

The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention that deleting individual events should use calendar_delete_event, nor does it state restrictions (e.g., primary calendar cannot be deleted). The context is implied but not spelled out, leaving the agent to infer usage.

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 exist, so the description must disclose behavioral traits. It mentions the delegated Calendars.ReadWrite requirement, but does not state that deletion is irreversible or clarify whether it affects the whole series or a single occurrence. For a destructive operation, this is insufficient.

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 extremely concise, with three short sentences: purpose, permission requirement, and Chinese intent aliases. Every sentence earns its place with no wasted 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?

Although the tool is simple (one parameter, no output schema), the description fails to distinguish 'delete' from the closely related sibling 'calendar_cancel_event'. It also doesn't mention whether deletion is permanent or affects only specific event types, leaving ambiguity for the agent.

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 input schema provides 100% coverage with a clear description for 'eventId' ('Calendar event ID.'). The description adds no additional parameter context beyond the schema, 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 clearly states the action ('Delete a calendar event') with a specific verb and resource. However, it does not differentiate from the sibling tool 'calendar_cancel_event', which likely performs a similar operation. This gives clear purpose but no 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?

There is no guidance on when to use this tool versus alternatives like 'calendar_cancel_event'. The description only states a permission requirement, not usage context 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?

With no annotations, the description carries the full burden. It discloses that this is a read operation and requires delegated Calendars.Read permission, which is valuable. However, it provides no detail on error behavior, response contents, or other side effects, which is a gap 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 compact two sentences plus Chinese examples, with every piece earning its place. It conveys purpose, permission, and language support without 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 simple single-parameter read tool, the description provides good coverage: purpose, permission, and Chinese alternatives. It lacks a pointer to how to obtain the eventId (e.g., via calendar_list_events) and what 'details' includes, but the absence of an output schema reduces the need. Overall, 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?

The schema already provides 100% coverage of the single parameter (eventId described as 'Calendar event ID'). The description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description clearly states 'Read details for a calendar event' with a specific verb and resource. This distinguishes it from sibling tools like calendar_list_events (listing) and calendar_update_event (modifying). The Chinese intents further reinforce the purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The Chinese intents give examples of when to use it (view meeting details, read event), and the permission requirement is stated. However, it does not explicitly contrast with alternatives such as calendar_list_events or calendar_get_schedule, nor does it state when not to use it. This leaves usage guidance mostly 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?

No annotations are provided, so the description carries the full burden. It discloses a permission requirement ('requires delegated Calendars.Read') and a regional support constraint ('Supported in 21V'), which is valuable. However, it does not describe the return format, behavior when no availability exists, or any error conditions, leaving meaningful gaps.

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 compact: two sentences cover the core function and constraints, followed by concise Chinese intent examples. Every sentence adds value, and the key information 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?

Given the tool has 4 parameters, nested objects, and no output schema, the description provides a decent overview but fails to mention the response shape or edge cases such as empty requests. It is adequate for a read-only query tool but not fully complete without 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?

Schema description coverage is 100%, so the baseline is 3. The description adds minimal extra context by mentioning 'users, rooms, or distribution lists' which maps to the 'schedules' parameter, and 'time range' aligning with start/end, but it does not provide deeper semantics than the schema already offers.

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 'Get free/busy availability for users, rooms, or distribution lists in a time range' with a specific verb and resource, clearly distinguishing it from sibling calendar tools like list_events or list_view. It also provides Chinese intent phrases, reinforcing its purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description conveys clear use cases (checking availability for coworkers/rooms, finding common free time) but does not explicitly exclude alternatives or name when to prefer this over calendar_list_events. It implies usage context well but lacks explicit when-not-to-use 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?

With no annotations provided, the description carries the burden. The phrase 'attachment metadata' explicitly indicates that actual file content is not retrieved, and 'List' implies a non-destructive read operation. While it omits details like auth requirements or error behavior, this is a reasonable disclosure for a read-only list 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, front-loaded sentence that directly states the purpose. The additional Chinese intents are helpful for multilingual contexts but are somewhat redundant; still, the overall structure is tight and 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 tool with one parameter and no output schema, the description adequately conveys the action and output type ('attachment metadata'). It does not detail the metadata fields, but given the low complexity, this is 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 100% with a single 'eventId' parameter described as 'Event ID'. The tool description adds no extra meaning beyond aligning the parameter with 'calendar event', so it meets the baseline of 3 for high schema 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 uses a specific verb 'List' and clearly identifies the resource as 'attachment metadata for a calendar event'. This distinguishes it from sibling tools like mail_list_attachments and calendar_add/delete_attachment, making the purpose 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?

Usage context is implied: the tool is used when one wants to see attachment metadata for a calendar event. However, it does not explicitly mention when to use it over alternatives or provide exclusions, relying on the reader to infer from the sibling tool 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?

The description discloses that it requires delegated Calendars.Read and operates on the signed-in user's data, which is useful context. However, it does not explain default behavior for the optional 'top' parameter, ordering, or what happens if no calendars exist, so it only partially covers behavioral 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?

The description is brief and front-loaded with the primary action, followed by the permission requirement and multilingual hints. Every sentence serves a purpose, and it avoids 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?

The description covers the purpose and permission clearly, but lacks details on default behavior and return format, especially since there is no output schema. The optional 'top' parameter's default value is not explained, leaving some ambiguity for a 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 schema fully documents the single 'top' parameter with description, min, max, so schema coverage is 100%. The description adds no additional meaning about the parameter, so baseline score of 3 is appropriate.

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

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

The description explicitly states 'List calendars for the signed-in user' with a clear verb and resource, and the title reinforces it. This clearly distinguishes it from sibling tools like calendar_list_events that handle events rather than calendars.

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 clear context: listing the signed-in user's calendars, with a permission requirement. It does not explicitly mention alternatives or when not to use it, but the scope is unambiguous, earning a 4 rather than a 3.

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

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

With no annotations, the description carries the full burden of behavioral disclosure, but it only states the basic function. It does not describe return value shape, timezone handling, limitations (e.g., max instances), or behavior for non-recurring events.

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 core description is concise and front-loaded. The additional Chinese intent phrases ('查看重复会议实例', etc.) may aid multilingual intent matching but are somewhat redundant for an AI agent evaluating tool semantics.

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 list operation with fully covered parameters and no output schema, the description is minimally viable. However, it lacks context around edge cases (e.g., non-recurring events), timezone behavior, and result ordering, which could matter for 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 100%, so parameters are well-documented in the schema. The description aligns with the startDateTime/endDateTime fields but adds no additional semantic value 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 uses a specific verb+resource structure ('List occurrences of a recurring event in a date-time range') and clearly distinguishes this tool from sibling calendar tools like calendar_list_events or calendar_get_event by focusing on recurring event instances.

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 provided on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or cases where other calendar tools would be more appropriate.

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 burden. It adds useful context by mentioning 'Requires delegated Calendars.Read' and clarifies scope to 'the signed-in user.' However, it doesn't disclose response format, sorting, pagination, or how 'upcoming' is determined (beyond what schema params imply).

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 concise and front-loaded with the main action. It includes usage, permission, and multilingual hints in a compact format. The Chinese intent list adds some length but is useful for multilingual contexts and doesn't detract significantly.

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 list tool with two well-documented parameters and no output schema, the description covers key aspects: scope, usage, permissions, and intent. It is not missing critical information 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?

Schema description coverage is 100%, and both parameters (top, daysAhead) have clear descriptions. The tool description does not add additional meaning beyond what the schema already provides, so baseline 3 is appropriate.

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

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

The description clearly states 'List upcoming calendar events for the signed-in user' with a specific verb and resource. It distinguishes itself from sibling tools like calendar_list_calendars (list calendars) and calendar_get_event (single event) by focusing on upcoming events for the signed-in user.

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?

Explicit guidance is provided: 'Use for today, this week, or upcoming meeting queries.' This gives clear context for when to invoke the tool. It doesn't explicitly name alternatives but the usage context is sufficient for an agent to select 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?

No annotations are provided, so the description carries this burden. It adds useful behavioral details: 'Requires delegated Calendars.Read' and expansion of 'single and recurring event instances.' However, it does not disclose pagination behavior, response format, or explicitly confirm there are no side effects beyond the verb 'List.'

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 compact and front-loaded: a clear core statement, a required permission, and a brief Chinese intent list. Every part earns its place, and the Chinese intents add useful multilingual guidance without bloating the text.

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 list operation with full schema coverage, the description is sufficiently complete: it states purpose, scope, and permission. The lack of an output schema and absence of explicit return-shape/pagination details create minor gaps, but not enough to significantly hinder an agent.

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 input schema has 100% description coverage for all four parameters, including formats and defaults. The tool description adds no parameter-level meaning beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description states 'List single and recurring event instances in an explicit date-time range,' which uses a specific verb, resource, and scope. It clearly distinguishes itself from sibling tools like calendar_list_events or calendar_list_event_instances by emphasizing both recurrence expansion and explicit range.

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 clear context for when to use this tool: when listing event instances across an explicit date-time range. It also adds an auth prerequisite ('Requires delegated Calendars.Read'). However, it does not explicitly name alternatives or state when not to use it, so it stops short of 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, the description carries full responsibility for disclosing side effects. It mentions the required permission but fails to state that this is a write operation that mutates the event, may notify the organizer, or that sendResponse defaults to true. This is insufficient 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 two sentences, front-loaded with the core action, and includes only essential information: the action, permission, and Chinese equivalents. There is no redundancy or filler, so 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?

The description provides the essential purpose and permission, while the schema covers parameter details. However, it lacks usage guidelines versus alternatives, omits behavioral consequences (e.g., organizer notification), and there is no output schema or return value information. These gaps make it minimally viable, not fully 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 100%, so baseline is 3. The description adds value by mapping Chinese intents (接受会议邀请, 拒绝会议邀请, 暂定会议) to the response enum values, aiding interpretation of non-English requests. This goes beyond the schema's plain descriptions and helps with parameter selection.

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 explicitly identifies the action (accept, tentatively accept, or decline) on a meeting invitation, making it clear what the tool does. It distinguishes itself from sibling calendar tools like create/update/cancel event by focusing on the 'respond' action, and the addition of Chinese intents further clarifies 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?

The description states a required permission (delegated Calendars.ReadWrite) but does not explicitly say when to use this tool versus alternatives. No exclusions or alternative tool references are provided, so usage context is implied by the name and sibling list rather than clearly described.

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

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

With no annotations, the description carries the full burden. It indicates a mutating rename action but does not disclose potential side effects, permission requirements, reversibility, or whether the calendar ID changes. This is a significant transparency gap for a write operation.

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 sentences, front-loaded with the English purpose and followed by a Chinese translation. It is concise and free of fluff; the Chinese addition is a useful localization but somewhat 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 simple rename tool with two well-documented parameters and no output schema, the description covers the basic purpose. However, the absence of annotations and behavioral details like error cases or effects on sharing make it only minimally complete.

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

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

The input schema has 100% coverage for both parameters, so the baseline is 3. The description adds minimal value beyond the schema, only clarifying the calendarId refers to a signed-in user's calendar. It does not explain how to obtain the calendarId or additional context.

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 'Rename one of the signed-in user calendars' with a specific verb and resource, clearly distinguishing it from create/delete calendar operations and event updates. The title 'Rename Calendar' reinforces the purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It implies usage on the signed-in user's own calendars, but provides no explicit when-to-use or alternatives. It does not reference sibling tools such as calendar_create_calendar or calendar_delete_calendar, so guidance is only 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?

With no annotations, the description carries the full burden. It does disclose the partial-update behavior and the required permission (delegated Calendars.ReadWrite), which are valuable. However, it omits potential side effects such as attendee notifications, and does not describe return values or error behavior, leaving gaps for a no-annotation, no-output-schema 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 appropriately sized and front-loaded. The core action ('Update a calendar event') appears first, followed by the patch semantics, permission requirement, and compact Chinese intent list. Each element earns its place without verbosity 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?

For a tool with 8 parameters, nested start/end objects, no annotations, and no output schema, the description covers the primary purpose, patch semantics, and permission but leaves out return value details, attendee notification behavior, and potential constraints (e.g., whether start/end must be updated together). The schema handles parameter documentation well, but the overall operational context is incomplete.

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 adds meaningful semantics beyond the schema by stating 'Provide only the fields to change', which clarifies that unspecified fields remain untouched—a key intent for PATCH-style operations. This goes beyond the per-field 'New ...' descriptions 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 clearly states the action with a specific verb and resource: 'Update a calendar event'. The phrase 'Provide only the fields to change' further distinguishes it from create/delete/cancel operations and clarifies the partial-update semantics. The listed Chinese intents (修改会议, 更新日程, etc.) reinforce the intended use case.

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?

'Provide only the fields to change' implies the tool is for modifying existing events rather than creating or deleting them, and the Chinese intent examples offer clear user-phrase triggers. The mention of 'Requires delegated Calendars.ReadWrite' gives a prerequisite, but it does not explicitly state when not to use this tool or compare it to siblings like calendar_update_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?

With no annotations provided, the description carries the burden of behavioral disclosure. It reveals crucial traits: the token is user-bound, one-time, and short-lived, and the tool never grants approval. However, it does not explicitly state potential side effects (e.g., whether the operation is destructive) or error behavior, which would add further 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 English text is concise, with two sentences that efficiently communicate purpose and usage. The addition of a Chinese translation line is redundant for an AI agent but does not harm clarity; it merely adds a bit of length. Overall, it is well-structured and free of 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 tool with one parameter, no output schema, and no annotations, the description is fully contextual. It explains the exact flow (pending operation, web preview approval, token constraints), the precondition, and the tool's non-approval role. There are no significant gaps that would hinder 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?

The schema describes confirmToken as 'One-time token returned by the pending operation,' but the description adds meaningful semantics: the token is user-bound, short-lived, and must belong to the same signed-in user who approved the preview. This goes beyond the schema's basic type/role information.

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 function: 'Continue a pending sensitive operation after the same signed-in user approved its web preview.' This specifies the verb (continue), the object (pending sensitive operation), and the condition (after user approval), which distinguishes it from sibling tools like auth_complete_device_login that handle login flows, not operation execution.

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 explicit usage guidance: 'Call it only after the user says the confirmation page was approved' and 'This tool never grants approval itself.' This gives a clear when-to-use condition and a when-not-to-use (it does not approve), which is sufficient for an agent to decide when to invoke 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?

With no annotations provided, the description carries the full burden. It discloses the permission requirement and the user scope, which is useful. However, it omits behavior like return value, default folder, or error conditions, leaving some important aspects unspecified.

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 extremely concise: two sentences. The first sentence states the action and permission, and the second provides Chinese intent synonyms. Every part serves a purpose, with no 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 simple create operation with all optional parameters, the description covers the core purpose, scope, and permission. It leaves out details like the destination folder and return value, but these are partially inferable from the sibling tool list and the 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?

The input schema has 100% property description coverage, so all 8 parameters are already documented. The description adds no additional parameter semantics, so the baseline score 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 clearly states it creates a mailbox contact for the signed-in user, using a specific verb and resource. It distinguishes itself from sibling tools like contacts_create_folder and contacts_update, and the Chinese intent mapping reinforces the purpose across languages.

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 context by specifying the target (signed-in user) and the required permission (delegated Contacts.ReadWrite), helping an agent decide when to use this tool. However, it does not explicitly mention exclusions or alternative tools, so it stops short of 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 only says 'personal' folder, but does not mention side effects, permissions, return values, or any requirements. For a create operation, this is a minimal disclosure and misses opportunities to clarify behavior beyond the obvious action.

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: an English statement and a Chinese translation. Both are concise, front-loaded with the main action, and contain no redundant information. It is appropriately sized for the tool's simplicity.

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 with one parameter and no output schema, so the description is minimally sufficient. However, the lack of annotations means more context would be helpful, such as prerequisites or when to use it. The current description is adequate but does not exceed expectations for a simple create tool.

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

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

Schema description coverage is 100% for the sole parameter displayName, which is clearly described as 'Contact folder name.' The description adds no extra parameter information, but the baseline of 3 applies because the schema already handles the semantics.

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 'Create a personal contact folder' with a specific verb and resource, distinguishing it from sibling tools like contacts_create (creating a contact) and contacts_delete_folder (deleting a folder). The Chinese intents are an additional language clue, enhancing clarity.

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 tool is used when creating a contact folder, but it does not explicitly discuss alternatives or provide exclusion criteria. No guidance is given on when to use this versus other folder-related tools, though the name and context make it somewhat 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?

No annotations are provided, so the description carries the burden. It discloses the required permission (delegated Contacts.ReadWrite) and scope (signed-in user's mailbox contact), which is helpful. However, it does not mention that deletion is irreversible or describe any side effects, which would strengthen transparency for a destructive operation.

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 concise and front-loaded: the core action is in the first sentence, the permission requirement in the second, and multilingual intents are appended without clutter. Every sentence adds value and the overall length is appropriate for a simple delete 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?

Given the tool's simplicity (one required parameter, no nested objects, no output schema), the description covers the essential context: what is deleted, for whom, and under what permission. It lacks an explicit irreversibility warning, but for a basic delete operation, the provided information 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?

The schema already fully documents contactId with the description 'Contact ID.' (100% coverage), so the baseline is 3. The tool description adds minimal param-specific meaning beyond confirming the contact belongs to the signed-in user's mailbox, which is a slight enhancement but not substantial.

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 specifies the verb and resource: 'Delete a mailbox contact for the signed-in user.' It also explicitly distinguishes this from sibling tools like contacts_delete_folder by naming 'mailbox contact,' and the included Chinese intents reinforce the intended action.

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 clear context: it targets the signed-in user's mailbox contact and requires delegated Contacts.ReadWrite permission. It does not explicitly mention alternatives or when-not-to-use, but the purpose is specific enough that an agent can select it appropriately among siblings like contacts_update or contacts_delete_folder.

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 must disclose behavioral traits. It states the deletion but omits critical consequences such as whether contacts inside the folder are also deleted, whether the action is reversible, or whether specific 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 extremely concise: one English sentence and one Chinese localization sentence. Both are purposeful and the key action 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 one-parameter tool with no output schema and no annotations, the description is too sparse. It fails to mention important operational context such as cascading deletion of contained contacts or irreversibility, leaving the agent without sufficient information to anticipate consequences.

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 input schema fully describes folderId as 'Contact folder ID to delete' with 100% coverage. The description adds no additional parameter meaning, so the baseline score 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 and resource: 'Delete a personal contact folder.' This clearly distinguishes it from sibling tools like contacts_create_folder, contacts_update_folder, and contacts_delete.

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 on when to use this tool versus alternatives, nor are any prerequisites, exclusions, or context provided. The description only states the action without explaining typical use cases.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It only states 'Read complete details', which conveys a read-only operation, but does not clarify error handling, permission requirements, or what 'complete details' entails. This is minimal disclosure 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 extremely concise with the main action front-loaded in the first sentence. The added Chinese intent mapping is a minor extra but does not add fluff. 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?

The tool is simple (one parameter, no output schema), and the description explains the core purpose. However, it does not describe return value structure or any edge cases (e.g., non-existent contact), leaving the agent without full context for what to expect.

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 for contactId is 100% with a basic description ('Contact ID'). The tool description adds context that it's for a personal contact, which is marginal. Since the schema already documents the parameter, baseline 3 is appropriate.

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

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

Description uses a specific verb ('Read') and clearly defines the resource ('complete details for one personal contact'). This distinguishes it from sibling tools like contacts_list and contacts_search, which are for listing and searching, not fetching a single contact's full details.

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 for a single contact detail lookup, but it does not explicitly state when to choose this tool over alternatives such as contacts_list or contacts_search, nor does it mention exclusions or prerequisites like having a valid contactId.

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 burden of behavioral disclosure. It notes the required delegated Contacts.Read permission, which is useful, but it does not mention pagination, sorting, or potential errors. The read-only nature is implied but not explicitly stated.

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 compact: one English sentence with purpose and permission, followed by Chinese intent examples. It is front-loaded and every part adds value, with 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?

The tool is simple with one parameter and no output schema, but the description lacks explicit clarification about scope (e.g., whether it includes contacts from all folders) and does not differentiate it from contacts_list_folder_contacts. It is adequate but could be more complete given the sibling 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?

The schema already provides full description for the only parameter 'top' (range 1-100), so baseline is 3. The description does not add extra semantic meaning beyond the schema, which is acceptable given high schema 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 clearly states the tool's purpose: listing mailbox contacts for the signed-in user. It uses a specific verb ('List'), resource ('mailbox contacts'), and scope ('for the signed-in user'), distinguishing it from folder-specific or search 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 description implies usage when a user wants to see their own contacts, but it does not explicitly provide alternatives or exclusions (e.g., for folder-scoped contacts, use contacts_list_folder_contacts). The permission requirement and multilingual examples give some context, but no direct comparison to siblings.

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 states the basic operation but adds no details about behavior such as whether it returns only direct folder members, if pagination is needed, or if any side effects occur. The description is minimal and largely redundant with the tool name.

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. The additional Chinese intent phrases add some bulk but are not excessive, and the main sentence is efficient. It is not overly verbose, meriting a score above the minimum.

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 list operation, the description covers the core purpose, and the schema fully documents parameters. However, it lacks any usage guidance or behavioral context beyond what the tool name implies, so it is only minimally complete for effective tool selection.

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 'top' and 'folderId' documented in the input schema. The description does not add additional meaning to these parameters beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description clearly states the action: 'List personal contacts in a selected contact folder.' This specifies the verb (list), the resource (personal contacts), and the scope (in a selected folder), distinguishing it from sibling tools like contacts_list (lists all contacts) and contacts_list_folders (lists folders).

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 provided on when to use this tool versus alternatives. It does not mention contacts_list, contacts_search, or contacts_list_folders, nor does it give any context about prerequisites or exclusions. The Chinese intents merely offer synonyms for the same action, providing no usage differentiation.

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 must carry the full burden of behavioral disclosure. It only states 'List personal contact folders' and does not describe the return format, whether system folders are included, pagination behavior, or authentication requirements. This is a minimal description with no additional 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?

The description is very concise, with a single English sentence and a Chinese translation. The Chinese text repeats the meaning and may be useful for multilingual intent matching, but it is not essential. Overall, the description is front-loaded and wastes no 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?

Given the simplicity of the tool (one optional parameter, no output schema), a basic description might suffice, but this one omits any indication of what the returned data looks like or how the response is structured. It also doesn't clarify the exact scope of 'personal contact folders' or if it excludes shared contacts. The description meets the minimum viable standard but lacks contextual richness.

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 sole parameter 'top' is fully documented in the schema with a description ('Number of folders to return') and constraints (minimum 1, maximum 100), providing 100% schema coverage. The tool description adds no further semantic meaning to this parameter, so the baseline score of 3 is appropriate.

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

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

The description uses the specific verb 'List' with the resource 'personal contact folders', clearly distinguishing the tool from sibling tools like contacts_list_folder_contacts which lists contacts within a folder. The scope 'personal' disambiguates from shared or public folders.

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 no explicit guidance on when to use this tool versus alternatives. It does not mention that contacts_list_folder_contacts is for contacts within folders, nor does it state any prerequisites or exclusion criteria. The tool's name partially implies its use case, but the description itself lacks usage direction.

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 must carry the full burden. It only says 'search personal contacts by name prefix' without disclosing read-only nature, case sensitivity, pagination, or error behavior. The Chinese intent examples do not add behavioral 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 concise with two sentences, the first being the core functionality. The second sentence lists Chinese intents, which is extra but not harmful; however, it could be seen as slightly unnecessary. Overall, it is front-loaded and 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 search tool with fully described schema, the description is minimally adequate. It does not describe return values (no output schema) or usage context, nor does it mention alternatives. However, the purpose is straightforward, so it is not severely incomplete.

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 baseline is 3. The description repeats 'name prefix' but adds no additional meaning beyond what the schema already provides for query and top 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?

The description clearly states the tool searches personal contacts by name prefix, which is a specific verb and resource. It distinguishes from sibling tools like contacts_list or contacts_get by detailing the search scope (personal contacts) and method (prefix).

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 does not mention when to use this tool instead of alternatives such as contacts_list or contacts_get. It gives no explicit context, exclusions, or alternative recommendations. The only hint is the prefix search nature, which implies use for partial name lookups, but this is not 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?

With no annotations, the description carries the behavioral disclosure. It explains the permission requirement, the partial-update semantics, and that it applies to the signed-in user's mailbox. It does not detail return values or error behavior, but the essential mutation behavior is 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?

The description is two concise sentences plus a compact Chinese intent line. It front-loads the purpose, adds a critical usage guideline, and includes the permission note without unnecessary 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 description, combined with the fully documented schema, gives enough context for correct invocation. It covers permission, scope, and partial-update semantics. It lacks output/error details but this is acceptable given no output schema and the tool's relative simplicity.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by stating that only the fields to change need to be provided, which clarifies the optionality and partial-update behavior beyond what the schema's individual field descriptions offer.

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 updates a mailbox contact for the signed-in user, using a specific verb and resource. It distinguishes from sibling tools like contacts_create and contacts_delete, and explicitly notes partial updates with 'Provide only the fields to change.'

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?

Clearly indicates this is for updating an existing contact and mentions the required delegate permission (Contacts.ReadWrite). It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent to select this tool over creation/deletion commands.

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 only says 'Rename a personal contact folder.' It does not disclose behavioral traits such as whether the rename is permanent, whether it affects existing contacts, or if any special 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 stating the operation, followed by a concise Chinese translation. It is appropriately sized and every word contributes to clarity.

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 with two self-explanatory parameters and full schema coverage, so the description is minimally sufficient. However, it lacks contextual details such as whether the folder must be a personal folder vs. a system folder, or any side effects, so it is not fully complete.

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

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

The input schema provides full coverage with descriptions for both parameters (folderId and displayName), so the description does not need to add much. However, the description adds no additional parameter-level meaning beyond what the schema already states, meriting a 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 (rename) and the object (personal contact folder), distinguishing it from sibling tools like contacts_create_folder and contacts_delete_folder. The Chinese translation reinforces the same intent without ambiguity.

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 no guidance on when to use this tool versus alternatives such as creating or deleting a folder. It does not mention any prerequisites, exclusions, or context in which renaming is appropriate.

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 an important behavioral trait: the copy is asynchronous and may return an operation monitor URL. Since no annotations are provided, this partially fulfills the transparency burden. However, it omits details about permissions, error handling, and whether the copy preserves metadata.

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 concise and front-loaded with the core purpose. The Chinese intent lines are redundant for an English-only workflow but do not significantly bloat the description. One extra sentence could be trimmed, but overall it is 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 moderately simple asynchronous copy tool, the description covers the primary behavior (async, monitor URL) and all parameters are fully documented in the schema. It could add caveats about long-running operations or failure modes, but it is sufficiently complete 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?

The input schema already covers all parameters with descriptions at 100% coverage, so the baseline is 3. The description does not add alternative meanings or nuances; it only restates the target folder concept in prose.

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 specifies the action ('Copy'), the resource ('OneDrive file or folder'), and the destination ('to another folder'). It also notes asynchronous execution, which distinguishes it from synchronous copy tools and from sibling tools like move or rename. The Chinese intents reinforce 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?

The description provides clear context for when to use the tool: when duplicating an item to another folder. It does not explicitly mention alternatives or exclusions, but the copy vs. move distinction is implicit via the verb and the sibling tool names (drive_move_item).

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

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

With no annotations, the description carries the full burden. It usefully discloses the delegated Files.ReadWrite permission and target location, but it omits behavior around name conflicts (despite the schema enum), return values, and 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 core description is concise and front-loaded with the action and target. The Chinese intent line adds a bit of length but serves a clear multilingual purpose. No redundant 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 create operation with a well-described schema, the description is serviceable. However, without an output schema, it does not mention return object shape, and it lacks explicit sibling differentiation or conflict-behavior caveats, leaving moderate 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 100% with descriptions for all parameters, so the baseline is 3. The description adds context about root/parent location that maps to parentItemId, but it does not add significant syntax or format details 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 uses a specific verb ('Create') and resource ('folder in the signed-in user OneDrive root or under a parent folder'), clearly distinguishing it from sibling tools like mail_create_folder, contacts_create_folder, and sharepoint_create_drive_folder by 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?

It clearly states the intended context (signed-in user's OneDrive, root or parent folder) and the required permission. However, it does not explicitly mention when not to use it or contrast with sharepoint_create_drive_folder, so it falls short of 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?

No annotations are provided, so the description carries the burden. It discloses the required permission and that 'actual sharing scope depends on tenant policy.' However, it does not mention what the response contains (e.g., the share link URL), side effects, or any limitations beyond permission. Given the lack of annotations, this is partial disclosure but not fully 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 compact: three sentences in total. The first two sentences are information-dense, and the third provides Chinese intent mappings, which may be useful for multilingual agents though not strictly necessary. It is efficient and front-loaded with the primary purpose.

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

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

The tool has only three parameters, one required, and no output schema. The description covers the main use case, required permission, and a behavioral caveat. It does not describe the return value, but for a straightforward action like creating a share link, the key context is present. The Chinese intent line adds value for intent detection.

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 input schema has 100% coverage with descriptions for all three parameters, so the baseline is 3. The description adds no specific parameter-level detail beyond the schema, and the mention of 'file or folder' only loosely corresponds to itemId. No additional meaning is provided for type or scope enums.

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: 'Create a sharing link for a file or folder in the signed-in user OneDrive.' This distinguishes it from related siblings like drive_invite_item (which sends invitations) and sharepoint_create_share_link (which operates on SharePoint).

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 provides clear context by limiting scope to the 'signed-in user OneDrive' and notes the permission requirement (delegated Files.ReadWrite) and tenant policy dependency. However, it does not explicitly name alternatives or state when not to use this tool versus the similar sharepoint_create_share_link.

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 burden. It discloses the permission requirement, which is useful, but does not clarify whether deletion is permanent or goes to recycle bin, or any side effects on folder contents. This is a partial disclosure.

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 concise and front-loaded with the core purpose. The additional Chinese intent phrases add localization value but are not essential for the core understanding, slightly reducing 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 simple delete operation with one parameter, the description covers the core purpose, scope (OneDrive), and permission. It falls short of explaining permanence or error behavior, but these are less critical for such a straightforward 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 the itemId parameter fully with a description 'OneDrive item ID.' The tool description does not add further meaning to the parameter, so the baseline score of 3 is appropriate.

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

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

The description clearly states the action (Delete) and the resource (file or folder in the signed-in user OneDrive). It also distinguishes from sibling tools like sharepoint_delete_drive_item by specifying OneDrive.

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 clear context: it's for the signed-in user's OneDrive, and it mentions the required delegated permissions (Files.ReadWrite). However, it does not explicitly state when not to use it or name alternatives (e.g., sharepoint_delete_drive_item), so it lacks exclusion 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It usefully states that output is base64 and that the MCP response is limited to 10 MB, which is critical for size expectations. However, it does not mention permissions, read-only status, or failure behavior on missing/invalid item IDs, leaving room for more 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 core behavior and the 10 MB limitation are stated in the first two sentences, keeping the most important information front-loaded. The third sentence with Chinese intent alternatives is somewhat extra but serves multilingual intent recognition without being verbose. Overall the description is compact and free of unnecessary 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 download tool with no output schema, the description explains the return format (base64), the key constraint (10 MB), and the resource type (OneDrive file), which is enough for invocation. It does not cover error handling or large-file alternatives, but the simplicity of the tool makes this acceptable.

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 fully documents the only parameter itemId as 'File item ID', giving 100% schema coverage. The description does not add additional parameter-level meaning or format guidance beyond what the schema already provides. The baseline of 3 is appropriate since the schema carries the parameter semantics.

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 'Download a OneDrive file' – a specific verb and resource – and further clarifies it returns base64 bytes. This distinguishes it from metadata tools like drive_get_item and from sharepoint_download_file by scoping to OneDrive. The added Chinese intent examples reinforce the purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for downloading file content, but it does not explicitly state when to prefer this tool over siblings like drive_get_item or sharepoint_download_file. It also does not mention exclusions such as files larger than 10 MB being unsuitable. The Chinese intent mapping offers some context but no tool-selection 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?

With no annotations, the description must carry the burden for behavioral disclosure. It explicitly states 'Read', indicating a non-destructive, read-only operation. It also discloses the types of data returned (metadata, owner, type, quota). It does not mention potential edge cases like missing OneDrive or auth failures, but for a simple no-parameter read, the transparency is adequate and above average.

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 sentences: the primary English description and a Chinese intent list. Every word contributes value, and the structure is front-loaded with the core purpose. It is concise without being under-specified.

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 is a simple, zero-parameter read operation with no output schema, the description is complete. It states the main purpose and the key data returned (metadata, owner, type, quota). There are no hidden parameters or side effects to describe, and the explanation is sufficient for an agent to select and invoke 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?

The input schema has zero parameters, so the baseline is 4. There are no parameter semantics to explain. The description does not need to add parameter details, and it appropriately focuses on the return values instead.

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 function: 'Read signed-in user OneDrive metadata, owner, type, and quota.' It uses a specific verb ('Read') and identifies the resource (signed-in user's OneDrive). This distinguishes it from sibling tools like drive_list_root (lists files) or drive_get_item (gets a specific item), so purpose clarity is high.

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 clear context for when to use: to retrieve the signed-in user's OneDrive metadata, including quota. The Chinese intents ('查看我的OneDrive信息, 查看网盘容量, 查看OneDrive配额') reinforce these use cases. However, it does not explicitly mention alternatives or exclusions (e.g., use drive_list_root for files). Thus it has clear context without explicit comparisons, aligning with a 4.

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 must carry the transparency burden. It discloses the read-only nature and permission requirements, but does not describe the return format, whether folder metadata differs from file metadata, or any error conditions. This is adequate but not rich.

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 tight sentences plus an optional Chinese intent helper. It front-loads the primary purpose, includes a key permission detail, and has 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 tool with one parameter and no output schema, the description covers the essential context: what it reads, where (signed-in user OneDrive), and the required permission. It lacks explicit return-value details but 'metadata' implies what is returned, making this sufficient for a low-complexity 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 already describes the only parameter (itemId as 'OneDrive item ID from a list or search result') with 100% coverage. The description text adds no further parameter context, so the baseline score 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 ('Read metadata') and clearly identifies the resource ('file or folder in the signed-in user OneDrive'). This distinguishes it from sibling tools like drive_download_file (downloads content) and sharepoint_get_drive_item (uses SharePoint instead of OneDrive).

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 states the required permission ('delegated Files.Read') and implies a read-only usage context. It does not explicitly mention alternatives or when-not-to-use, but the scope is clear enough for an agent to choose this over download or list tools.

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 must carry the transparency burden. It clearly states the core side effect (granting read/write access) and the optional invitation. However, it does not disclose whether existing permissions are replaced, whether the caller needs special ownership rights, or what happens if recipients already have access. This is acceptable but not rich.

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 long, front-loaded with the core English action, and the Chinese intent mapping adds useful multilingual coverage without unnecessary verbosity. Every sentence earns its place.

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

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

Given the tool's moderate complexity, the 100% schema coverage, and the absence of an output schema, the description provides enough context for an agent to understand the action and its optional invitation behavior. It could be improved by noting how this relates to permission replacement or invite vs. share-link flows, but it is not incomplete for selection purposes.

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 adds semantic context by mentioning 'selected people' (recipients), 'read or write access' (roles), and 'optionally send an invitation' (sendInvitation), but it does not add detail beyond what the schema already provides for message, itemId, or requireSignIn.

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: 'Grant selected people read or write access to a OneDrive item and optionally send an invitation.' This uses a specific verb and resource, and the mention of OneDrive plus 'selected people' distinguishes it from sibling tools like drive_create_share_link (link-based sharing) and sharepoint_invite_drive_item (SharePoint-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?

The description does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions. For example, it does not clarify whether to prefer this over drive_create_share_link for link-based sharing or sharepoint_invite_drive_item for SharePoint items. Usage context is only implied by the action 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?

With no annotations, the description carries full behavioral burden, but it only states the action. It does not disclose that it returns immediate children, is a read-only operation, supports pagination via `top`, or what the response structure will be. This leaves the agent to infer core 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 primary sentence is concise and front-loaded. The Chinese intents line is redundant as a direct translation, but it may serve multilingual intent matching. Overall, the description is compact and efficient, though not maximally so.

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

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

The tool has no output schema and no annotations, so the description should explain what the response contains or how to use the results. It does not describe return fields, pagination limits beyond the `top` property, or any other context needed to make full use of the tool. This is a significant gap for a listing operation.

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 little beyond schema: it frames `parentItemId` as 'selected OneDrive folder' but does not clarify `top` or any parameter nuances. It is adequate but not additive 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?

The description states a specific verb ('List') and resource ('files and folders under a selected OneDrive folder'), clearly distinguishing it from sibling tools like `drive_list_root`, `drive_list_recent`, and `drive_search_items`. The Chinese intent line reinforces the same purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no explicit guidance on when to use this tool over alternatives, no exclusions, and no prerequisites. It merely implies usage by mentioning 'selected OneDrive folder', but does not describe navigation context or compare with other listing tools.

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 that it requires delegated Files.Read permission, which is useful. As a list operation, the verb implies read-only behavior, but it does not discuss other behavioral aspects such as response shape, pagination, or handling of empty permission lists.

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 additional Chinese intents. It is front-loaded with the core action and includes the auth requirement, but the Chinese translation section adds bulk without new information for English agents.

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 simple one-parameter tool, the description covers the purpose, auth scope, and general resource type. It does not specify return format, but the name and description imply the output is permission metadata; no output schema is 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?

The only parameter itemId is described in the schema as 'OneDrive item ID.' The description reinforces that it applies to a file or folder but adds no further semantics beyond the schema, so the baseline for full schema coverage 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 the specific verb 'List' with resource 'permission and sharing metadata for a file or folder in the signed-in user OneDrive', clearly identifying its scope. The mention of 'signed-in user OneDrive' distinguishes it from the SharePoint permission listing sibling (sharepoint_list_drive_permissions).

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 provided on when to use this tool versus alternatives. It states a required permission (Files.Read) but does not explain scenarios, prerequisites, or exclusions relative to similar tools.

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

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

No annotations are provided, so the description carries the full burden. It does add useful context by specifying that results are scoped to the signed-in user and filtered by recency. However, it does not disclose limitations such as whether only metadata is returned, how 'recent' is defined, or that this is a read-only operation beyond the verb 'List.'

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 primary sentence is a crisp, front-loaded definition of the tool's purpose. The Chinese intent variants add multilingual guidance without significant bloat, keeping the overall description compact 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?

For a single-parameter, read-only list tool, the description covers the essential semantics: resource, scope, and recency. With no output schema, it would be slightly stronger to describe the returned item shape, but the low complexity makes the current text reasonably complete.

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

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

The only parameter, `top`, is fully documented in the schema with the description 'Number of recent items to return,' providing 100% schema coverage. The tool description adds no parameter-specific meaning beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description begins with the specific verb 'List,' identifies the resource as 'files,' and clearly scopes it to 'recently used by the signed-in user,' which matches the title. This distinguishes it from related tools like drive_list_root, drive_list_children, and drive_search_items.

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 'recently used by the signed-in user' provides a clear retrieval context, making it apparent when this tool should be selected. It does not explicitly mention alternatives or exclusion cases, but the context is unambiguous and sufficient for a simple list operation.

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 indicates a read-only 'List' operation and discloses the specific auth requirement ('Requires delegated Files.Read'). It also specifies the user scope ('signed-in user'), which is valuable. It does not discuss pagination or output format, but these are less critical for a simple list operation.

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 front-loaded with the core purpose, followed by a permission note and a list of Chinese intent examples. The intent list is useful for multilingual agent routing and not excessive. Each sentence serves a distinct purpose, and the overall length is appropriate for the tool's simplicity.

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 one optional parameter and no output schema, the description adequately covers purpose, permission, and user-scope. It could mention that the result is limited to immediate children of the root or the optional top parameter, but those are already implied by the schema and the word 'root'. The Chinese intents enhance contextual completeness for language-driven 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?

The input schema already covers the only parameter (top) with a clear description and bounds. The tool description adds no additional meaning to the parameter, so the baseline of 3 for high schema coverage is appropriate.

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

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

The description states a specific action ('List files and folders') and a specific resource ('the signed-in user OneDrive root'), clearly distinguishing it from sibling tools like drive_list_children or drive_search_items. The scope is explicit: root of OneDrive for the signed-in user.

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 for root-level listing and includes Chinese intent phrases like '查看我的OneDrive' as examples of user queries that should route here. It also states the required permission (delegated Files.Read), providing a prerequisite. However, it does not explicitly contrast with alternatives such as drive_list_children or drive_list_recent.

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 transparency burden. It states the action ('List retained versions') but does not disclose additional behaviors such as read-only nature, permission requirements, pagination, or response format. The description adds minimal behavioral context beyond the tool name.

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 extremely concise, with a single clear sentence plus a useful Chinese intent translation. Both sentences add value; there is no wordiness 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?

The tool is simple with one parameter, but the absence of an output schema and annotations means the description should hint at return values or related tools. It does not explain what the list contains or how it connects to drive_restore_version, leaving some contextual 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?

The schema already provides 100% coverage for the single parameter (itemId) with a description. The tool description does not add any further explanation about the parameter, so it provides 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 specific verb+resource: 'List retained versions of a OneDrive file.' This clearly distinguishes it from the sibling tool sharepoint_list_drive_versions, which is for SharePoint. The included Chinese intents further clarify the tool's 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?

The description implies usage for OneDrive files, which differentiates it from the SharePoint counterpart. However, it does not explicitly mention alternatives or when-not-to-use scenarios, so it lacks full exclusionary 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?

With no annotations provided, the description carries the full burden. It usefully discloses the required delegated permission and the mutation implied by 'move.' However, it does not mention side effects like the item disappearing from the source folder or potential changes to sharing links, though these are somewhat inherent in the operation.

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 long, front-loaded with the primary English purpose and permission requirement, followed by helpful multilingual intent aliases. Every sentence adds value, with no wasted 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?

Given the tool's simplicity (2 parameters, no output schema), the description covers the core operation and permission context. It lacks an explicit statement about return values, but for a move action, the outcome is generally clear. The multilingual aliases enhance completeness for Chinese-speaking intents.

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% as both itemId and newParentItemId have concise descriptions. The description adds no additional parameter detail beyond what the schema already provides, so the baseline score of 3 is appropriate.

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

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

The description clearly states the tool moves a file or folder in the signed-in user's OneDrive to a new parent folder. It uses a specific verb and resource, and differentiates from siblings like drive_copy_item and drive_rename_item by explicitly indicating relocation.

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 clear context by specifying the scope (signed-in user's OneDrive) and a prerequisite (requires delegated Files.ReadWrite). It does not explicitly mention alternatives or exclusions, but the action is unmistakable, and the Chinese intent aliases help recognize relevant user requests.

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 the required delegated Files.ReadWrite permission, which is useful context. However, it does not describe behavioral expectations such as what happens on conflicts, whether the rename is reversible, or what the response contains. With no annotations, this leaves some gaps, but the tool's core behavior is straightforward.

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 concise and front-loaded with the action and resource. The Chinese intent line is purposeful for supporting Chinese queries and does not bloat the description unnecessarily. Every part serves a function.

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 tool with no output schema, the description adequately covers purpose, scope, and permission. It would be slightly more complete if it mentioned the response format or error behavior, but given the low complexity, the current content is largely 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?

The input schema provides complete descriptions for both itemId and newName, so the schema already covers parameter semantics. The description adds no additional parameter details beyond what is in the schema, making the baseline score of 3 appropriate.

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

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

The description clearly states the action 'Rename' and the resource 'file or folder in the signed-in user OneDrive'. It is specific and distinguishes from sibling tools like drive_move_item and sharepoint_rename_drive_item by indicating the OneDrive scope. The Chinese intent clarifies the purpose further for multilingual use.

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 clear context by specifying the signed-in user's OneDrive and the required permission, but it does not explicitly mention when to use this tool versus alternatives such as sharepoint_rename_drive_item. No exclusions or alternative recommendations are 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?

No annotations are provided, so the description carries the full burden. While 'restore' implies returning to a previous version, the description does not disclose that this overwrites the current version, is potentially irreversible, or requires specific permissions. This is a significant gap for a mutating operation, though the name gives a partial clue.

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 English sentence is concise and front-loaded, stating the action in one line. The additional Chinese intent list provides useful aliases for multilingual routing while remaining compact; no words are wasted.

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

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

The tool is simple (2 required params, no output schema), but because it performs a destructive restore and lacks annotations, the description should explain the effect on the current file and any prerequisites. The current description only states what it does, not the consequences, leaving a completeness 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?

The input schema already covers both parameters with clear descriptions (itemId and versionId from drive_list_versions), so the baseline is 3. The description adds no additional meaning beyond what the schema provides, merely referencing 'selected historical version' which maps to versionId.

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 ('Restore') and resource ('historical version of a OneDrive file'), clearly distinguishing it from sibling tools like drive_list_versions or drive_download_file. The Chinese intent aliases reinforce routing without ambiguity.

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 no guidance on when to use this tool compared to alternatives like drive_list_versions or drive_download_file. It does not mention that a version must first be selected from drive_list_versions, nor any exclusions such as file types or permission requirements. This lack of usage context makes it difficult for an agent to decide between related drive operations.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It reveals the required delegated Files.Read permission and the user scope (files visible to the signed-in user), which is useful. However, it does not clarify whether the search covers file content or just names, nor does it mention pagination or result format. This is somewhat thin for an unannotated 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 very concise: two short sentences, with the first conveying the core purpose and the second providing multilingual support hints. No wasted words, and the structure front-loads the essential 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 tool is simple (2 params, no output schema), and the description covers permission, user scope, and language support. However, it omits behavior around result ordering, whether full-text search is supported, and any error scenarios. Given the low complexity, this is adequate but not rich; a 3 reflects that the description does not fully stand alone.

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 for parameters is 100%, so the baseline is 3. The description adds a note about Chinese intents and '按文件名搜索' (search by filename), but this largely echoes the schema's phrase 'file name or document keyword.' It provides minimal additional semantic value 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 the tool's function with a specific verb ('Search') and a clearly defined resource ('files visible to the signed-in user in OneDrive'). It implicitly distinguishes from siblings like sharepoint_search_drive_items and search_files by scoping to the user's own OneDrive. The permission requirement adds further specificity.

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 clear context for when to use the tool: searching the signed-in user's own OneDrive files. It implies a distinction from SharePoint or general file searches, but does not explicitly name alternatives or state when not to use it. Since context is clear but exclusions/alternatives are not explicitly stated, a 4 is appropriate.

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?

Without annotations, the description effectively discloses key behavioral context: it requires delegated Files.ReadWrite permission and is intended for small files (implying size limitations). It does not mention overwrite/rename behavior or response format, but the schema covers conflictBehavior and the tool's purpose is not misrepresented.

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 concise sentences: purpose, size limitation/alternative, and permission requirement. The Chinese intent list is a useful add-on for multilingual agents and does not bloat the description. Front-loaded with the tool's primary function.

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 moderate complexity (5 params, no output schema) and lack of annotations, the description covers the essential context: what it does, when to use it, and required permissions. It omits the return value and exact size limit, but the schema and the small/large distinction provide adequate guidance for an agent.

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 parameters are fully documented in the schema. The description adds no extra parameter meaning beyond what the schema already provides (e.g., it doesn't explain the 'small' size threshold or clarify base64/text modes beyond schema definitions). Baseline 3 is appropriate.

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

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

Clearly states 'Upload a small file to the signed-in user OneDrive' with a specific verb (upload), resource (file to OneDrive), and scope (signed-in user). Contrasts with large-file upload sessions and identifies the target as OneDrive vs SharePoint, distinguishing it from 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?

Explicitly guides on when to use this tool ('small file') and when not ('Use upload sessions for large files'), providing an alternative. Also notes the required delegated permission (Files.ReadWrite), which is a prerequisite.

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 burden of disclosing behavior. It clearly labels the operation as 'Read', indicating a safe, non-destructive action, and lists the returned profile attributes. It does not mention auth prerequisites or error handling, but for a simple read-profile endpoint, the disclosure is adequate.

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 concise and front-loaded: the first sentence states the action and resource, the second gives usage context. The Chinese intent examples are a useful addition for multilingual support and do not bloat the 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?

This is a simple, zero-parameter tool with no output schema. The description fully covers its purpose, typical use cases, and return content. No additional context is necessary for an agent to select and 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?

The tool has zero parameters, so the baseline is 4. The description adds no parameter details because there are none to document, and the schema coverage is effectively complete.

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 ('Read') and resource ('signed-in user profile from Microsoft Graph /me'), clearly distinguishing it from sibling tools like users_get_profile by focusing on the current signed-in user. It also enumerates the exact data fields returned (email, display name, job title, department), making the purpose 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?

The description explicitly states when to use the tool: 'Use for questions about account identity, email address, display name, job title, and department.' It does not explicitly exclude alternatives like users_get_profile, but the 'me' scope is clearly implied, providing sufficient guidance for most cases.

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 adds useful context: 'including transitive membership' and 'up to 20 supplied group IDs.' However, it does not disclose the return format (e.g., list of matching group IDs vs. boolean per ID), error handling for invalid IDs, or authentication expectations. The description gives basic behavioral traits but lacks depth.

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 concise sentences: the core statement and a multilingual repetition. Every sentence serves a purpose, with no unnecessary fluff. The main information is front-loaded: 'Check which of up to 20 supplied group IDs contain the signed-in user, including transitive membership.'

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 simplicity (one parameter, no output schema), the description covers the key aspects: the action, the parameter scope, and the transitive membership behavior. It does not explicitly state the return value structure, but the phrase 'Check which... contain' implies the output will be the subset of supplied group IDs where the user is a member. This is reasonably complete for the 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?

The schema description for groupIds ('Group IDs to check.') is clear, and schema coverage is 100%. The tool description adds context about checking against the signed-in user and the limit of 20, but these are already present in the schema or are not additional semantics about the parameter's format or usage. Thus, the description provides minimal extra 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 clearly states a specific action: 'Check which of up to 20 supplied group IDs contain the signed-in user, including transitive membership.' This distinguishes it from sibling tools like groups_list_members (which lists members of a group) and users_list_memberships (which lists all memberships) by focusing on checking a supplied set of group IDs against the current user.

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 use case: when you have a set of group IDs and need to check if the signed-in user is a member, especially with transitive membership. However, it does not explicitly mention when to use this tool instead of alternatives like users_list_memberships or groups_list_members, nor does it state exclusions. Thus, the usage 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?

With no annotations provided, the description carries the burden of disclosing behavior. It clearly states 'Read details', indicating a read-only operation, which is useful. However, it does not describe the return format, the exact identifier format expected for groupId, or any potential error conditions, leaving gaps in behavioral 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 very short and front-loaded with the English purpose. The Chinese intent list adds length but serves a clear i18n purpose. Every sentence earns its place, though the intent list could be seen as slightly 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 simple one-parameter read operation, the description is largely sufficient when combined with the schema. It identifies the resource type and action. It lacks details on return shape and usage alternatives, but given the tool's simplicity, this is a minor gap rather than a critical omission.

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 describes groupId as 'Group ID' at 100% coverage, so the baseline is 3. The description adds context that the group is a Microsoft Entra or Microsoft 365 group, but does not specify the format (e.g., object ID, UPN, mail address) 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 uses a specific verb and resource: 'Read details for a Microsoft Entra or Microsoft 365 group.' This clearly distinguishes the tool from sibling group tools like groups_list, groups_list_members, and groups_list_owners, which focus on listing or membership operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance is given for when to use this tool versus alternatives. The description does not mention that groups_list can find group IDs, or that groups_list_members/owners are separate tools for specific group-related queries, so an agent gets no usage 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?

With no annotations, the description carries the burden of behavioral disclosure. It adds the important permission requirement (delegated GroupMember.Read.All) and confirms the filtering behavior, but does not disclose return format, pagination, or other potential 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?

The description is compact and front-loaded: purpose, filter option, permission, and localized intents in three sentences. Every sentence adds value without 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 list tool with two optional parameters and strong schema coverage, the description covers purpose, filter, and permissions. It does not explain return fields or pagination, but this is not critical for such a straightforward operation.

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 input schema already has 100% coverage with clear descriptions for both top and query. The description adds no additional parameter-specific details beyond restating the filter behavior, so a baseline score of 3 is appropriate.

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

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

The description states a specific action ('List') and resource ('Microsoft Entra security groups and Microsoft 365 groups'), clearly distinguishing from sibling tools like groups_list_members or groups_get. It also identifies the optional filter behavior.

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 context for when to use the tool (listing groups, optionally filtered by prefix) and related Chinese intents. It does not explicitly name alternatives or edge cases, but the context is clear enough relative to sibling tools.

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

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

With no annotations, the description carries the full burden. It discloses the 'direct members' scope and the additional tenant permissions for hidden-membership groups, which is useful. However, it does not mention return format, pagination, or default behavior when 'top' is omitted, leaving some transparency gaps.

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 three concise sentences: the core action, a permissions caveat, and Chinese intent variants. Every sentence earns its place with no fluff, and the key information 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 simple list tool with 100% schema coverage and no output schema, the description is nearly complete. It covers the core behavior and an important permission nuance. It could benefit from a brief note on the return shape, but that is not critical given the schema and tool simplicity.

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

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

Schema description coverage is 100%, and both parameters (groupId, top) have clear descriptions. The tool description adds no extra parameter semantics, so the baseline of 3 is appropriate.

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

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

The description clearly states 'List direct members of a group' – a specific verb and resource. The term 'direct members' differentiates from sibling tools like groups_list_owners and groups_get, making the tool's purpose 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?

The description implies usage through 'List direct members of a group' but provides no explicit alternatives or when-not-to-use guidance. The hidden-membership permission caveat adds context, but it doesn't direct users to other group-related tools for different needs.

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 must carry the full burden. It adds the scope of 'Microsoft Entra or Microsoft 365 group' but does not disclose return format, potential empty results, pagination behavior, or any permission requirements. Minimal behavioral detail is given beyond the core action.

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 additional Chinese intent phrases. Every part is purposeful and adds value, with no unnecessary 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?

The tool is simple with two parameters and no output schema. The description is sufficient for a basic list operation but could benefit from mentioning pagination, default top value, or typical return structure. Overall, it is adequate but not rich.

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 parameters (groupId, top) described. The description adds no additional parameter nuance, so the baseline of 3 applies as the schema already provides adequate 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?

The description clearly states 'List owners of a Microsoft Entra or Microsoft 365 group', using a specific verb and resource. It distinguishes from sibling tools like groups_list_members by focusing on owners, and is further reinforced by the title 'List Group Owners'.

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 provided on when to use this tool versus alternatives such as groups_list_members or groups_get. The Chinese intent phrases imply usage scenarios but do not explicitly exclude sibling tools or mention 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?

With no annotations available, the description carries the disclosure burden. It adds useful behavioral details like the 3 MB decoded size limit and the permission requirement. However, it does not mention the return value, error conditions, or that the action modifies the draft, which would be expected for a complete behavioral profile.

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 compact, with the core action in the first sentence, permission in the second, and a useful multilingual hint in the third. Every sentence adds value, and the structure is front-loaded with the primary purpose.

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 moderate-complexity tool with no output schema, the description covers the essential constraints (size, target, permission) and gives contextual intent phrases. It could be more complete by stating what the tool returns or what happens on failure, but it is sufficient for understanding the tool's primary function.

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 parameters are already well documented in the schema. The description's mention of 'base64-encoded file under 3 MB' aligns with the contentBase64 property description, but adds no new meaning beyond what the schema already provides. The baseline of 3 is appropriate.

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

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

The description uses a specific verb 'Add' and resource 'base64-encoded file to an existing draft message', clearly distinguishing this from sibling tools like mail_send_draft, mail_list_attachments, and calendar_add_file_attachment. It also provides Chinese intent phrases to aid recognition.

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 clearly states the target context: adding a file to an existing draft message. It mentions the permission requirement (delegated Mail.ReadWrite) which helps agents know when the operation is allowed. However, it does not explicitly list alternatives or exclusions, such as not using this for calendar attachments.

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 discloses the required delegated Mail.ReadWrite permission, which is a critical behavioral trait. The verb 'copy' implies the original remains, but it does not explicitly mention side effects or reversibility. The auth disclosure is a valuable 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?

The description is concise: one main sentence, one permission note, and Chinese intents. It is front-loaded with the action and contains no fluff or redundant 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 simple two-parameter tool with no output schema, the description covers the core action, the permission requirement, and language variations. It does not explain return values or edge cases, but these are not essential given the tool's simplicity.

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

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

The input schema has 100% coverage with descriptions for both messageId and destinationFolderId. The tool description does not add further meaning beyond what the schema already states, so the baseline of 3 is appropriate.

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

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

The description states the exact action: 'Copy a message into another mailbox folder.' It uses a specific verb and resource, and the word 'copy' distinguishes it from sibling mail_move_message. The inclusion of Chinese intents also reinforces the purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly implies when to use (when a message needs to be copied to another folder), but it does not explicitly contrast with mail_move_message or state when not to use. The permission requirement adds context, but no alternative tools 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?

With no annotations provided, the description carries the full burden. It discloses the required delegated Mail.ReadWrite permission and explicitly states the draft is not sent. This is useful behavioral context, though it does not mention side effects like saving to the Drafts folder or return values.

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 focused sentence followed by Chinese intent aliases. It front-loads the core purpose and permission requirement. No wasted words; the additional Chinese text is compact and serves multilingual support without bloating the definition.

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 draft tool with no output schema and no annotations, the description provides the essential context: what it does, permission needed, and the non-sending guarantee. It lacks details on where the draft is stored or what the response contains, but these are not critical for tool selection. Overall, the description is largely complete for its 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 100% for all 6 parameters, so per the rubric baseline is 3. The description does not add parameter-level info beyond what the schema already provides, but since the schema is complete, no deduction is needed.

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 verb 'Create', the resource 'email draft', and the key distinction 'without sending it'. This distinguishes it from siblings like mail_send and mail_reply, making the tool's purpose 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?

The phrase 'without sending it' provides clear context that this tool is for drafting emails when the user wants to prepare content but not transmit it yet. However, it does not explicitly name alternative tools (e.g., mail_send) or provide explicit exclusion scenarios, so it misses the top score.

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 adds a specific permission requirement (delegated Mail.ReadWrite) and clarifies the scope (top-level or child folder), but it does not disclose potential side effects, return behavior, or any post-creation details, leaving some behavioral aspects implicit.

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 concise and front-loaded with the core purpose in the first sentence. The permission note is valuable, and the Chinese intents provide localization without bloating the text. Every part serves a purpose, and there is no redundancy with the 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 straightforward creation tool with a simple 3-parameter schema and no output schema, the description provides the essential context: what the tool does, the permission required, and the folder hierarchy capability. It lacks details about return values or error conditions, but the simplicity of the operation and full schema coverage make this acceptable.

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 input schema already provides descriptions for all three parameters (isHidden, displayName, parentFolderId) with 100% coverage, so the description adds no parameter-specific meaning beyond what the schema gives. The 'top-level or child' phrasing loosely maps to parentFolderId being optional, but this is redundant with the schema's 'Optional parent folder ID.'

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 verb 'Create' and the resource 'mailbox folder', and further specifies 'top-level or child', distinguishing it from sibling folder creation tools like contacts_create_folder and drive_create_folder. The additional Chinese intent phrases reinforce the tool's purpose without ambiguity.

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 clear context by indicating the tool creates mailbox folders and requires delegated Mail.ReadWrite permission, which sets expectations for when to use it. However, it does not explicitly contrast with alternatives or state when not to use it, so it stops short of a 5.

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