Does the description disclose side effects, auth requirements, rate limits, or destructive 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?

简洁明了，先陈述目的，再列出参数。无冗余。

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?

对于变更操作，在无注解、无输出架构且架构描述覆盖率为 0% 的情况下，描述未能提供足够的行为上下文，以便智能体安全地调用。

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?

架构描述覆盖率为 0%，因而基线为 3。描述仅列出了 task_id 及其类型和用途，这些信息架构本身也已体现（名称和必填性），故描述未增加实质意义。

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

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

清晰说明了动词+资源（'将任务标记为已完成'——将任务标记为完成），对应相邻工具中的同级操作（update_task、create_task），尽管它未明确说明与 update_task 的区别。

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?

未提供何时使用此工具而非 update_task 的指导，尤其考虑到标记任务完成可能与将状态设为'已完成'的更新操作重叠。

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

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

With no annotations, the description carries the full burden, and it does disclose useful behavior: 11 parameters, their defaults, and the hard constraint that start/end must be local time in ISO 8601 with UTC+8. It still omits permission/auth needs, what happens with duplicate or conflicting events, and what the call returns or mutates externally.

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 one-line purpose is front-loaded, then a clean parameter list with no filler. Minor redundancy in repeating types/defaults that partly appear in the schema, and inconsistent labeling ('str' vs 'optional', mixed Chinese/English), but it stays tight for an 11-parameter tool.

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

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

For a creation tool with no output schema and no annotations, the description gives the agent enough to construct a valid call, including defaults and the timezone/format rule. It stops short of covering failure modes, permission prerequisites, and post-creation behavior, which an agent would plausibly want.

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 there are 11 parameters, so the description is the only source of parameter meaning — and it documents every one with type, optionality, accepted values ('Text'/'HTML', 'low'/'normal'/'high'), and default. It adds format examples and the local-time requirement that the schema does not.

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

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

The opening line gives a specific verb and resource (创建新日程) and pins the scope to the main calendar with an explicit UTC+8 timezone, which is a real constraint an agent needs. It distinguishes itself from update/list/delete_calendar_event by verb alone; there is no explicit sibling contrast, so it falls short of a 5.

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

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

The description never says when to create a new event versus updating an existing one (update_calendar_event) or how to discover existing events first (list_calendar_events). No prerequisites, permission requirements, or duplicate-handling guidance are given, leaving usage entirely to inference.

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

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

No annotations are provided, so the description carries the full burden. It does add one genuinely useful behavioral constraint — all dates must be UTC+8 local time — which is non-obvious and repeated for every date parameter. However, it says nothing about required permissions/auth, whether the task is returned, error behavior, or duplicate 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 single front-loaded purpose sentence is followed by a tight, consistently formatted parameter list with no filler prose. The bulk is parameter documentation that duplicates the schema's property names, which is necessary given 0% schema description coverage but keeps the block long.

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

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

For a 10-parameter write tool with no annotations and no output schema, the description covers parameters and the timezone rule well. It is still silent on auth requirements, the returned object, and edge behavior (e.g., setting completed_date or status at creation time).

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 there are 10 parameters, yet the description documents each one with type, optionality, and format. It also supplies enum values absent from the schema ('text'/'html', 'low'/'normal'/'high', and the five status values) plus the ISO 8601 timezone convention, which is exactly the compensation required here.

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 opening sentence states a specific verb and resource in a specific product: '在 Microsoft To Do 中创建新任务'. The create_/update_/list_/delete_/complete_ naming convention across siblings makes the action unambiguous, though the description never explicitly contrasts itself with those siblings.

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

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

Usage is implied by the 'create' verb and the To Do context, but there is no explicit when-to-use guidance, no mention of prerequisites, and no pointer to alternatives such as update_task (for existing tasks) or create_calendar_event (for calendar items, which is a realistic confusion in this sibling set).

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

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

No annotations are provided, so the description carries the full behavioral burden. It conveys only that the operation is destructive via the verb 删除, but says nothing about permanence, whether attendees are notified, recurrence handling, required permissions, or error behavior for an invalid ID.

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

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

Two short lines, front-loaded with the action followed by the parameter. Nothing is padded, though the '参数:' block is largely a restatement of a one-field schema and earns limited extra 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 single-parameter destructive tool with no annotations and no output schema, the description covers the action and the parameter but omits the behavioral context (permissions, irreversibility, effect on recurring events) an agent needs before invoking a delete. Adequate but with clear gaps.

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

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

