overleaf_create_folder

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

With no annotations provided, the description carries the behavioral disclosure burden. It discloses key limitations: single folder only, project-root scope, empty folder requirement, no nested path support, and current upload behavior. It does not cover duplicate-name handling or authentication, but the main operational constraints are explicit.

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 two short sentences with no filler. The operation is front-loaded, and the second sentence compactly conveys the important limitations without restating schema fields.

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 low-complexity create operation with fully described parameters and no output schema, the description provides enough operational context. Minor gaps such as duplicate-folder behavior and login requirements are present, but the root and empty-folder constraints already prevent common mistakes.

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?

Both parameters are already well described in the input schema, including the folder_name example. The description adds little parameter-specific detail beyond confirming the root-level scope, so the high schema-coverage baseline of 3 is appropriate.

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 states the exact operation and resource: create one folder in the project root. The constraints 'empty folder' and 'no nested paths' make its intended scope unambiguous and distinguish it from sibling file/project creation tools.

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 gives clear usage guidance: use only for an empty folder at the project root, and nested paths are not supported yet. It does not name explicit alternatives, but the scope constraints are sufficient to prevent most misuses.

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