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 does disclose a key non-obvious behavior—no sending—as well as the time window and the filtering rule. But it leaves ambiguous whether the generated drafts are returned to the caller or persisted somewhere, and it does not mention permissions or other side effects.

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

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

The description is one compact sentence that front-loads the investigation scope and closes with an important limitation. Every clause carries useful information, and there is no repetition of the tool name or empty filler.

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

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

With no output schema and no annotations, the description should clarify what the caller actually receives. It says it 'creates draft replies' but does not state whether those drafts are returned as data, saved into Outlook/Teams, or both. This is a meaningful gap for an agent that needs to know how to use the tool's result.

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 JSON schema already documents all four parameters with descriptions and defaults, so schema description coverage is 100%. The description mostly restates the default time window and the source names without adding deeper parameter semantics. This meets the baseline but does not go beyond it.

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

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

The description states a clear action scope: it investigates Outlook, Teams, and meetings over a past time window and extracts only items requiring the user's reply. It also ends with '送信はしない', explicitly distinguishing it from sending tools. However, it does not differentiate itself from sibling tools like 'hey365_triage' or 'hey365_draft', so it is clear but not sibling-specific.

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

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

The phrase '送信はしない' gives an explicit non-goal, which helps rule out sending workflows. It does not, however, explain when to prefer this tool over 'hey365_triage' or 'hey365_draft', and no alternative tool names are mentioned. Usage context is implied rather than explicitly routed.

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 states the core mutation (modifying an existing draft) but does not disclose what the tool returns, whether the refinement persists, or whether the original draft is replaced. For a mutating refinement tool with zero annotation coverage, this is a significant 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?

A single front-loaded sentence states verb, resource, and mode, with parenthetical examples that clarify the instruction format. Every element earns its place and there is zero filler.

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

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

For a 2-parameter tool with full schema coverage, the description is nearly sufficient. However, with no output schema and no annotations, it fails to state what the agent should expect back (the refined draft text) or that a draft must already exist in the session. The workflow relationship to sibling tools is only implied.

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

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

Schema description coverage is 100% — both itemId and instruction have clear Japanese descriptions, so the baseline of 3 applies. The tool description adds only marginal value by framing instruction as natural-language editing examples, partially overlapping with the schema's own examples. No parameter is left undocumented.

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 (修正する/modify), a specific resource (既に提示した返信案, the already-presented reply draft), and the method (natural language instructions), with concrete examples (柔らかく/英語に/短く). The 'already presented' qualifier implicitly differentiates it from sibling draft-creation tools like hey365. The purpose is unambiguous.

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

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

The phrase '既に提示した返信案' implies the tool is only for refining a draft that already exists in the conversation, which is useful context. However, it names no alternatives (e.g., hey365 to create a draft, hey365_send to send) and gives no explicit when-not-to-use guidance. Usage is implied rather than stated.

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

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

With no annotations, the description carries the full burden. The verb '確認する' implies a read-only diagnostic, and the listed checks add useful behavioral context. However, it does not explicitly state that no data is modified, whether external services are contacted, or what happens on failure.

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?

One short, front-loaded sentence that states the tool's entire purpose with no filler. Every word contributes meaning, and the optional parameter detail is left to the schema where it belongs.

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

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

For a simple tool with one optional boolean parameter, the definition is reasonable. Still, with no output schema and no annotations, it does not explain the return shape, success/failure indicators, or that the check is non-mutating, leaving some ambiguity for an agent 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 100%: the single optional 'deep' parameter is fully documented in the schema, including its effect on Outlook/Teams/Calendar reachability. The tool description adds nothing beyond this, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb ('確認する' / check) and names the exact resource scope: Work IQ connection, authentication, read/write permissions, and timezone. This clearly distinguishes it from sibling tools like hey365_send or hey365_setup, making the health-check purpose unmistakable.

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 health-check purpose makes it inferable when to use the tool: when verifying connectivity, auth, permissions, or timezone. However, there is no explicit guidance about when not to use it or which sibling tool (e.g., hey365_setup) should be used instead, so routing is left mostly 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?

注釈が一切ないため、説明が動作特性を説明する責任を負うが、設定ファイルの変更や上書き、必要な権限などの副作用が開示されていない。dryRun パラメータが書き込み動作を暗示するが、本体説明には明記されていない。

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?

1文で目的が完結しており、冗長な表現や無関係な情報がない。対象クライアントの列挙も具体的で、情報が前寄せされている。

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?

2つの任意パラメータはスキーマで完全に説明されており、ツール自体は単純。ただし、出力スキーマも注釈もないため、実行結果や成功・失敗時の挙動、ファイル変更の具体的な影響についての説明が欠けており、完全とは言えない。

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?

スキーマの説明カバレッジは 100% であり、dryRun と clients の意味はスキーマが十分に説明している。ツール説明自体はパラメータの追加情報をほぼ提供していないため、ベースラインの 3 が妥当。

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

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

説明は「Hey365 を MCP 設定に登録する」という具体的な動詞と対象を示し、対象クライアントも列挙されているため、何をするツールかは明確。ただし、兄弟ツールの hey365_setup との使い分けが明示されておらず、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?

説明は動作内容のみで、どのような場面で使うべきか、または hey365_setup など代替ツールとどう使い分けるかが一切書かれていない。エージェントはツール名と文脈から推測するしかない。

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 of disclosing behavior. It explicitly states that it only sends user-approved reply drafts as replies to original threads and does not create new threads, adding important behavioral context beyond the input schema. It does not mention irreversibility or failure behavior, but the core side effects are clearly disclosed.

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

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

