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

Annotations indicate readOnlyHint=false and idempotentHint=false. The description adds that it initiates device flow, requires user confirmation, and is not idempotent, providing behavioral context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the purpose and uses structured steps. It is slightly lengthy but well-organized and clear.

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 zero parameters and the presence of an output schema, the description fully covers the tool's function and process, linking to the completion step.

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

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

There are zero parameters, so default to baseline 4. The description adds no parameter info, which is unnecessary.

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 authenticates a Microsoft account using device flow and returns instructions. It distinguishes itself from the sibling tool account_complete_auth, which completes the process.

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 outlines the steps for the user and mentions that account_complete_auth should be used afterward, providing clear context on when to use this tool. However, it does not explicitly state when not to use it or list alternatives.

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 adds context beyond annotations: it describes return values (account info or pending status) and the pending nature if user hasn't completed. Given readOnlyHint=false and destructiveHint=false, the description appropriately indicates a mutating but non-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 with two clear sentences, an emoji for visibility, and labeled Args/Returns sections. No unnecessary 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?

Given one simple parameter and an output schema, the description fully covers the tool's purpose, prerequisite, and return possibilities. Complete for this 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?

With 0% schema coverage, the description provides crucial meaning: it explains 'flow_cache' is the flow data returned from account_authenticate (the _flow_cache field). This clarifies the parameter's origin and type.

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 completes device flow authentication, specifying the verb 'Completes' and the resource 'authentication process'. It distinguishes itself from sibling account_authenticate by referencing the prior step and the flow_cache argument.

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

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

The description explains that it is used after the user enters the device code at the verification URL, and that flow_cache comes from account_authenticate. It implies a prerequisite but does not explicitly state when not to use or provide alternative 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?

Annotations already declare readOnlyHint and idempotentHint, so the description reinforces these. It adds value by detailing the return structure (username, account_id, account_type) and providing an example.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise yet fully informative, using clear sections and an example. 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?

Given no parameters and an output schema, the description sufficiently explains the return values and provides a complete example. Annotations cover safety and idempotency.

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 correctly omits parameter details as none 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 clearly states the tool's action ('List all signed-in Microsoft accounts') and its resource scope, distinguishing it from sibling tools like account_authenticate that handle authentication.

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 indicates it's 'read-only, safe for unsupervised use,' implying low-risk usage. However, it does not explicitly state when not to use it or suggest alternatives.

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

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

Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds value by detailing the exact statistics returned, such as hit rates and compression ratios, and reassures 'safe for unsupervised use'. No contradiction.

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 well-structured with a header, safety note, bullet list of return fields, and an example. It is somewhat lengthy but every sentence adds value. Front-loading of key info is good.

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 zero parameters and a likely rich output schema, the description thoroughly explains the return fields and provides an example. It is fully self-contained for an agent to understand the tool's purpose and output.

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

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

There are zero parameters, so the description naturally has minimal param info. The schema coverage is 100% (none). The description provides an example usage, adding practical 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 the tool retrieves cache statistics and performance metrics, distinguishing it from sibling tools like 'cache_invalidate' and 'cache_warming_status'. It emphasizes 'read-only, safe for unsupervised use', which is a specific verb+resource combo.

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 marks the tool as safe and read-only, implying it's appropriate for any monitoring context. While it does not provide explicit exclusions or alternatives, the context is clear enough for an agent to decide when to use it.

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

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

The description mentions deletion of cache entries, implying a destructive action, yet the destructiveHint annotation is false. This is a contradiction. Additionally, while it discloses the return values and pattern matching behavior, it does not discuss performance implications or authentication requirements beyond the optional account_id parameter. The annotation contradiction reduces 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 well-structured with sections (Args, Returns, Examples) and front-loaded with a clear purpose. It is slightly verbose but every sentence adds value. The emoji provides instant recognition. Could be more concise, but overall 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?

Given the output schema exists and is referenced in the description, the description covers all aspects: what the tool does, parameters, return values, and examples. The tool has moderate complexity and the description is complete for effective use.

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?

Despite 0% schema description coverage, the description provides extensive details for each parameter: pattern supports wildcards with examples, account_id scoping, and reason default/audit logging. This fully compensates for the lacking schema descriptions and adds significant 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 it invalidates cache entries matching a pattern. It uses specific verbs ('Invalidate', 'Delete') and specifies the resource ('cache entries'). It distinguishes from sibling cache tools like cache_get_stats and cache_warming_status by explicitly being the invalidation tool.

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

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

The description explains when to use it: for forcing fresh data retrieval or clearing stale cache entries. It includes examples for common use cases. Although it doesn't explicitly state when not to use it, the context of sibling tools and the note about user confirmation provide sufficient guidance. Lacks explicit exclusion of alternatives.

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

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

Annotations already provide readOnlyHint, idempotentHint, etc. The description adds value by detailing the return structure (fields like status, progress, error) and the error case (ValueError for missing task_id), which goes beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with purpose and uses clear sections (Args, Returns, Raises). It is slightly verbose due to the detailed Returns list, but every sentence adds value. Could be slightly more concise without losing 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?

Given the simple tool (one required parameter) and the existence of an output schema, the description covers purpose, parameter, return structure, and error handling thoroughly. No gaps are apparent.

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 0%, so the description must fully explain parameters. It describes task_id as 'the unique identifier for the cache task', adding meaning beyond the schema's simple type definition. The single parameter is well-described.

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 'Get status' and the resource 'background cache task'. It distinguishes from sibling tools like cache_task_list (which lists all tasks) and cache_get_stats (which likely returns aggregate stats) by focusing on a single task's 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 notes the tool is 'read-only, safe for unsupervised use' and implies it should be used to check status of a specific background cache task. However, it does not explicitly state when to use alternatives like cache_task_list or when not to use this tool.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds 'read-only, safe for unsupervised use' and fully documents the return format (list of task dictionaries with fields), providing useful context beyond annotations. No contradictions.

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?

