detach_activity_from_goal【需要登录】【何时用】这场活动不再属于这个目标了。活动本身一动不动（它本来就能独立存在），只是解开归属。
【组合链】get_collaboration_goal(include:["activities"]) 拿 slug → 本工具。
【口径/坑】① 摘下后目标里其他合作人当场失去这场活动的管理权：摘之前必须把活动名念给用户确认。② 只有活动的举办人能摘。③ 只收 activityRef，不收 goalId——一场活动至多挂在一个目标下。
| Name | Required | Description | Default |
|---|---|---|---|
| activityRef | Yes | 活动 slug 或 id（get_collaboration_goal(include:["activities"]) 里两个都有） |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint=true, but the description adds critical behavioral context: other collaborators immediately lose management rights over the activity after detachment, and the agent must confirm the activity name with the user before proceeding. It also discloses the constraint that an activity can be attached to at most one goal, which explains why goalId is not needed. This goes well beyond the annotations.
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 compact and well-structured with clear sections: when to use, chained workflow, and pitfalls. Every sentence carries meaningful information, and the most important caveat (confirm with user) is front-loaded in the pitfalls section.
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 mutation tool with no output schema, the description covers the essential context: prerequisites, side effects, permission requirements, and parameter source. The agent has everything needed to invoke it correctly and safely.
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% and the schema already describes activityRef as 'activity slug or id'. The description adds the source of that value (from get_collaboration_goal(include:["activities"])), which is useful but not extensive. Since the schema already covers the parameter well, a 4 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 states a specific verb ('detach') and resource ('activity from goal'), and clarifies the semantics: the activity itself remains unchanged, only the membership is removed. It also distinguishes itself from the sibling attach_activity_to_goal by describing the inverse operation.
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 explicitly says when to use it ('this activity no longer belongs to this goal'), provides a chained workflow (get_collaboration_goal → this tool), and gives clear exclusions: only the activity host can detach, and only activityRef is accepted. This is strong guidance for an agent.
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.