释放或移出联盟下属组织
detach_alliance_organization【需要登录】須联盟 manage。确认组织/联盟、释放自有或移出加盟及原因;关闭联盟共享和进驻访问,通知组织管理者。组织仍存在。官方分录只允许平台运营处理。
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| reason | No | ||
| allianceId | Yes | ||
| organizationId | Yes |
detach_alliance_organization【需要登录】須联盟 manage。确认组织/联盟、释放自有或移出加盟及原因;关闭联盟共享和进驻访问,通知组织管理者。组织仍存在。官方分录只允许平台运营处理。
| Name | Required | Description | Default |
|---|---|---|---|
| reason | No | ||
| allianceId | Yes | ||
| organizationId | Yes |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and discloses key effects: closes alliance sharing and access, notifies the organization manager, the organization itself remains, and official entries are restricted to platform ops. It stops short of covering reversibility or rate limits, but provides substantial 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 a single dense paragraph with no wasted words, front-loading login and permission requirements before action details. It is appropriately sized for the complexity despite the lack of sentence breaks.
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 3-parameter mutation tool with no annotations and no output schema, the description covers permissions, side effects, notification behavior, entity persistence, and a key restriction. It misses minor details like idempotency or failure modes, but gives enough 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 0%, so the description must compensate. It mentions organization/alliance and reason, mapping to all three parameters, but adds no format, optionality, or constraint details beyond their names—leaving the agent reliant on the bare 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 title and description clearly state the action: detaching an organization from an alliance, with two modes (release own or move out joined). The verb and resource are specific, though the description does not explicitly contrast with siblings like attach_alliance_organization or leave_organization_alliance.
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 states prerequisites (login required, alliance manage permission) and implies when to use it via the two detachment modes, but it never names or contrasts with alternative tools for related operations. Adequate but leaves the agent to infer sibling selection.
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.