Well-structured with an initial summary line, then Args, Returns, and Examples sections. Every sentence adds value, no fluff or repetition. Front-loaded with key 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?

Even with an output schema, the description details return fields. Covers purpose, safety, parameters, output, and examples. Complete for a read-only listing 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 0%, but the description thoroughly explains each parameter (account_id, status, limit) with purpose, types, and defaults, plus examples. Fully compensates for missing schema descriptions.

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 'List background cache tasks' with verb and resource, and adds 'read-only, safe for unsupervised use' to distinguish it from mutation tools. Siblings like cache_invalidate are clearly different.

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?

Implies usage by detailing filtering options and providing examples, but does not explicitly compare to alternatives like cache_task_get_status. No '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?

Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint as true. The description reinforces that it's read-only and safe, and adds value by detailing the return fields (e.g., is_warming, progress_percent) and providing an example. No contradictions.

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 well-structured with a clear lead sentence, a bulleted list of return fields, and an example. It is not overly long, though the emoji and detailed list could be slightly trimmed. The information is front-loaded and every sentence adds value.

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

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

For a tool with no parameters and existing annotations, the description fully covers the behavior and return format. It lists all expected fields in the response, provides context on when each field is populated (e.g., started_at when active), and includes a usage example. No gaps remain.

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

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

There are no parameters, and schema description coverage is 100% (trivially). The description adds meaning beyond the schema by documenting the full return dictionary with field descriptions and an example, which helps the agent understand the output without needing an explicit output 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 'Get cache warming status and progress', specifying the verb (get) and resource (cache warming status). It includes a read-only badge, but does not differentiate from sibling tools like cache_get_stats or cache_task_get_status, which could also provide related status info.

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 safe unsupervised use ('read-only, safe for unsupervised use') which suggests it can be called freely, but it does not explicitly state when to use this tool over alternatives or when not to use it. No exclusions or comparisons to siblings are provided.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds context by repeating 'read-only, safe for unsupervised use,' and details return type (free/busy information) and possible errors (ValidationError, ValueError). This goes beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, well-structured, and front-loaded with the main purpose. Each section (args, returns, raises) is clearly separated, and every sentence adds value.

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

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

Given the tool has 4 parameters and an output schema, the description covers purpose, parameters, return format, and errors. The presence of an output schema means the description does not need to detail the return structure, making it 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?

Despite 0% schema description coverage, the description lists each parameter with a brief explanation (e.g., 'start: Start time in ISO format'). This adds meaning that the schema alone does not provide, compensating for the lack of schema descriptions.

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 checks calendar availability for scheduling and returns free/busy information. It is distinct from siblings like calendar_create_event, but could differentiate from calendar_get_free_busy, which also deals with free/busy data.

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 says 'Useful for finding meeting times,' implying usage context. However, it does not specify when not to use this tool or mention alternatives like calendar_get_free_busy, leaving room for ambiguity.

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

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

Annotations indicate readOnlyHint=false and destructiveHint=false. The description adds a user confirmation recommendation and explicit error handling (ValidationError), providing behavioral context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured with sections for usage, args, returns, and raises, though the emoji and redundant phrasing could be trimmed slightly.

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 (create a calendar), the description covers purpose, parameters, return value, and error conditions. The presence of an output schema reduces the need to detail return structure further.

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 has 0% description coverage, but the description explicitly explains both parameters (account_id and name) in the Args section, adding meaning beyond the bare 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 verb 'creates' and resource 'calendar in the user's mailbox.' Among siblings like calendar_delete_calendar and calendar_list_calendars, it is distinct and 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 clear use cases (work, personal, project-specific calendars) but does not explicitly state when not to use or mention alternatives like updating an existing calendar.

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

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

Annotations provide basic mutation flags (readOnlyHint=false, destructiveHint=false). The description adds valuable behavioral details: attendees receive invitations, addresses are validated/deduplicated/limited to 500, and ValidationError raised for invalid inputs.

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 well-structured with a summary, parameter details, returns, and raises sections. It is front-loaded with the purpose. Minor redundancy (e.g., 'optional' repeated) but overall efficient and clear.

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 complexity (8 parameters, 4 required), the description covers parameter syntax, error conditions, and side effects (attendees invited). The return type is vaguely mentioned but an output schema is noted to exist, so this is 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?

Schema description coverage is 0%, so the description carries the full burden. The 'Args' section explains each parameter's meaning (e.g., account_id is Microsoft account ID, start/end in ISO format), adding critical semantic value beyond the schema's type-only definitions.

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 'Create a calendar event' with specific verb and resource. It differentiates from sibling tools like calendar_update_event and calendar_delete_event by its focus on creation.

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 implicitly indicates this tool is for creating events, but lacks explicit guidance on when not to use it or alternative tools. The 'requires user confirmation' note is more about safety than 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?

Annotations indicate destructiveHint=true and idempotentHint=true. The description adds context: the action is permanent, cannot be undone, and the confirm parameter prevents accidents. Also explains the error when trying to delete the default calendar.

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?

Well-structured with a prominent warning emoji, clear sections for args, returns, and raises. Every sentence adds value, and the warning is front-loaded. 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?

Covers all essential aspects: preconditions (default calendar not deletable), required confirmation, permanent nature, and error cases. The output schema (not shown) is likely sufficient, and the description explains return type and raises. Complete for this destructive 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 has 0% description coverage, but the description fully explains each parameter: account_id, calendar_id, and confirm (with its role in preventing accidents). Provides clear semantics beyond the schema.

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

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

The description clearly states the action: 'Delete a calendar permanently.' It specifies the resource (calendar) and includes a warning about data loss. Distinguishes from sibling tools like calendar_create_calendar and calendar_delete_event by focusing on calendar deletion.

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 notes that the default calendar cannot be deleted and requires user confirmation via the 'confirm' parameter. However, no explicit alternatives are given for cases where deletion is not intended, though siblings provide other calendar 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?

Beyond annotations (destructiveHint=true, readOnlyHint=false), the description adds critical behavioral context: always requires user confirmation, permanent deletion, attendee cancellation notices, and need for confirm parameter to be True.

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 efficient and well-structured: opens with a clear action, includes a warning, then lists parameters in a clean args block. No unnecessary sentences.

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 4 parameters, 2 required, destructive, and an output schema. The description covers purpose, irreversibility, attendee notices, parameter meanings, and return confirmation. Lacks mention of error handling or prerequisites but is sufficient for a delete 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?

Despite 0% schema description coverage, the description fully explains all 4 parameters with purpose and semantics (e.g., account_id as Microsoft account ID, event_id as the event to delete, send_cancellation default true, confirm must be True to prevent accidents).

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 deletes a calendar event, with a permanent irreversible action. This verb+resource combination is distinct from sibling tools like calendar_create_event, calendar_update_event, etc.

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 deleting events and warns about permanence and attendee notifications, but does not explicitly state when to use this tool vs alternatives or provide exclusion criteria.

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

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

The description discloses critical behaviors: immediate sending, irreversibility, validation, deduplication, recipient limit of 500, and the need for confirm=True. Annotations (readOnlyHint=false, destructiveHint=false) are consistent and the description adds substantial context beyond them.

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 well-structured: a header line, a crucial warning, then a list of parameters with explanations. No extraneous information; every sentence adds value.

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

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

The description covers purpose, usage, parameter details, behavioral warnings, errors, and return type. Given the tool's complexity (6 params, sending action) and the presence of an output schema, the description is complete and self-sufficient.

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

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

With 0% schema description coverage, the description adds meaning by explaining each parameter (e.g., 'to: Recipient email address(es)', 'confirm: Must be True to confirm sending'). It also mentions validation and limits. However, it does not detail format for account_id or event_id, missing some depth.

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 'Forward a calendar event to recipients,' clearly identifying the verb and resource. It is distinct from sibling tools like email_forward (email) and calendar_respond_event (response), so an agent can differentiate it.

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 important usage instructions: user confirmation required, immediate sending, irreversibility, and recipient limits. It does not explicitly contrast with alternative tools, but the context and warning provide adequate guidance for when to use this tool.

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

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

Annotations already provide readOnlyHint, destructiveHint, idempotentHint, openWorldHint. The description adds 'safe for unsupervised use' and specifies return content (recurrence, meeting details), which is useful but does not contradict annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Very concise with clear structure: emoji header, one-sentence purpose, then parameter list. No superfluous information; every sentence adds value.

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

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

Covers purpose, parameters, and return content. Output schema exists so return details are not needed. Minor lack of cache behavior nuances, but adequate for a read-only tool.

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

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

The description explicitly lists and explains all four parameters with roles and defaults. Since the input schema lacks descriptions, the description fully compensates (schema coverage 0%).

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 'Get full event details (read-only)' and mentions recurrence and online meeting details. It distinguishes from sibling tools like calendar_list_events and calendar_update_event by emphasizing completeness and read-only nature.

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 'safe for unsupervised use' but does not explicitly state when to use this tool versus alternatives like calendar_list_events or calendar_get_free_busy. No when-not-to-use guidance is provided.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description reinforces this by stating 'read-only, safe for unsupervised use' and explains the output type ('availability view strings'), adding value beyond the structured annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, starting with a emoji-summarized safety note, then a clear explanation, sibling comparison, and structured Args section. 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?

With an output schema present, the description only needs to hint at returns, which it does ('Free/busy information with availability view strings'). It also lists possible exceptions. For a simple read tool with 5 params and rich annotations, it is 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 description coverage is 0%, but the description provides clear explanations for all five parameters in the Args section (e.g., 'ISO format' for start/end, 'default: 30' for time_interval), compensating fully for the bare 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 'Get simplified free/busy times for attendees' with a specific verb ('get'), resource ('free/busy times'), and scope ('for attendees'). It also distinguishes from the sibling tool calendar_check_availability, ensuring no 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 explicitly compares itself to calendar_check_availability, noting it 'focuses on availability view strings rather than detailed schedule information,' which guides selection. However, it does not provide explicit when-not-to-use or alternative scenarios beyond that one comparison.

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 adds significant behavioral context beyond annotations: caching details (15 min fresh, 1 hour stale), return fields (_cache_status, _cached_at), and safety guarantee. Annotations already declare readOnlyHint=true, which the description reinforces.

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 well-structured with sections (Args, Returns), uses an emoji for quick scanning, and is concise without redundancy. Every sentence adds value.

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

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

Despite the output schema existing but not shown, the description adequately describes the return format (list of calendar objects with metadata, including _cache_status and _cached_at). It covers caching, parameters, and return behavior completely 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?

With schema description coverage at 0%, the description fully explains all parameters: account_id as Microsoft account ID, use_cache (default True), force_refresh (default False), adding 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 the tool lists all available calendars for the user, using a specific verb ('List') and resource ('calendars'). It is distinct from sibling tools like calendar_create_calendar or calendar_list_events.

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

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

The description provides context about when to use the tool (e.g., read-only, safe) and caching behavior (fresh vs. stale), but does not explicitly state when not to use it or contrast with alternatives beyond the implied domain.

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?

