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

readOnlyHint already declares the read-only profile, so the description adds real context: organizer/login requirement, liveId defaulting to the latest session, and the negative disclosure that stream keys and push/playback/replay URLs are deliberately not returned to the Agent. The remaining gap is that the overall return shape of a live session is never described, only the messageId nuance.

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?

Semicolon-separated and front-loaded with the actor and the core action, with no filler sentences. It is dense to the point of terseness—"recent/pinned含messageId用于管理" is hard to parse without knowing the return shape—but every clause carries routing or behavioral information.

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?

With no output schema, the description is expected to compensate, and it does so partially by noting the liveId default, the messageId present on recent/pinned sessions, and the fields that will never be returned. What is still missing is any indication of what a live-session record otherwise contains, though for a two-parameter read tool this is a minor gap.

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%, so baseline would be 3, but the description adds a genuine semantic the schema omits: liveId defaults to the latest session when omitted, which changes how an agent should call it. activityRef meaning is already fully documented in the schema, so no further credit is due.

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?

"读直播场次" names a specific verb and resource scoped to one activity, and the follow-up sentence contrasts it against ensure_activity_live, start_live_session, end_live_session and export_live_messages. An agent can tell this is the read/view tool rather than any of the live-lifecycle mutation siblings without opening another schema.

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?

Usage is explicitly routed: if no session exists use ensure_activity_live, to start use start_live_session, to end use end_live_session, and for the complete message history use export_live_messages. It also states what to do outside the Agent (OBS console, App viewer), covering the when-not case.

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