Move Request

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

With no annotations, the description carries the full burden of behavioral disclosure. It goes above and beyond by explaining that the move is byte-verbatim, that seq may tie and are resolved by filename, and that the new path is returned. This level of detail is outstanding and far exceeds the minimum.

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: three sentences that carry substantial information without fluff. It leads with the primary purpose, then covers the key nuance (copy mode), and concludes with behavior and an alternative. Every sentence adds value, and the structure is efficient.

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 complexity, the description is remarkably complete. It explains the return value (new path), an edge case (seq ties and resolution), and the difference between move and copy. There is no output schema, so the description appropriately covers the response. It also provides guidance on selecting destinations via parameters.

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 covers 100% of parameters with descriptions, so the baseline is 3. The description reinforces the copy semantics and notes that the file keeps its name, but these are more behavioral than parameter-specific. It does not add significant new meaning beyond the schema, but it does not need to.

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 purpose: 'Relocate a request file to another folder, or to another collection entirely.' It specifies the verb (relocate), the resource (request file), and the two primary operation modes (move and copy). It also distinguishes from sibling tools like modify_request by noting that renaming is handled there.

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 description provides explicit guidance on when to use copy:true versus moving, and explicitly points to modify_request for renaming, which differentiates it from that sibling. It does not explicitly list all alternatives or exclusion criteria, but the context is clear enough for typical usage.

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