Beyond annotations (readOnlyHint, idempotentHint), the description adds caching specifics (5 min fresh, 30 min stale), force_refresh option, and confirms it is safe for unsupervised use. No contradictions.

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 well-structured with sections for caching, parameters, and returns. It is concise without unnecessary words. Slightly verbose due to full parameter listing, but this is justified given 0% schema coverage.

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 complexity (6 parameters, output schema exists), the description is complete. It covers caching, parameter details, safety, and return fields like _cache_status. The output schema covers event properties, so no additional detail needed.

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 0% description coverage, but the description manually documents all 6 parameters with defaults, ranges (1-365 for days_ahead, 1-200 for limit), and semantics (e.g., include_details for full event details). This fully compensates for the missing schema descriptions.

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 lists upcoming calendar events from now until a specified number of days ahead. It uses specific verb-resource ('List Calendar Events') and distinguishes from siblings like search_events or calendar_get_event by focusing on upcoming events from a specific account.

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: it is read-only and safe for unsupervised use, and explains caching behavior. However, it does not explicitly state when not to use this tool or mention alternatives like calendar_get_event for single events or calendar_get_free_busy for availability checks.

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

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

Annotations indicate write operation and side effects (openWorldHint=true). The description adds 'requires user confirmation recommended' but doesn't detail the process or potential side effects adequately.

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 well-structured with a summary, usage note, and parameter list. It's slightly lengthy but not wasteful. The 'requires user confirmation recommended' could be phrased more concisely.

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 basic usage, but given openWorldHint=true and an output schema exists, more details about what happens after proposing (e.g., organizer receives request) would improve 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?

Despite 0% schema coverage, the description includes detailed Args with examples (ISO date formats) and explains each parameter's purpose, fully compensating for the schema's lack of descriptions.

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 proposes a new meeting time, specifying it's for attendees only, which distinguishes it from sibling tools like calendar_update_event for organizers.

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 explicitly says when to use: when invited but the time doesn't work, and notes the limitation of only working for attendees. It doesn't name alternatives but provides clear 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?

The description adds behavioral context beyond annotations: it recommends user confirmation, states the action sends a response to the organizer, mentions case-insensitivity and alias for 'tentative', and notes potential ValidationError. Annotations indicate idempotentHint=true and readOnlyHint=false, which are consistent with the described 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 well-structured with clear sections (warning, important note, valid responses, args, returns, raises). It is front-loaded with a warning but includes some redundancy (e.g., default value mentioned in description and schema). Overall, it is appropriately sized for the tool's complexity.

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 tool's purpose, parameter semantics, expected output (status confirmation), and possible errors. With a relatively simple tool and an output schema available (context indicates exists), the description is sufficiently complete for agent 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 has 0% description coverage according to context signals, meaning no parameter descriptions in the schema. The tool description compensates by providing an Args section that explains each parameter, including valid values for 'response' and its case-insensitivity. This adds significant 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 the action 'Respond to a calendar event invitation' and identifies the resource as a calendar event invitation. It distinguishes from sibling tools like calendar_create_event or calendar_delete_event by specifying the response 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 usage context by listing valid response values ('accept', 'decline', 'tentativelyAccept') and notes that it sends a response to the organizer. However, it does not explicitly state when not to use this tool or suggest alternatives for other 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?

Annotations indicate mutability and idempotency, but the description adds crucial behaviors: user confirmation is recommended, and attendees receive update notifications. This goes beyond the structured metadata and helps the agent anticipate real-world 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 brief yet covers purpose, usage, parameters, and behavior. It uses a clear structure with an introductory sentence, a bullet list of allowed keys, and an Args section. 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?

Given the presence of an output schema, the description does not need to detail return values. It already covers all necessary aspects: what the tool does, when to use it, what fields to update, and behavioral side effects (user confirmation, notifications). No gaps remain.

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 lacks descriptions for all three parameters (0% coverage). The description compensates thoroughly by listing allowed update keys (subject, start, end, location, body) and providing brief explanations for event_id, updates, and account_id. This makes parameter usage clear.

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 an existing calendar event, listing specific properties like time, location, and attendees. This verb+resource combination uniquely identifies the tool among siblings (create, delete, get, list), making 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 context for when to use the tool (to modify event details) and mentions side effects (notifications sent). However, it does not explicitly exclude scenarios like proposing new times or responding to events, though these are distinct operations handled by 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?

The description discloses key behavioral traits: the contact is copied (not moved), and it requires user confirmation. Annotations only indicate readOnlyHint=false and openWorldHint=true, so the description adds significant context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured, with a purpose statement, behavior details, parameter list, return value, and error information. 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?

Given the tool's simplicity, the description is complete: it explains the operation, all parameters, return type, and possible error. Even with an existing output schema, it provides necessary 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?

With 0% schema description coverage, the description fully explains each parameter (account_id, contact_id, list_id) with clear meanings. This compensates entirely for the lack of schema descriptions.

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 contact to a contact list' and explains that the contact is copied, distinguishing it from creating a new contact or list. It uses a specific verb-resource pair.

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 adding existing contacts to lists but does not explicitly state when to use this tool vs alternatives like contact_update or search_contacts. No exclusions or context for when not to use it are provided.

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

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

Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds 'requires user confirmation recommended' and clarifies it creates data, providing some behavioral context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is fairly concise, using an emoji for visual cue and front-loading purpose. The Args section adds value but could be slightly more streamlined.

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 key creation parameters and includes a Returns line. Given the presence of an output schema, it is reasonably complete, though it omits error conditions and permission requirements.

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

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

With schema description coverage at 0%, the description compensates by listing each parameter with clear explanations, including required status and acceptable types (e.g., phone_numbers as dict with specific keys).

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 new contact' and details the components (name, email, phone). It distinguishes itself from sibling tools like contact_update and contact_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?

The description implies when to use the tool (to create a contact) but offers no explicit guidance on when not to use it or mention of alternatives among 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?

Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds the behavioral trait 'requires user confirmation recommended,' which is beyond what annotations provide. It also clarifies the resource type ('contact folder/list'). No contradiction with annotations. However, it omits details on permissions or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured: it opens with a clear purpose, then provides usage context, parameter descriptions, return information, and error details. Each sentence adds value, and the formatting (Args, Returns, Raises) makes it 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?

