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

No annotations are provided, so the description carries the full burden. It usefully discloses that the subject returned by weekly_report is a server auto-advanced default and usually need not be resubmitted, which is real behavioral context. But it says nothing about confirmation types, permissions, or the consequences of submitting the resume path.

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 two purposes, then follows with the weekly_report format detail and the subject note. Content is dense but each sentence carries information; minor redundancy in re-explaining the subject.

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?

An output schema exists so return values need not be described. For a 2-param tool with a nested object at 0% schema coverage, the weekly_report selections are well covered but resume_token and the confirmation-type selections are left undefined, so an agent cannot fully call the resume path with confidence.

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

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

Schema description coverage is 0%, so the description must compensate. It does document the selections structure in detail (changes with short id/text, optional subject, worked example), but resume_token — the central parameter for a resume tool — is never explained beyond the implied 'resume' sense.

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 dual purpose: resume people/mail/time confirmations, or submit weekly_report modifications. The verb+resource is clear and it distinguishes the weekly_report path from the sibling of the same name. It stops short of explaining how the two modes relate.

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 concrete guidance for the weekly_report path (selections supports only changes and optional subject, with an id/text example). However it offers no when-to-use guidance for the resume path — it never says how a resume_token arises or what condition should lead an agent here instead of a sibling.

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 delivers: it guarantees the draft is never sent and that all attachments undergo path and size validation before the first Exchange write, which is meaningful safety/consistency context. It omits auth requirements and what happens to fields not supplied.

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

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

Three short sentences with the purpose, the no-send guarantee and the routing constraint front-loaded; little waste. It is efficient, though the second sentence could be tightened 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?

An output schema exists so return values need not be described, and the description covers the two non-obvious parameters plus the critical safety behavior. For an 8-param mutation tool with zero annotation coverage it is largely sufficient, though additional field-level context would help.

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% across 8 params, so the description must compensate. It adds real meaning for draft_ref (mail-draft reference only) and attachments (must live in allowed directories, size-checked), but says nothing about cc/to/bcc/subject/body_html/importance beyond their self-evident names, so half the parameters remain unelaborated.

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?

Names a specific verb (修改/edit) and resource (邮件草稿/mail draft), states the scope (may append local attachments, never sends), and explicitly separates itself from a sibling by declaring that meetings must use save_meeting. An agent can tell this apart from save_meeting without opening either 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 clear routing: draft_ref is only a mail-draft reference and meetings must go to save_meeting, which is a concrete alternative. However it does not clarify when to use this versus the sibling save_mail_draft (creating/persisting a draft), leaving that boundary 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?

With no annotations, the description carries the full burden, and it does disclose useful non-obvious behavior: attendee queries accept only pinyin names or full emails, the current user is injected as Organizer by default, and working-hours data comes from Exchange with a local-calendar fallback. It does not state whether the tool only reads calendars (no invites sent) or anything about result limits or errors.

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

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

Three short, front-loaded sentences with no filler; the core action leads and the constraints follow. It is efficient, though it under-covers rather than over-explains.

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

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

For a 9-parameter tool with 0% schema coverage and no annotations, the description leaves most inputs undefined. The presence of an output schema excuses return-value discussion, but the input-side gaps are substantial.

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% across 9 parameters, so the description must compensate, yet it only addresses attendee_queries format and partially respect_attendee_working_hours and include_self semantics. Window format, duration_minutes, interval_minutes, max_results, and lookback_days are entirely unexplained.

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 — parsing attendees and finding shared free time — which is a distinct capability from siblings like read_calendar or save_meeting. However, it never explicitly contrasts itself with those siblings, so an agent must infer the boundary.

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 statement of when to use this tool versus read_calendar or send_meeting_invitation, and no prerequisites beyond the mention of which attendees are accepted. The default-organizer note hints at behavior but does not guide tool selection.

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, and it does little: 'read' implies a safe operation, but permission requirements, whether results are paginated (a limit param exists), and what happens with an empty range are all unstated. For a parameterized read with zero annotation coverage, this is a notable gap.

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

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

