Hey365 client install

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.