Given the tool's simplicity (2 params, output schema exists), the description is fairly complete. It explains the function, parameters, return object, and error case. It does not explicitly mention prerequisites like authentication, but since sibling tools include account_authenticate, this is likely understood. A small gap is the lack of uniqueness constraints on list_name.

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 0% schema description coverage, the description fills the gap by providing semantic meaning for both parameters: 'account_id: Microsoft account ID' and 'list_name: Name for the contact list/folder.' This adds necessary context beyond the schema's bare property definitions, though more detail (e.g., allowed formats) could be helpful.

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 creates a contact list (folder) for organizing contacts. It uses a specific verb ('Creates') and resource ('contact list'), and the examples of use cases (distribution lists, project teams) distinguish it from sibling tools like contact_create (which creates individual contacts) and contact_add_to_list (which adds to existing lists).

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

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

The description mentions it is 'useful for creating distribution lists, project teams, or other groupings,' giving context for when to use it. However, it does not explicitly state when not to use it or compare it with alternatives like contact_add_to_list for adding contacts to existing lists. The guidance is implied but not sharply differentiated.

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?

Beyond the annotations (destructiveHint, readOnlyHint), the description adds critical context: permanent deletion, requirement for user confirmation, and the need to set confirm=True. This is valuable information for safe invocation.

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, using a short warning and bullet-style argument list. Every sentence adds value, and the structure is easy to parse.

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

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

The description covers the action, warning, and parameter meanings. However, it omits details about the output schema (only says 'Status confirmation') and does not mention required parameters explicitly.

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 0% schema description coverage, the description compensates by listing the three parameters and their purposes. However, it lacks details on formats, constraints, or how to obtain values.

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 deletes a contact permanently. It uses a specific verb and resource, distinguishing it from other contact tools like create or update.

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. The description only explains the deletion behavior but does not help an agent decide between 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?

Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint, so the tool is safe. The description adds context about error conditions (ValidationError, ValueError) and the format limitation (only 'vcard' supported), enhancing transparency beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, structured with a summary line, Args, Returns, and Raises sections. It front-loads key information (emoji, read-only tag) and contains 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?

Given that the tool is read-only with comprehensive annotations and an output schema (not shown), the description covers input parameters, error behavior, and output intent. It is complete for its purpose.

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 0%, but the description includes an Args section that explains all three parameters: account_id, contact_id, and format (with supported value). This compensates for the missing schema descriptions and meets the baseline of 4 for low coverage.

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

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

The description clearly states 'Export a contact in vCard format (read-only, safe for unsupervised use)', which is a specific verb-resource combination. It distinguishes from sibling tools like contact_get, contact_list, and contact_update by focusing on export.

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 exporting contacts to vCard and mentions read-only safety, but does not explicitly contrast with sibling tools or provide when-not-to-use guidance. No alternatives are named.

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

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

Annotations already declare readOnlyHint, destructiveHint, idempotentHint, openWorldHint. The description adds valuable behavioral context: caching details (30 min fresh, 4 hours stale, use_cache, force_refresh) and output fields _cache_status and _cached_at. This goes beyond what annotations provide, though it does not mention error handling or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a header, caching paragraph, parameter list, and return format. It uses emojis for visual cues and every sentence adds value. 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 presence of an output schema (context signal) and rich annotations, the description covers all essential aspects: purpose, caching behavior, parameter semantics, and return fields. It is complete for a read-only get 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 coverage is 0% (no descriptions in JSON schema). The description explains all four parameters with meaningful labels: contact_id, account_id, use_cache, force_refresh, including defaults and behaviors like 'bypass cache'. This compensates well for the missing schema descriptions, though format details (e.g., contact_id format) are absent.

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 'Get contact details (read-only, safe for unsupervised use)' and 'Returns complete contact information including all fields.' This is a specific verb-resource pair that distinguishes it from sibling tools like contact_list, contact_create, etc.

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 retrieving a single contact's details, with caching options. However, it does not explicitly state when to use this vs alternatives like contact_list or search_contacts, nor does it provide when-not or exclusion criteria.

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

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

Annotations already declare readOnlyHint, destructiveHint, and idempotentHint. The description adds caching behavior (20 min fresh, 2 hours stale) and the force_refresh parameter, which provides additional behavioral context beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with an emoji, clear sections for output, caching, arguments, and returns. Every sentence is informative and necessary, 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 complexity (4 parameters, many siblings, output schema exists), the description covers safety, caching, parameter details, and return fields. It is sufficiently complete for effective use.

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 0%, so the description fully compensates by explaining each parameter in detail: account_id, limit (with range), use_cache, and force_refresh. It clarifies defaults and caching logic, adding significant 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 the tool's purpose: '📖 List contacts (read-only, safe for unsupervised use)'. It specifies what it returns ('names, email addresses, and phone numbers'), distinguishing it from siblings like search_contacts and contact_get.

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?

While the description indicates the tool is read-only and safe, it does not explicitly guide when to use this tool versus alternatives (e.g., search_contacts for searching, contact_get for a single contact). The caching advice is helpful but does not address 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?

Annotations already provide readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds behavioral context like requiring user confirmation and listing allowed update keys, but does not detail side effects or partial update 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 well-structured with a summary, field list, parameter explanations, and return value, all in a concise format 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?

The description covers allowed fields and return type, but lacks clarification on whether the update is partial or full replacement. Given the output schema exists, this is a minor gap.

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

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

Schema description coverage is 0%, but the description lists allowed update keys and explains each parameter (contact_id, updates, account_id) with clear descriptions, adding significant 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 it updates contact information, lists specific modifiable fields, and distinguishes from sibling tools like contact_create, contact_delete, and contact_get.

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 note about user confirmation but lacks explicit guidance on when to use this tool versus alternatives, and does not specify prerequisites or exclusions.

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

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

