unban_live_user【需登录·本场主办方】先get_organizer_live核对bans中的targetUserId和用户本人，确认仅解除本场禁言。允许本场发言，不恢复隐藏历史消息/置顶，也不解除其他场次或全站限制。重复保持未禁言；未知结果先核验，禁止自动重试。
| Name | Required | Description | Default |
|---|---|---|---|
| liveId | Yes | 要发言或管理的直播场次 id，从 get_activity 或 get_organizer_live 取得并给用户确认 | |
| activityRef | Yes | 活动 slug 或 id；管理动作仅影响这场活动下指定直播场次 | |
| targetUserId | Yes | 要禁言或解除禁言的用户 id；先核对本人昵称与 id，不能猜测身份 |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare mutation, idempotency, and destructiveness; the description adds login/organizer requirements, verification workflow, exact scope of the unban, idempotent repeat behavior, and a no-auto-retry policy for unknown outcomes.
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, leading with the access level and role before constraints. Every clause adds operational meaning: scope, verification, side effects, idempotency, and retry caution.
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 state-changing organizer action with no output schema, the description covers prerequisites, verification, scope limits, side effects, idempotency, and failure handling. An agent has enough information to call it correctly without additional inference.
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 all three parameters are documented in the schema. The description adds a useful verification detail for targetUserId against bans, but it does not add much beyond the schema for activityRef or liveId.
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 names a specific verb and resource: lifting the ban for this live session only. It distinguishes that from lifting bans in other sessions or site-wide restrictions, and its sibling ban_live_user makes the direction explicit.
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, organizer-only), the required verification step via get_organizer_live, and explicit when-not conditions: does not restore hidden history/pinned messages and does not affect other sessions or site-wide bans.
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.