Two short sentences, zero filler, with the mode distinction front-loaded. Every clause directly supports correct invocation.

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?

An output schema exists so return values need not be explained, which the description correctly omits. Still, with 4 undocumented params, no annotations, and no sibling differentiation, the definition leaves the agent guessing about limit semantics and timestamp formatting.

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% and there are 4 params, so the description must compensate — it does partially, by defining the mutually exclusive roles of calendar_ref vs. start/end. However, 'limit' is never mentioned and the expected format of start/end (ISO string? date?) is left undefined in both schema and description.

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

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

The description names a specific verb+resource ('read/list calendar items') and, unusually, distinguishes two operating modes — single-item read via calendar_ref vs. range listing via start/end. It is clearer than most siblings' abbreviated names, though it never explicitly contrasts itself with calendar-adjacent siblings like find_meeting_times or save_meeting.

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

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

It gives concrete routing rules: supply only calendar_ref for a single item, supply start/end for a listing. That is real when-to-use guidance. It stops short of naming alternatives (e.g. use find_meeting_times to schedule) or stating what happens if both modes' params are mixed.

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 discloses a real constraint (exactly one of message_ref/draft_ref, no raw Exchange ItemId), which is useful, but says nothing about permissions, error behavior, or side effects. readOnly could be inferred but is not stated.

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

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

Two compact sentences with no filler; the return-value summary is front-loaded and the constraint follows. Size is appropriate for the tool's simplicity. Minor deduction because the constraint sentence could be sharper.

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?

An output schema exists, so return values needn't be explained in prose. But with zero annotations and zero schema description coverage, the description should say more about the ref formats, permission needs, and the max_body_chars parameter to be fully actionable. It covers the critical mutual-exclusivity rule but leaves other 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 schema provides only names/types and no semantic help. The description does add meaning: it clarifies that message_ref and draft_ref are mutually exclusive and exactly-one-required, and that raw Exchange ItemId is rejected. However, it never explains max_body_chars or the ref format, so compensation is 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?

States a specific verb (读取) and resources (邮件或草稿) plus what fields are returned (正文、收发件人、附件元数据). Distinguishes itself from write siblings like save_mail_draft/edit_mail_draft by being a read operation, though there is no explicit sibling differentiation (e.g., vs search_mail).

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

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

No when-to-use or when-not-to-use guidance relative to alternatives. The only usage-adjacent note is a mutual-exclusivity constraint on identifiers, which is a parameter rule, not tool-selection guidance. An agent has no signal why it should pick read_mail over search_mail.

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 does meaningfully: it discloses that bare pinyin collects candidates across all configured company domains by email local-part prefix, that it does not prefer non-digit-suffixed emails, and that auto-selection only fires when exactly one candidate has historical correspondence. It omits permission/auth requirements and result shape, but the disambiguation semantics are unusually well surfaced.

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 dense, front-loaded sentences with no filler; the core resolution contract comes first and the disambiguation edge cases follow. Nothing padding, though it is information-heavy for its length.

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?

An output schema exists, so return values need not be described, and the disambiguation logic is covered. However, with no annotations and 0% parameter coverage, gaps remain around limit/lookback_days semantics and the absence of any mutation/side-effect statement for what is an identity-resolving lookup.

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 effectively documents the query parameter (pinyin vs full email) and the trigger logic behind auto_select, but leaves 'limit' and 'lookback_days' unexplained (the '历史来往' reference only vaguely implies a history window). Partial compensation for a 4-parameter, zero-coverage schema.

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

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

The description states a specific verb and resource ('解析人员' / resolve people) via pinyin name or full email, and adds the disambiguation mechanism. It clearly distinguishes itself from the mail/calendar siblings, none of which resolve identities, though it does not name those siblings explicitly.

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

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