Discloses that the tool 'replaces all existing categories with the specified ones' – a key behavioral trait not captured by annotations. Also lists raised errors (ValueError, ValidationError). Annotations indicate destructiveHint=false, but the replacement behavior could be considered destructive; however, the description is transparent about this.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with emoji and key info. Each sentence serves a purpose: purpose, usage guidance, behavioral warning, args, returns, raises. No redundant 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?

Covers all aspects: purpose, behavior, parameters, return value, and error handling. Has output schema, so return details are sufficient. Complexity low, but description is complete.

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

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

With 0% schema description coverage, the description fully compensates by describing each parameter in the Args section: email_id, account_id, and categories, adding context beyond the schema's type definitions.

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 'Add categories to an email' with a specific verb and resource. Distinguishes itself from sibling 'email_update' by noting it is a 'simpler alternative for managing email categories'.

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

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

Provides guidance by recommending use as a simpler alternative to email_update and mentions user confirmation. However, does not explicitly state when not to use or list other alternatives.

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

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

Annotations indicate idempotentHint=true and non-destructive. The description adds that it requires user confirmation (recommended), returns a status confirmation with new email ID, and raises ValueError for invalid email ID or missing archive folder. No contradictions.

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 well-structured with clear sections for Args, Returns, and Raises. Front-loaded with the main 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?

Given the output schema exists and the tool is simple, the description covers the essential behavior and return value. Sibling tools are many, but the differentiation from email_move is clear.

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 0%, and the description only adds minimal one-line explanations for each parameter (email_id and account_id). More detail would help, but the parameters are simple.

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 (archive an email) and resource (email), and explicitly distinguishes from sibling tool email_move by calling it a convenience wrapper that targets the archive folder.

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

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

The description explains it is a quick action for archiving, recommends user confirmation, and notes it's a wrapper around email_move, implying it should be used when archiving vs moving to other folders. However, it does not explicitly state when not to use it.

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

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

Annotations indicate a non-read-only, non-destructive write operation. The description adds context: 'requires user confirmation recommended', drafts can be edited, and supports attachments. This goes beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a purpose sentence, an Args list, and a Returns section. It is concise, though the emoji is minor clutter. Front-loaded with key information.

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

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

The description covers purpose, parameters, and basic return. An output schema exists for detailed return structure. Missing mentions of authentication or prerequisites, but given sibling tools and annotations, it is fairly 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 0%, so the description must explain parameters. It provides an Args section with brief descriptions for all six parameters (account_id, to, subject, body, cc, attachments), adding 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 clearly states the tool 'Creates a draft email message that can be edited later before sending.' It uses the verb 'create' and the resource 'email draft', distinguishing it from siblings like email_send, email_reply, and email_get.

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: creating drafts for later sending, but lacks explicit guidance on when to use this tool versus alternatives like email_send or email_update. It mentions 'requires user confirmation recommended' but does not provide when-not-to-use or alternative 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?

Description adds permanent deletion warning and confirmation requirement beyond annotations. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise, front-loaded with purpose, uses warnings and emoji effectively. 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?

Description covers all needed behavioral and usage context for a simple destructive tool with output schema 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?

All three parameters explained with roles and the confirm parameter's required value, compensating for 0% 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?

Clearly states 'Delete an email permanently' with explicit warning. Distinguishes from siblings like email_move and email_archive.

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?

Suggests using email_move as safer alternative. Mentions required user confirmation. Could be more explicit about when not to use.

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

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

Annotations already indicate mutability (readOnlyHint=false) and safety (destructiveHint=false). The description adds valuable behavioral context like the recommendation for user confirmation, return format note, and potential errors, going beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: one emoji-tagged purpose line, one comparative guidance line, and a clear Args/Returns/Raises block. Every sentence earns its place, and the core 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?

Given the simple tool nature and presence of an output schema, the description covers all bases: purpose, parameter semantics, behavior (user confirmation), sibling differentiation, and error handling. No gaps remain.

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 0% schema description coverage, the description fully compensates by explaining each parameter's purpose, default value, and possible values for flag_status (listed as options). This adds meaning that the raw schema lacks.

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: 'Flag or unflag an email' with a specific verb and resource. It further distinguishes from sibling 'email_update' by positioning itself as a 'Simpler alternative for flagging emails,' making the unique 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 directs agents to use this tool for flagging when they would otherwise consider 'email_update,' and recommends user confirmation. It lacks explicit guidance on when not to use it, but the comparison covers key 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?

Annotations indicate not read-only, destructive, or idempotent. Description adds the behavioral trait of requiring user confirmation and lists possible ValueError, providing context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is well-structured with Args, Returns, Raises sections, and is concise overall. The emoji and recommendation add value without excessive verbosity.

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 presence of output schema, description still provides return and error details. Covers creation scenarios and error conditions, making it complete 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?

Schema has 0% description coverage, so description compensates by explaining each parameter's meaning and default behavior for parent_folder_id. Also describes return 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 clearly states the verb 'create' and resource 'mail folder', with additional scope (root level or child of existing folder). This distinguishes it from siblings like rename, delete, etc.

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 mentions 'requires user confirmation recommended' and explains parent_folder_id for root vs child, but does not explicitly state when to use this tool vs alternatives or when not to use it.

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

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

Beyond the annotations (destructiveHint=true, readOnlyHint=false), the description adds critical behavior: 'WARNING: This action permanently deletes the folder and all its contents (emails and subfolders) and cannot be undone.' It also clarifies the confirm parameter requirement, which is not in annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is structured with a clear warning, parameter list, and returns/raises sections. Each sentence serves a purpose, though the multiple warnings could be slightly condensed without losing 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 destructive nature (destructiveHint=true) and the output schema presence, the description covers all necessary aspects: purpose, usage warnings, parameter semantics, return values, and error conditions. It leaves no critical gaps for an AI 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?