A single compact sentence front-loads the critical constraint ('only explicitly instructed reply drafts') before stating the action and the new-thread exclusion. There is 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?

The tool is simple with two fully documented parameters, and the core behavior is clearly described, including what it does not do. With no output schema, it leaves the agent to infer the return value and error behavior, but this is a minor gap for a low-complexity send tool.

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

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

Schema description coverage is 100%, so the baseline is 3; both itemIds and confirm are already documented with concrete examples and intent. The tool description reinforces the confirm semantics but does not add substantial parameter-level detail beyond the schema.

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

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

The description uses a specific verb-resource pair ('sent reply drafts') and clearly defines the scope: only explicitly instructed reply drafts, sent as replies to original threads, with no new thread creation. This distinguishes it from sibling tools like hey365_draft and from general send operations.

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

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

The description states an explicit precondition: send only when the user has explicitly instructed a reply draft to be sent, which tells the agent when to invoke it. It does not name alternatives such as hey365_draft nor provide direct when-not-to-use guidance beyond the no-new-thread note, so it stops short of full routing guidance.

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

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

No annotations are provided, so the description carries the full burden. It discloses the outputs (decisions, action items, etc.) and implies a read-only summarization operation, but it doesn't explicitly state whether it modifies anything, requires specific permissions, or has any side effects. It also doesn't mention the behavior of includeDraft beyond what the schema says. It's transparent about outputs but not about the operation's side effects.

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

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

The description is a single, front-loaded sentence that immediately states the action (summarize) and then enumerates the outputs. It is efficient with no wasted words and clearly structured.

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 lists all key output categories (decisions, action items, homework, unresolved items, reply need) and the optional draft generation is captured by the schema. No output schema exists, so the description adequately specifies the expected return content. It could mention prerequisites like authentication, but given the sibling suite, setup likely handles that. Overall, it's sufficiently complete for an agent to call it correctly.

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

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

Schema description coverage is 100% for both parameters (sessionId and includeDraft), so the schema already documents them well. The tool description does not add extra parameter semantics beyond what the schema provides; it only references the output categories. Baseline 3 is appropriate.

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

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

The description clearly states it summarizes meetings/Teams threads/Outlook conversations and lists the specific outputs (decisions, action items, homework, unresolved items, reply need). This is a specific verb+resource combination and distinguishes it from sibling tools like hey365_draft or hey365_send, though it doesn't explicitly name them. It's not a tautology and provides clear intent.

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: if you need a summary of a session, use this tool. However, it doesn't explicitly state when to use it versus siblings like hey365_triage or hey365_draft, nor does it provide exclusions or alternative conditions. The context is clear but not fully 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the actions (installation, Broker disablement, browser authentication) but does not disclose side effects, required privileges, reversibility, or impact on existing settings. For a recovery/mutation tool, this is a significant gap; the agent cannot assess risks or prerequisites.

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, concise sentence in Japanese that front-loads the trigger conditions and clearly states the recovery actions. Every clause serves a purpose, with 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?

The description is adequate for a two-boolean-parameter tool with no output schema, but it lacks information about expected outcomes, return values, or side effects. Given no annotations and no output schema, an agent may not know what to expect after invoking it. It explains 'what' and 'when' but not 'what happens after' or potential pitfalls.

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

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

Schema description coverage is 100% for both parameters (force and interactive), and the schema already explains their meaning. The description adds no additional semantic value beyond what the schema provides. Baseline 3 is appropriate since the schema covers the parameters fully.

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 purpose: recover Work IQ when it is uninstalled, unauthenticated, or WAM auth fails, by performing installation, Broker disabling, and browser authentication. The verb '復旧する' (recover) plus the resource (Work IQ) and explicit conditions clearly distinguish it from siblings like hey365_install, which likely only handles installation.

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

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

The description provides explicit conditions for use: '未インストール・未認証・WAM 認証失敗の場合' (when not installed, not authenticated, or WAM auth fails). It does not explicitly mention alternatives or exclusions, but the condition is specific enough to guide selection among siblings. Lacks a clear statement of when not to use it, such as when only installation is needed.

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

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

Annotations are absent, so the description must disclose behavioral traits. It only states that the tool investigates and extracts items, but does not mention potential side effects like draft generation (implied by includeDrafts), permission requirements, or whether it mutates data. The parameter includeDrafts suggests the tool may create drafts, but this is not disclosed in the description.

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

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

The description is two brief sentences, front-loading the alias relationship and then stating the core function. It contains no redundant words and is appropriately sized for a simple alias 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?

The description lacks critical information such as return value format, behavioral side effects, and usage distinctions. Without an output schema or annotations, the agent needs more detail about what the tool returns and whether it has write-side effects. The includeDrafts parameter is particularly ambiguous without explanation in the description.

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

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

Schema coverage is 100%, so the description need not repeat schema details. It adds the phrase 'past N hours' which maps to the hours parameter, but this is already in the schema description. No additional meaning is provided for limit, sources, or includeDrafts.

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 it is the same as hey365 and provides the action 'investigate M365 for the past N hours and extract items requiring action.' This is a specific verb-resource pair and distinguishes it from other siblings like hey365_health or hey365_setup. However, since hey365 is a sibling, the description relies on the alias relationship rather than fully independent differentiation.

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 only says 'same as hey365' and gives no conditions for when to use this tool over alternatives. It does not mention when-not-to-use or name alternative tools for comparison. An agent cannot tell whether to call this or hey365, as both appear to serve identical purposes.

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