Schema description coverage is 0%, so the description must compensate for the single parameter. It does gloss event_id as the unique ID of the event to delete, adding meaning beyond the schema's bare 'type: string', but it gives no format, source, or validation detail for that ID.

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

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

States a specific verb+resource (删除日历事件 / delete calendar event), which cleanly distinguishes it from the sibling delete_task and delete_email tools. Clear purpose, though it does not proactively name any alternative. It relies on the resource noun alone for differentiation, which is adequate here.

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

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

There is no guidance on when to use this versus update_calendar_event, list_calendar_events, or other delete tools, nor any prerequisites (permissions, required ownership). Usage must be inferred entirely from the name and the single parameter.

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

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

No annotations are provided, so the description carries the full behavioral burden. '删除' implies mutation, but the description never states whether deletion is permanent or reversible, whether permissions are required, or what happens if the ID does not exist — significant gaps for a destructive tool.

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

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

The text is short, front-loaded with the operation, and followed by the parameter list with zero filler. It is efficient, though the brevity reflects under-specification as much as tight writing.

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

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

For a destructive, single-parameter tool with no annotations and no output schema, the description should disclose irreversibility, error behavior, and any permission requirements. None of that is present, leaving the agent unable to predict the consequences of calling 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 description coverage is 0%, so the description must compensate, and it does describe the single parameter as '待删除邮件的唯一 ID'. However, it adds no format, source, or example detail beyond that minimal gloss, so the compensation is only partial.

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

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

The description states a specific verb and resource ('删除电子邮件') that unambiguously identifies the operation. It does not, however, distinguish itself from sibling tools like list_emails or send_email, nor clarify scope such as permanent deletion versus moving to trash.

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

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

There is no when-to-use guidance, no mention of prerequisites (e.g., needing a message_id obtained from list_emails), and no warning about the destructive nature of the call. The agent receives only the bare operation name.

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

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

No annotations are provided, so the description carries the full behavioral burden. For a destructive operation it says nothing about irreversibility, whether confirmation is needed, what the deletion affects (subtasks, reminders), or what is returned. It is essentially a restatement of the name plus the parameter.

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 short and front-loaded: purpose first, then the parameter. It is not bloated, though the parameter block merely echoes the schema and could be trimmed.

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?

A destructive single-parameter tool with no annotations and no output schema needs more than one sentence: irreversibility, error behavior for an unknown ID, and side effects are all absent, leaving the agent underinformed before invoking a delete.

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 must compensate; it does so minimally by glossing task_id as the unique ID of the task to delete. That adds a little meaning (uniqueness, target identity) but omits format, source of the ID, or how to obtain one.

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

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

States a specific verb+resource ('删除任务' / delete task) with an unambiguous scope, so an agent knows exactly what it does. However, it does not distinguish itself from siblings like update_task or complete_task, which are also task-state mutations.

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

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

There is no when-to-use guidance, no prerequisite conditions, and no mention of alternatives such as complete_task (which may be preferable if the intent is to finish rather than remove a task). Only implied usage from the name.

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

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

No annotations are provided, so the description carries the full burden; it discloses the timezone of the result (UTC+8), which is the key behavioral fact an agent needs to interpret the value. For a trivial local-clock read there are no auth, rate-limit, or destructive concerns to disclose, so the remaining gap is minor.

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

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

Two short sentences, zero waste; the resource and its scope come first and the mandatory-usage rule is front-loaded right after.

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

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

For a no-param, no-output-schema utility, the description covers what it does, where the time comes from (local, UTC+8), and the workflow role it plays. It could say a bit more about the returned format, but nothing essential for correct invocation is missing.

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

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

Zero parameters, so per the rubric the baseline is 4. The schema is empty and 100% covered, and the description adds the timezone context that the empty schema cannot convey.

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

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

States a specific verb ('获取') and resource ('当前本地时间') plus a concrete scope qualifier (UTC+8), which disambiguates it from the calendar/task/email siblings that also deal with time. An agent can tell exactly what this returns without opening anything else.

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 tells the agent when to call it: before handling relative-time requests, as a reference-time anchor, with a strong '【必须】' marker. It stops short of naming alternatives or when-not-to-call conditions, but the trigger condition is unambiguous.

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

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