Despite 0% schema description coverage, the description fully explains each parameter: folder_id (the folder ID), account_id (Microsoft account ID), and confirm (must be True to confirm). It also documents the ValueError for invalid folder_id or false confirm, adding 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 clearly states 'Delete a mail folder permanently' and includes a warning about permanent deletion. It distinguishes itself from sibling tools like emailfolders_create, emailfolders_rename, and others by specifying the destructive nature.

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 notes that the action 'always require[s] user confirmation' and warns about permanent deletion. It implicitly guides usage by emphasizing the need for caution, though it does not explicitly list alternatives or when not to use.

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?

Beyond annotations (destructiveHint=true, idempotentHint=false), description adds that deletion is permanent, cannot be undone, and folder remains. No contradictions.

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?

Well-structured with clear sections (purpose, warning, args, returns, raises), uses bold and emoji for emphasis, every sentence is necessary and concise.

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 an output schema exists and the description includes Returns and Raises, it fully covers operation, parameters, behavior, and errors, making it 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 0%, but description fully explains all three parameters: folder_id, account_id, and confirm (clarifying it must be True to prevent accidents, overriding schema default of false).

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 'Delete all messages in a folder' with the verb 'Empty' and resource 'Email Folder', distinguishing it from siblings like 'email_delete' (single email) or 'emailfolders_delete' (delete folder).

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

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

Provides explicit warning about permanent deletion, requires user confirmation via 'confirm' parameter, and notes the folder remains. However, does not explicitly compare to alternative tools like 'emailfolders_delete'.

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

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

Annotations already declare readOnlyHint, destructiveHint, idempotentHint. The description adds 'read-only, safe for unsupervised use' and specifics about returned fields (counts, hierarchy). This adds some value beyond annotations but not extensive 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 concise, with a clear structure: purpose, safety note, return summary, and args. No unnecessary words, and front-loaded with key 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?

Given the tool's simplicity (2 parameters, output schema exists), the description fully explains the purpose, parameters, and return fields. It is complete for the agent to understand how to use it.

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 0%, but the description includes a brief explanation for both parameters (folder_id and account_id), giving basic context that the schema lacks. This compensates for the missing schema descriptions.

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 retrieves detailed info about a specific folder, with a specific verb and resource. It distinguishes itself from related tools like emailfolders_list and emailfolders_get_tree by focusing on a single folder's metadata.

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

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

The description provides clear context: 'read-only, safe for unsupervised use' and mentions the returned data type. It does not explicitly say when not to use or name alternatives, but the context implies its use for getting a single folder's details.

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 explicitly confirms read-only behavior ('safe for unsupervised use'), matching annotations. It adds valuable behavioral context: recursion with depth control (max_depth 1-25), handling of parent folder as root, and hidden folder inclusion. This goes beyond what annotations (readOnlyHint, idempotentHint) convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with an emoji for quick scanning, a one-line summary, then clearly labeled Args and Returns sections. Every sentence adds value, with no unnecessary repetition. It is front-loaded with the key purpose and safety note.

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 presence of an output schema (not shown but confirmed), the description sufficiently explains what the tool does, its parameters, and the hierarchical return. It addresses safety (read-only), recursion limits, and hidden folder control, making it complete for an AI agent to use 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?

With 0% schema description coverage, the description fully compensates by detailing each parameter: account_id, parent_folder_id (None=root), max_depth (1-25, default 10), include_hidden (default False). This adds critical meaning beyond the bare schema types and defaults.

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 ('Recursively build'), resource ('tree of mail folders'), and scope ('read-only, safe for unsupervised use'). It effectively distinguishes the tree-building functionality from sibling tools like emailfolders_list (likely flat) and emailfolders_get (single folder).

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 notes the tool is 'useful for understanding mailbox folder organization,' which implies a hierarchical exploration use case. However, it does not explicitly specify when to avoid this tool in favor of alternatives (e.g., emailfolders_list for flat listing or emailfolders_get for a single folder). The guidance is clear but lacks exclusion criteria.

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

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

Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds value by confirming it is 'safe for unsupervised use' and details metadata like unread counts and child folder information, beyond what annotations convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with a front-loaded purpose indicated by an emoji. It is structured into clear Args and Returns sections, with each sentence adding necessary information. No redundancies.

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

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

With 4 parameters, one required, and an output schema available, the description provides complete context: it explains the return structure (list of folder objects with fields) and all parameter behaviors. There are no gaps for safe 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 has 0% description coverage, meaning the JSON schema itself lacks parameter descriptions. The description compensates fully by explaining each parameter: account_id as Microsoft account ID, parent_folder_id's null vs provided behavior, include_hidden default, and limit's range and default.

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 lists mail folders from a mailbox with a read-only safe behavior. It distinguishes itself from siblings like emailfolders_get (detail) and emailfolders_get_tree (hierarchy) by focusing on listing either root or child 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 explains when to use root vs child folder listing via the parent_folder_id parameter. It does not explicitly state when not to use, but sibling names imply alternatives for specific folder details or tree structure.

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 adds behavioral context beyond annotations: it notes potential slowness for large folders, recommends confirmation, and specifies a ValueError for invalid folder_id. Annotations already indicate idempotent and non-destructive, and the description aligns.

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 well-structured: a clear one-line summary followed by a short elaboration, then structured Args/Returns/Raises sections. 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?

The description covers behavior, parameters, return type, and errors. Given the tool's simplicity and the presence of an output schema (though not detailed here), it is fairly complete. Minor omission: no mention of whether the operation is all-or-nothing.

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 0% description coverage, but the description's Args section provides meaningful explanations for both parameters: folder_id as the folder to mark and account_id as the Microsoft account. This adds value beyond the raw 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 it marks all messages in a folder as read, but does not explicitly differentiate from the sibling email_mark_read tool which works on individual emails. The verb 'mark all' is specific, but lack of direct comparison reduces 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 mentions that the operation may take time and recommends user confirmation, but provides no direct guidance on when to use this tool versus alternatives like email_mark_read. The usage context is implied but not explicit.

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

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

