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

Only destructiveHint=true is annotated, so the description carries most of the burden. It does add useful signal beyond the annotations: the 'WRITE' marker and the concrete endpoint POST /api/v1/items. However it omits auth requirements, what happens on duplicate names, and whether the create is reversible, which matters for a mutation tool.

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?

A single dense sentence that front-loads the verb and the two type values, followed by the write/endpoint tag. No filler, though the trailing field enumeration is slightly redundant with the schema.

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 15-parameter nested mutation with no output schema, the description covers the main shape but leaves gaps: no return-value expectations, no error behavior, and no note that the measured_quantity unit should come from sortly_list_units. Adequate but not complete.

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% with descriptions and enums for all 15 parameters, so the baseline is 3. The description nods at parent_id nesting and the label/barcode fields but adds no syntax or format detail beyond what the schema already documents.

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?

Specific verb (create) plus both resource types it produces (item/folder), with the parent_id placement scope named. It is easy to distinguish from siblings like sortly_create_alert, sortly_create_job, and sortly_update_item without opening the schema.

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?

Creation intent is implied by the verb, and the description notes parent_id controls nesting, but it never states when to choose this over sortly_update_item or sortly_move_item, nor any prerequisites such as needing valid custom_attribute_ids or photo_ids first.

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