get_speech

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

With no annotations provided, the description carries the full burden of disclosing behavior. It does reveal that the tool is a polling mechanism and lists event types, but it omits critical behavioral traits such as whether timeout blocks, how since_id acts as a cursor, whether events are consumed or cumulative, or any side effects. The agent gets only a vague sense of how the tool actually behaves.

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 concise and front-loaded with the action (轮询拉取), followed by event examples and a use-case note. It avoids verbosity and structures information in two short sentences. While it is underspecified in other dimensions, as a standalone piece of text it is efficiently written without wasted words.

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?

Even though an output schema exists, the tool is a polling endpoint with two undeclared parameters and no guidance on alternative tools. The description provides only a minimal understanding of the polling loop and does not explain how timeout and since_id fit into that loop, making it insufficient for an agent to use the tool correctly in context. The overall picture is incomplete.

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?

The input schema has 0% description coverage and the tool description does not mention the parameters timeout or since_id at all. As a result, the agent has no semantic information about what these parameters do, how they influence polling behavior, or what values are appropriate. There is no compensation for the schema's lack of descriptions.

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 clearly states the tool's verb and resource: '轮询拉取实时语音事件' (poll to fetch real-time speech events), and lists specific event types (speech_start/final/state). This distinguishes it from sibling tools like speak and listen, which focus on producing or managing audio rather than consuming event streams.

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?

The phrase '宿主可据此感知用户说话' (host can use this to perceive user speech) implies the tool is for polling speech events during a session. However, there is no explicit guidance on when to prefer this tool over alternatives such as listen or listen_start, and no mention of exclusions or conditions. The usage context is implied rather than clearly defined.

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