The description adds value beyond annotations by noting user confirmation is recommended and clarifying the move operation's effect. Annotations already indicate non-destructive and idempotent behavior, but the description doesn't contradict them.

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, front-loaded with a summary, and uses a structured Args list. Every sentence adds value 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 covers purpose, parameters, return value, and a safety note. It lacks details on permissions, error handling beyond ValueError, or integration with sibling tools like emailfolders_get_tree, but is adequate given the 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?

With 0% schema description coverage, the description provides clear, helpful explanations for each parameter (folder_id, destination_folder_id, account_id), significantly adding meaning beyond the schema's type and required attributes.

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 ('Move a mail folder to a different parent') and the resource ('mail folder'), distinguishing it from sibling tools like emailfolders_rename or emailfolders_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?

The description mentions user confirmation recommendation but provides no explicit guidance on when to use this tool versus alternatives (e.g., emailfolders_delete, emailfolders_empty), nor when not to use it.

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

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

The description adds behavioral traits beyond annotations: it warns that user confirmation is recommended and lists error conditions (ValueError for invalid folder_id or empty new_display_name). Annotations indicate idempotentHint=true and destructiveHint=false but lack detail on confirmation or error handling.

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 (4 sentences) and well-structured with sections for Args, Returns, and Raises. The emoji front-loads the action, and every sentence provides essential information 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 rename tool with 3 parameters and existing output schema, the description covers purpose, parameters, return ('Updated folder object with new displayName'), and error cases. It lacks details about authentication requirements beyond the account_id parameter, but overall it is complete enough for an agent to understand 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?

With schema description coverage at 0%, the description compensates by explicitly defining each parameter in the Args section: 'folder_id: The folder ID to rename', 'new_display_name: New name for the folder', 'account_id: Microsoft account ID'. This adds meaning beyond the schema's type-only definitions.

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 a mail folder') and the resource ('mail folder'), with a specific verb 'rename' that distinguishes it from sibling tools like emailfolders_create, delete, or move. The title 'Rename Email Folder' reinforces this.

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 (e.g., emailfolders_move, emailfolders_update). The context of 'renaming' is implied but no comparison or exclusion criteria are provided, leaving the agent to infer usage from the name alone.

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

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

The description adds significant behavioral context beyond annotations: forwarding is immediate and irreversible, addresses are validated/deduplicated with a 500 limit, confirm must be true. No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with sections: emoji line, warning, validation info, Args list, Returns, Raises. It is slightly lengthy but each sentence adds value. Front-loaded with purpose and warning.

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 6 parameters, output schema exists, and no enums, the description covers behavior, validation, parameter requirements, and error conditions comprehensively. Returns are summarized as 'Status confirmation', sufficient since output schema exists.

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 0% schema description coverage, the description fully compensates by listing all parameters with explanations: account_id (Microsoft account ID), email_id, to/cc (recipients), body (optional plain text), confirm (must be True). Provides meaning beyond parameter names.

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

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

The description clearly states 'Forward an email to recipients', which is a specific verb and resource. It distinguishes itself from sibling tools like email_send (send new email) and email_reply by specifying forwarding an existing email with an optional comment.

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

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

The description implies when to use (forwarding) and includes warnings and constraints, but does not explicitly compare to alternatives like email_send or email_reply. However, the context from sibling tools makes it fairly 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?

Annotations already cover readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds value by detailing body truncation at 50,000 characters, caching freshness (15 min fresh, 1 hour stale), and the effect of force_refresh. No contradiction.

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 well-structured, using emojis for visual cues, bullet points for clarity, and front-loading the key purpose. Every sentence adds value without unnecessary verbosity.

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 7 parameters, presence of output schema, and annotations, the description is thorough. It covers return values including _cache_status and _cached_at, and explains caching behavior, making it 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?

Schema description coverage is 0%, but the description explains all 7 parameters: email_id, account_id, include_body, body_max_length, include_attachments, use_cache, and force_refresh, including defaults and purpose. This fully compensates for the lack of schema descriptions.

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 retrieves detailed information about a specific email, specifying it's read-only and safe for unsupervised use. It distinguishes itself from sibling tools like email_list and email_get_attachment by focusing on a single email with 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 provides guidance on caching behavior and when to use force_refresh. It also implies safe usage (read-only, unsupervised). However, it does not explicitly mention when not to use this tool versus alternatives like email_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 safety validation via ensure_safe_path and that existing files are never overwritten. This adds value beyond annotations, which already indicate idempotency and non-destructiveness. Missing error handling details, but sufficient for the tool's simplicity.

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: one sentence purpose, then clear Args and Returns sections. No extraneous information; every sentence adds necessary detail.

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

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

Given the presence of an output schema, the description sufficiently covers inputs and key behavior. It lacks error handling descriptions, but for a tool with 4 simple parameters, it is adequately complete.

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

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

With 0% schema description coverage, the description elaborates on each parameter, including validation for save_path and the role of email_id and attachment_id. This compensates well, though format constraints (e.g., path requirements) are not specified.

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 downloads an attachment to a validated local path, using specific verbs and resources. It distinguishes itself from sibling tools like 'email_get' which retrieves the message itself, not the attachment.

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 on when to use this tool versus alternatives such as 'email_get' or other attachment-related tools. The agent must infer usage from the tool 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?

Beyond annotations (readOnlyHint, etc.), the description adds caching details (2 min fresh, 10 min stale), return field information, and parameter behavior (force_refresh). No contradictions.

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 well-structured with sections (Returns, Caching, Args) and an emoji for visual cue. It is slightly verbose but each sentence adds value. Front-loading with purpose is effective.

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 7 parameters, output schema presence, and sibling tools, the description covers all aspects: function, parameters, caching, return format, and safety. No gaps remain.

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 0% but the description's Args section thoroughly explains each parameter: account_id, folder (with allowed values), folder_id, limit (with range), include_body, use_cache, force_refresh. This adds meaning far beyond the schema.

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