ghl_project_create_space_folder

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

Annotations already state readOnlyHint=false, idempotentHint=false and destructiveHint=false, so the safety profile is covered. The description does add genuinely non-obvious behavior: a default list is seeded server-side but omitted from the response, and projects/workspace.write scope is required. However, most of the preamble (RBAC task filtering, lexorank position, rruleOptions, delete cascades) has nothing to do with creating a folder, so the added value is diluted.

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 tool-specific content — what it creates, the seeded default list, the endpoint, the scope — is compact and well-formed, but it is buried behind a multi-sentence API-wide preamble covering unrelated task/recurring-task/delete semantics. Roughly half the text does not earn its place for this tool.

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 3-param create call with full schema descriptions and annotations, the essentials (parent space required, auth scope, seeding side effect) are present. With no output schema, the description still does not say what the response contains beyond noting the default list is omitted, nor does it cover failure modes such as duplicate folder names.

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% and the nested body already documents name, color, userIds and isPrivate in detail. The description adds nothing parameter-level beyond confirming the endpoint path (spaceId) and the required scope; baseline 3 applies where the schema does all the work.

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 operative sentence is a specific verb+resource: "Creates a folder inside a space," with the hierarchical context (folders group lists) that separates it from ghl_project_create_space and ghl_project_create_space_list. It never names those siblings explicitly, so the differentiation is inferable rather than stated.

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?

Usage is implied by the hierarchy description (folders sit between spaces and lists) plus the OAuth scope requirement, but there is no explicit "use this when / not when" or pointer to the sibling create tools for spaces, lists, or folder-lists.

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