Usage is implied rather than stated: an agent infers this is a name/email-to-person lookup, but there is no explicit when-to-use, when-not-to-use, or pointer to a prerequisite such as resolving a person before sending an invitation. The rules about bare pinyin describe behavior more than they route the agent between tools.

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

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

With no annotations, the description carries the burden and does disclose the key behavioral trait — the draft is never sent (non-destructive, non-delivering) — plus the mode-dependent recipient rules that would otherwise cause errors. It does not cover whether drafts persist/overwrite or whether permissions are needed, but the safety profile is clear and an output schema exists for returns.

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 purpose and the never-sends constraint, then a dense block of conditional parameter rules; no filler sentences. It is slightly terse/run-on across four sentences but every clause carries actionable information.

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

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

For a 9-parameter, mode-conditional mutation tool with zero annotations, the description covers the critical selection logic and the safety boundary, and an output schema handles return values. It falls short on the auxiliary parameters (attachments, cc/bcc, lookback_days), which an agent may need to guess about.

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 for the hardest part: mode-conditional requiredness of subject/to_queries/source_message_ref and the recipient restrictions on reply/reply_all/forward. However cc_queries, bcc_queries, attachments, and lookback_days get no mention, leaving roughly half the parameters undocumented anywhere.

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

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

States a specific verb+resource ('新建...邮件草稿' = create mail drafts) across four named modes and immediately bounds scope with '绝不发送' (never sends), which cleanly separates it from any send action. It also names the sibling edit_mail_draft as the follow-up 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?

Gives explicit per-mode routing: compose requires subject/to_queries, other modes require source_message_ref, reply/reply_all take no recipients, forward requires to_queries. It also states the follow-up condition for edit_mail_draft, so an agent knows both when to pick this tool and what to do next.

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

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

No annotations are provided, so the description carries the burden and does useful work: it discloses the persistent draft/unsent state, which fields are conditionally required, and that attendee_queries changes semantics between create (resolvable queries) and update (full emails only). It does not cover permissions or what happens to omitted fields on update, which keeps it short of a 5.

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

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

Front-loads the purpose and state invariant, then presents the create/update branches in separate, scannable clauses with no filler. Slightly dense for a three-line description but every clause carries operational information.

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

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

An output schema exists so return values need no explanation, and the draft-state disclosure substantially de-risks the mutation. Remaining gaps are secondary — no auth/permission context and no statement about how update handles unspecified fields.

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% across 11 parameters, so the description must compensate. It adds real meaning for the conditional params (calendar_ref, attendee_queries, subject, body_html, start/end) and their requiredness per mode, but leaves location, lookback_days, reminder_minutes, check_availability, and optional_attendees entirely unexplained in both schema and description.

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

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

States a specific verb set and resource — creates or modifies a meeting — and immediately pins down the invariant that the item is always left unsent. It also names its two relevant siblings (find_meeting_times, send_meeting_invitation), so an agent can place it precisely among the calendar tools.

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

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

Gives explicit branch conditions: no calendar_ref → create (with required fields listed); calendar_ref present → update an existing unsent meeting. It also routes two adjacent needs to alternatives — candidate-time lookup to find_meeting_times and invitation sending to send_meeting_invitation.

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

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

With no annotations, the description carries the full behavioral burden and does disclose meaningful traits: the type-safe ref distinction (drafts are not disguised as replyable messages), server-side name/pinyin disambiguation, and the resume_token handoff to continue_action. It omits safety profile (read-only vs mutating), pagination behavior despite limit/offset, and rate limits, so it is strong but not complete.

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?

Dense but front-loaded: purpose and return contract come first, then default behavior, then the resume flow. Four short sentences, each carrying information with no filler. Slightly terse for the amount of undocumented surface it must cover.

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?

An output schema exists, so return values need not be explained, and the description does describe the ref/resume contract. But against 11 parameters at 0% schema coverage and zero annotations, the description leaves most filter parameters semantically undefined, which is a real gap for a query tool of 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?

