whistle_session_get

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

With no annotations provided, the description carries the burden of behavioral disclosure. It implies a read-only operation via the verb '获取' (get) and details the returned content, but it does not explicitly state side-effect-free behavior, error conditions, or authorization requirements. The description adds useful context about auto-parsing but leaves some behavioral aspects unspecified.

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 sentence that front-loads the core purpose. It lists many included fields and behaviors, but each element adds value and there is no fluff or repetition. Slightly over-stuffed but still concise for the amount of information conveyed.

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?

Given the tool's simplicity (one parameter, no output schema), the description provides a solid outline of what the tool returns and its parsing behavior. It does not describe the output format or error handling, but for a simple retrieval tool with clear schema coverage, this is reasonably complete.

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 schema already provides a clear description for the single 'id' parameter, and the description adds valuable provenance by noting the id comes from whistle_sessions_list. This covers the parameter semantics well beyond just the schema's basic type definition.

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 gets full details of a single request, enumerating specific content categories (headers, body, response, timing, rules) and auto-parsing behavior. This distinct verb+resource combination differentiates it from sibling tools like whistle_sessions_list, which presumably provides a list of sessions.

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 parameter description explicitly instructs that the session id comes from whistle_sessions_list, implying a clear workflow (first list, then get details). While it doesn't explicitly mention when not to use this tool or alternative tools, the workflow guidance is clear and actionable.

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