No annotations are provided, so the description carries the full disclosure burden. It does add real behavioral context: the tool operates in UTC+8 and inputs must be local time. However, it never states permissions/read-only nature explicitly, whether results are cached or real-time, or anything about the shape or pagination of the returned occupancy data.

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

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

Front-loads the '[primary choice]' marker, follows with purpose, then the routing rule, then a compact parameter block. The 'more efficient and intuitive' clause is mild filler but the overall structure is tight and scannable.

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

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

For a 3-parameter read tool with no annotations and no output schema, the description covers purpose, routing, timezone, formats, and defaults adequately. The main gap is that the structure of the returned occupancy (per time slot) is only obliquely implied by availability_view_interval rather than described.

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 must compensate and largely does: it documents all three parameters with ISO 8601 format, the 'must be local time' constraint, and the default of 30 minutes for availability_view_interval. Only the interaction between interval and the returned slots is left implicit.

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

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

States a specific verb+resource (check whether the current user is free in a given time range) and explicitly positions itself against the sibling list_calendar_events. An agent can distinguish it from the raw event-listing tool without opening any schema.

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

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

Gives explicit trigger phrasing ('am I free?', 'is there a conflict?', 'check my busy/free') and a hard routing rule: prefer this over list_calendar_events. It even names the reason (more efficient, more intuitive occupancy view). This is as prescriptive as usage guidance gets.

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?

没有提供注解，因此描述需要承载告知义务。描述了时区要求和前置条件，这是有用的行为背景。但没有说明权限需求、返回格式或分页行为——对于一个未注解的读取工具，这是一个缺口。

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?

前置条件放在前面，并使用了 '[注意]' 标注，这很好。但 '参数:' 部分重复了模式信息，虽然值增加了格式说明。'[时区]' 行也是冗余的，因为参数描述已经说了必须是本地时间。稍微有些啰嗦。

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?

对于一个没有注解、没有输出模式且模式覆盖率为 0% 的简单读取工具，描述涵盖了前置条件和参数格式。但没有说明返回值（例如，没有日期范围时会怎样，有哪些事件字段）。对于一个未注解的工具来说，基本够用，但缺少一些经过判断后应补充的细节。

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?

模式描述覆盖率为 0%，描述必须进行补偿。它确实为两个参数提供了 ISO 8601 格式示例、时间范围和时区限制。这很有帮助，但没有解释 start_date/end_date 的默认值行为——没有它们时是查询所有事件还是无内容。

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?

明确说明了动词和资源——'列出用户主日历中的事件'——并限定了作用域为主日历。没有明确指出与 list_tasks 或 get_user_schedules 等同类工具的区别，但资源名称不同。

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?

提供了明确的前置条件：调用前必须先执行 get_current_time 获取当前时间。没有给出何时使用此工具而非 get_user_schedules 等替代项的指导。

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

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

No annotations are provided, so the description carries full behavioral burden. It discloses the timezone (UTC+8) and default limit, but omits whether the operation is read-only, what authentication is required, how pagination works, or what format the returned emails take.

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, then cleanly separates the parameter explanation. It is short, avoids redundancy, and every sentence contributes needed information.

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

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

For a simple one-parameter list tool with no output schema or annotations, the description is minimally adequate. However, it lacks return-value context and any mention of pagination or authorization, leaving gaps an agent may need before invoking 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 description coverage is 0%, so the description must compensate for the single parameter. It explains that 'limit' is an optional integer controlling the maximum number of returned emails, with a default of 10, adding meaningful semantics beyond the bare schema type 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?

States a specific verb and resource ('列出收件箱中的最近邮件') with a timezone qualifier, clearly separating it from send_email and delete_email. It does not explicitly name or contrast with sibling tools, but the resource scope is distinct enough to prevent confusion.

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. The description implies retrieval of recent emails, but gives no conditions, exclusions, or sibling comparisons such as using send_email when you need to compose instead.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it discloses nothing about pagination, result ordering, whether completed tasks are included, or auth requirements. Listing is implicitly a read, but that is an inference rather than a stated trait.

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

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

A single front-loaded sentence with no filler; the verb and scope come first. It is appropriately sized for a zero-parameter tool, though it is terse to the point of being sparse.

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

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

With no output schema and no annotations, the description is the only source of return-value and safety information, and it supplies neither. For a simple list tool the burden is light, but an agent still cannot tell what comes back or whether filtering applies.

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 zero parameters, so there is nothing for the description to clarify. Baseline 4 applies; no parameter-level gaps exist to compensate for.

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

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