Schema description coverage is 0% across 11 parameters, so the description must compensate and largely fails to. It only alludes to filter semantics indirectly ('无过滤条件时' covers folders defaults, and '姓名拼音或完整邮箱由 Server 解析' touches sender/participant query resolution), leaving after, before, limit, offset, lookback_days, unread_only, has_attachments and subject_contains completely undocumented in both schema and description.

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

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

The description opens with a clear verb+resource ('统一查找邮件') and immediately specifies the return contract: message_ref for regular mail, draft_ref for drafts. This distinguishes it from read_mail (single message retrieval) implicitly, though it never names a sibling as an alternative. Purpose is clear but sibling differentiation is only partial.

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

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

It gives one concrete usage scenario (no filters → lists recent inbox/sentitems mail) and explains that a resume_token is returned when user disambiguation is needed, which continue_action restores. However, it never states when to prefer search_mail over read_mail, nor any conditions/exclusions around filtering. Guidance is implied and incomplete.

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

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

No annotations are provided, so the description carries the full burden: it discloses a deliberate send gate (default false means nothing is sent), idempotency-style protection against duplicate invites, and a hard cross-tool prerequisite on calendar_ref. It omits what happens after a successful send (recall/cancellation) and any permission requirements, which matters for an unannotated, irreversible-looking mutation.

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

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

Three short lines, front-loaded with the action and the gating condition, followed by rejection behavior and the prerequisite. No sentence is redundant with the name or schema.

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

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

An output schema exists, so return values need not be explained, and the description covers the mutation's precondition and failure states. For a write tool with zero annotations, a note on permissions or post-send irreversibility would close the remaining 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%, so the description must compensate, and it does for both parameters: confirm_send is given real gating semantics (explicit true required, default false is a no-op) and calendar_ref is given provenance (must come from save_meeting/read_calendar). Only the expected format/identity of calendar_ref is left unstated.

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 (send a saved, not-yet-sent meeting invitation) and immediately distinguishes itself from save_meeting and read_calendar, which it names as the sources of calendar_ref. An agent can tell this apart from its siblings without opening a schema.

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

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

Explicitly names the precondition (confirm_send=true must be set explicitly), the states that cause rejection (already-sent or cancelled meetings, to avoid duplicate invitations), and the alternative tools that supply the required reference. This is effectively when-to-use, when-not-to-use and alternatives in three lines.

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 discharges it: it specifies the returned JSON fields, the meaning and immutability of slots.id and loc, that it never creates drafts or exposes HTML, that the Server auto-advances Subject dates and chooses Reply All vs new draft, and the exact token-reuse/expiry rules. This is unusually rich disclosure for a mutation-style workflow.

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 long but dense, front-loaded with the identity claim and the critical semantics of `request` before moving to return shape and workflow. Given the complexity of the slot-routing and token lifecycle, most sentences earn their place, though a few procedural details 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?

An output schema exists, yet the description still helpfully covers the return payload, token lifecycle, subject auto-advance, and the two-step continue_action handoff, so the workflow is complete. The main shortfall is the undocumented non-required parameters, which leaves how the tool sources prior weekly reports implicit.

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

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

Schema description coverage is 0% across 6 parameters, so the description must compensate. It thoroughly explains only `request`; folder, folders, lookback_days, subject_contains, and reference_materials (a nested object array) are never explained, leaving an agent to guess how prior reports are located or what reference_materials should contain.

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 declares itself the sole Agent entry point for weekly-report (周报) requests, a specific verb+resource, and explicitly distinguishes itself from siblings by stating it does not search other people's mail (search_mail/read_mail do). An agent can tell it apart from the mail and draft tools without opening schemas.

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

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

It gives explicit when-to-use sequencing: do search_mail/read_mail + LLM summarization first, then pass the summarized result as request, and specifically warns not to pass meta-instructions like '去搜索并总结 A、B' verbatim. It also names the follow-up tool (continue_action) and the conditions for re-invoking weekly_report.

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