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

Beyond the annotations, the description discloses meaningful behavior: owner_artist_id falls back to the workspace's only artist (else its first) and cast is shared only when shared=true, ai_made=false routes through a face check, and 'The uploads are deleted' is a real side-effect warning. The replacement of an existing character ('replace true takes the place of theirs') and the upload deletion sit in mild tension with destructiveHint=false, but the primary operation is additive and no user artist or video is destroyed, so this is not a direct contradiction.

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?

It is short with no filler sentences, and the core action is front-loaded, but the branching is packed into a single run-on with nested parentheses and semicolons that is difficult to scan. The information earns its place; the layout does not.

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 8-parameter mutation with no output schema, the description covers mode selection, defaults, sharing scope, the face-check gate, and the upload-deletion side effect. It does not say what state request_id must be in (a pending charreq) or what the agent gets back, but return values are less critical here and the operational picture is essentially 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 already 100%, so the baseline is 3, but the description adds semantics the schema does not: artist_id vs name/handle are mutually exclusive modes, owner_artist_id only applies to cast, shared and ai_made default behavior, and the fact that ai_made must be solicited from the user rather than inferred. That is genuine meaning added on top of the field-level descriptions.

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 verb and resource are stated concretely ('Keeps the sheet in the kit') and the description distinguishes two creation modes, one tied to artist_id and one tied to name/handle as cast. It does not name any sibling (e.g. discard_character_request, start_character, draw_character_sheet) to tell an agent when this tool is the wrong choice, and the telegraphic phrasing makes the purpose harder to extract than it should be.

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 real branch-level guidance: use artist_id to keep as that artist, or name/handle to add cast in owner_artist_id's kit, plus an explicit instruction to ask the user about ai_made and never guess. It gives no routing against alternatives such as discard_character_request or start_character, so the when-not-to-use side is left to inference.

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