set_dispatch_outcome【需要登录】对已接受的安排反馈用户告知的结果：HELPFUL 有帮助、OK 一般、NO_REPLY 没回复、NO_SHOW 没聊上、NOT_FIT 不合适。可能完成步骤、安排下一步或补排人，消耗平台 LLM 并可能通知。不要根据已读或时间猜测用户结果。结果不明或超时后先查询现值，不要自动重发；服务没有持久请求去重键。 用 get_my_dispatch 核对。
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | ||
| outcome | Yes | ||
| arrangementId | Yes |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare destructiveHint=false, so the description carries most of the behavioral burden and does so well: it discloses login requirement, possible step completion, next-step scheduling, adding people, LLM consumption, notifications, and lack of a durable request dedup key. That is meaningful context beyond what the annotation provides.
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 dense but front-loaded: login requirement and outcome meaning come first, followed by side effects and safety cautions. Every sentence adds operational value, including the no-dedup and do-not-guess warnings.
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 mutation tool with sparse annotations and no output schema, the description covers side effects, notification behavior, LLM cost, and safe retry/verification behavior. The main remaining gap is the optional note parameter and the exact meaning/source of arrangementId.
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 glosses the outcome enum values in Chinese and implies arrangementId can be checked via get_my_dispatch, but it does not explain arrangementId's origin or the optional note field, leaving gaps for two of three parameters.
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: report the user-told outcome for an accepted dispatch arrangement. It distinguishes itself from read-only siblings by pointing to get_my_dispatch for verification and by warning against guessing from read status or elapsed time.
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 when-to-use guidance (only after the user reports an outcome), explicit exclusions (do not infer from read status or timing), and an alternative path (check get_my_dispatch first when the outcome is unclear or timed out). It also warns against automatic resend because no persistent dedup key exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.