States a specific verb (列出) and resource (任务) with an explicit scope: the user's default to-do list. It distinguishes itself from list_emails and list_calendar_events by resource, but never names a sibling or clarifies why this differs from any other task-listing path.

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

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

The phrase '默认待办事项列表' hints that non-default lists are out of scope, but the description gives no explicit when-to-use guidance and does not mention alternatives such as list_calendar_events or get_user_schedules. The agent must infer the calling context entirely.

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?

无注解，因此描述需完全承担行为披露的责任。它没有说明权限、发送后可达性、速率限制或撤销可能性。对于包含 3 个参数的修改工具，是一个很大的缺口。

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?

结构清晰但有些啰嗦，重复“邮件”概念。参数列表比需要更冗长，虽然引言简短。

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?

对于包含 3 个必需参数的修改工具，没有注解、没有输出模式、0% 模式覆盖率，描述严重不足。它未能涵盖基本行为或使用上下文。

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?

模式描述覆盖率为 0%，因此参数必须在描述中补偿。描述为每个参数提供了简短标签（to, subject, body），这略有帮助，但缺乏格式、约束或验证细节。

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?

明确指出了动词+资源（发送电子邮件），与 list_emails 和 delete_email 等兄弟工具区分开来。然而，它没有描述作用域或任何与兄弟工具的区别，只是陈述了功能。

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?

没有指导说明何时使用此工具而非替代方案。没有提及先决条件、上下文或与 list_emails/delete_email 相关的条件。

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

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

With no annotations, the description carries the full burden. It usefully discloses that times are UTC+8, that start/end must be local time, and that unspecified fields are left untouched — real behavioral context. It omits permissions, side effects on existing reminders/attendees, and error behavior for a mutation tool.

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

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

Front-loaded one-line purpose followed by a scannable parameter list; every line carries information. Slightly list-heavy but no filler or redundancy.

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

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

For a 12-parameter mutation with no annotations and no output schema, the description supplies the missing parameter documentation and the partial-update/timezone semantics an agent needs to call it correctly. It stops short of covering failure modes or auth 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?

Schema description coverage is 0%, so the description must compensate, and it largely does: all 12 parameters are enumerated with types, optional/required status, and value hints ('Text'/'HTML', 'low'/'normal'/'high'). Remaining gaps are ranges (reminder_minutes) and interactions (is_reminder_on vs reminder_minutes).

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

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

The description states a specific verb (更新/update) and resource (日历事件/calendar event) plus a scoping constraint (UTC+8), which cleanly separates it from create_/delete_/list_calendar_event. It does not explicitly name a sibling or contrast behavior, so it falls short of a 5.

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

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

Usage context is implied: it updates an *existing* event and only touches provided fields, which tells the agent partial-update semantics. However it never says when to prefer this over create_calendar_event, nor any prerequisites beyond requiring event_id.

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

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

没有提供注释，因此描述承载了全部行为披露负担。它说任务是“现有的”，但未说明权限要求、操作是否可逆、未提供的字段会发生什么，或单个字段更新是否会产生任何副作用。

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?

简洁、结构良好，并以前置过滤条件开头。参数列表是组织有序的，但 'UTC+8' 的提及在日期参数中重复了四次，可以巩固。

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?

对于一个修改现有资源的工具来说，该描述基本完整，但缺乏行为上下文。它缺少模式以外的信息，例如如果任务不存在会发生什么、验证规则（例如，'status' 是否必须匹配枚举值？）以及权限要求。

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?

尽管输入模式覆盖率 0%，但描述在参数列表中提供了每个参数的文档。这增加了模式中没有的意义（例如，'text' 或 'html' 的枚举值、ISO 8601 的日期格式、UTC+8 的要求）。然而，11 个参数中有一半的语义可以更详细（例如，'status' 的有效值、'importance' 的含义）。

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?

明确说明了动词 (更新)、资源 (Microsoft To Do 中现有的任务) 以及应用的时区约束 (UTC+8)。与 create_task、delete_task 和 complete_task 等兄弟工具区分开来，因为它是通用的修改操作。

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?

没有说明何时使用此工具与 complete_task（用于标记完成）或 create_task 相对。也没有解释可选参数会如何修改现有值的语义（例如，未提供的字段是否会保持原样？）。

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