Skip to main content
Glama

独行录 / opcmenu

主办方:解除本场禁言

unban_live_user
Idempotent

登录/本场主办方;先get_organizer_live核对bans中的targetUserId和用户本人,确认仅解除本场禁言。允许本场发言,不恢复隐藏历史消息/置顶,也不解除其他场次或全站限制。重复保持未禁言;未知结果先核验,禁止自动重试。

Input Schema

NameRequiredDescriptionDefault
liveIdYes要发言或管理的直播场次 id,从 get_activity 或 get_organizer_live 取得并给用户确认
activityRefYes活动 slug 或 id;管理动作仅影响这场活动下指定直播场次
targetUserIdYes要禁言或解除禁言的用户 id;先核对本人昵称与 id,不能猜测身份

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare idempotentHint=true, so the description's 重复保持未禁言 largely restates structured data. It does add non-annotated behavior: unbanning restores speaking only, not hidden history messages or pinned items, and does not cascade to other sessions or site-wide bans. Useful, but the core safety signal is already in the annotation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four compact clauses, front-loaded with the permission/scope constraint before the side-effect exclusions and the retry rule. Dense but every clause carries information; the semicolon-delimited style is slightly harder to scan than separate sentences.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no output schema and full schema coverage, the description supplies everything else an agent needs: authorization requirement, prerequisite verification call, precise blast radius, idempotent behavior, and the no-retry policy on unknown results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all three parameters (liveId, activityRef, targetUserId) are already documented with bounds and sourcing instructions. The description adds only procedural color (check targetUserId in bans via get_organizer_live), which is guidance rather than new parameter meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource+scope: 解除本场禁言 (lift this session's mute), and explicitly bounds it against what it is not (other sessions, site-wide restrictions). An agent can distinguish it from sibling ban_live_user or any account-level unblock without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit precondition (登录/本场主办方), a mandatory pre-check via get_organizer_live against the bans list, and a routing rule for ambiguous outcomes: verify first, do not auto-retry. This is exactly the when/how guidance an agent needs before a destructive-adjacent mutation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources