generate_requirements

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

With no annotations, the description carries the full burden and does disclose real behavior: the server (not the agent) generates and persists Q1..Qn, sessions survive interruption and day boundaries, and generation, validation, state transitions and document rendering are a closed process the caller cannot intervene in. It omits permissions, error behavior, and limits, which keeps it below 5.

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?

Four short sentences with no filler, front-loaded with the tool's identity before the input modes. The semicolon-heavy packing is dense but every clause carries information, so nothing is wasted.

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?

An output schema exists, so return values need not be described, and the description fully covers the session lifecycle that is this tool's core complexity. What is missing is any account of the profile and output_dir parameters, which an agent must still set correctly.

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 description coverage is 0%, so the description must compensate for all five parameters, and it only covers three: q0, answer, and session_id, including how they combine across turns. The enum parameter profile and output_dir are never explained anywhere, leaving a real gap.

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 resource and role: the single entry point (唯一入口) for requirement documents, with the server generating and persisting Q1..Qn. This is far more than a restatement of the name and implies a pipeline-entry role, though it never explicitly contrasts itself with generate_architecture or generate_skill.

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 lays out three concrete invocation modes: new work supplies q0, continuation supplies session_id plus answer, and session_id alone resumes or queries an interrupted session. That is clear when-to-use guidance, but it names no alternatives or conditions under which a sibling tool should be chosen instead.

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