create_folder

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

Annotations already indicate readOnlyHint=false and destructiveHint=false, so the mutation is implied. The description adds value by specifying that it returns the created folder 'same shape as get_folder,' which is beyond the annotations. It also clarifies the nesting behavior via parent_folder_id. This provides useful behavioral context beyond what annotations declare.

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 compact yet structured with clear section markers (USE WHEN, USE INSTEAD, FIRST, EXAMPLE, RETURNS). Each sentence serves a purpose: purpose, usage context, alternatives, prerequisite, example, and return shape. No redundancy or fluff, and the most critical information (purpose) is front-loaded.

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?

For a create operation with 4 parameters and no output schema, the description covers all necessary aspects: what it does, when to use it, what to use instead, how to obtain a required parameter, an example payload, and the return format. There are no missing pieces an agent would need to correctly invoke the tool.

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 all parameters have descriptions. The description adds an example with a sample value, emphasizes required fields, and clarifies parent_folder_id for nesting. This goes beyond the schema's dry descriptions, providing concrete usage context. The example directly maps to the parameter structure.

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 explicitly states 'Create a folder in a workspace, optionally nested under another.' This is a specific verb and resource, and the mention of optional nesting distinguishes it from sibling tools like move_folder and delete_folder. It clearly defines what the tool does without ambiguity.

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 usage guidance: 'USE WHEN: Organising memos' and 'USE INSTEAD: move_folder to relocate a folder that already exists.' It also instructs to call get_workspaces_basic_info first to obtain workspace_id. This clearly tells the agent when to use this tool and when to use an alternative, leaving no inference needed.

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