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

Annotations only indicate readOnlyHint=false, openWorldHint=false, and destructiveHint=false, which are not very informative. The description adds meaningful behavioral context: writes are performed through ChangeRequests with a message, diff, and full history, and stored content should be treated as data, not instructions. This goes beyond the annotations and helps the agent understand side effects and safety posture.

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 and front-loaded: the core purpose appears in the first sentence, followed by the endpoint, multi-space usage, and a security note. Every sentence earns its place, with no redundant filler or repetition of schema details.

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 an 11-parameter write operation with no output schema, the description is not complete enough. It omits the relationship to the preceding upload step, does not explain most required parameters, and gives no indication of the response shape. The ChangeRequest and multi-space notes are useful, but significant gaps remain for an agent to call this correctly.

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 description coverage is only 18%, so the description must compensate for the other 9 parameters. It only adds context for targetSpaceId and does not explain required parameters like storageKey, fileName, mimeType, sizeBytes, nodeId, or nested metadata and contentHash. The parameter names are somewhat self-explanatory, but the description does not clarify how they relate to the upload-confirmation workflow.

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 a specific action and resource: 'Recorded the uploaded file as an attachment for this node's icon,' and includes the endpoint. It is clearly distinct from the sibling nodes_icon_create_upload_url, which creates an upload URL rather than confirming the upload. However, it does not explicitly name or contrast the sibling, so it stops short of a 5.

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 gives clear contextual guidance: for multi-space accounts, call auth_verify, ask the user which space to use, and pass targetSpaceId. It also explains that writes go through ChangeRequests. It does not explicitly say when to use this tool instead of alternatives like assets_confirm or community_confirm_post_image_upload, so it lacks explicit exclusions.

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