attach_activity_to_goal【需要登录】【何时用】把我举办的一场活动挂进合作目标，让它成为这个目标的一个模块——挂上之后目标的合作人自动成为这场活动的管理员。
【组合链】list_my_activities 或失败返回体里的 attachable 清单拿到活动 → 本工具 → get_collaboration_goal(include:["activities"]) 核对。摘下来用 detach_activity_from_goal。
【口径/坑】① 两侧都要有权：目标这边至少是合作人，活动那边必须是我举办的。② 组织名下的活动挂不进个人目标（409）。③ 会让目标里的其他合作人当场获得这场活动的管理权，挂之前跟用户说清是哪一场。
| Name | Required | Description | Default |
|---|---|---|---|
| goalId | Yes | ||
| 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?
Beyond what annotations convey, the description discloses a significant side effect: goal collaborators automatically become administrators of the attached activity. It also exposes the 409 failure case, login requirement, and the 'must be my activity' ownership constraint, giving the agent important behavioral context.
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 well-structured with clear sections: when to use, combo chain, and pitfalls. Every sentence adds actionable information, and the most important context (login, usage, side effects) is front-loaded with no 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?
Given there is no output schema, the description provides a verification workflow via get_collaboration_goal(include:["activities"]). It covers prerequisites, authorization, error behavior, and the side effect on administrators, making it sufficient for an agent to invoke 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 coverage is only 50%, but the description compensates by clarifying activityRef as a slug or id obtainable from list_my_activities or get_collaboration_goal(include:["activities"]). It also clarifies the goalId context as a collaboration goal requiring collaborator permission, although goalId itself is not explicitly labeled in a dedicated parameter note.
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: attach an activity that "我举办的" to a collaboration goal, making it a module of that goal. It also distinguishes itself from the inverse sibling detach_activity_from_goal, so an agent can tell them apart.
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 explicitly marks when to use the tool with 【何时用】, provides a complete combo chain (list_my_activities → attach → get_collaboration_goal), and names detach_activity_from_goal as the inverse operation. It also documents required permissions and exclusion cases like org-owned activities failing against personal goals.
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.