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

Annotations already flag destructiveHint=true and openWorldHint=true, and the description adds substantive context on top: credit spend, mandatory owner price approval, active account rights for imports, and the image-specific fictional rights declaration requirement. The rights/compliance guardrails ('do not invent owner words', 'use Soclo's verified-person flow for real people') are behavioral facts an agent could not infer from annotations or schema.

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 pricing/approval prerequisite is front-loaded and every sentence carries actionable content, with no filler. It is dense and somewhat run-on for a single paragraph, packing pricing, origin, rights, and replay guidance together, so a reader must parse carefully to extract the ordered call sequence.

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 destructive, credit-spending tool with 10 undocumented parameters and no output schema, this covers what matters most: cost, approval, rights attestation, mode selection, and idempotent replay handling. Remaining gaps are what a successful creation returns (actor id?) and what failure modes exist (insufficient credits, offer mismatch), which would help but are secondary to the guidance given.

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?

With 0% schema description coverage across 10 parameters, the description carries heavy load and does so well: it explains origin's enum values, assetId/assetVersion as a current owned Brand Kit asset, expectedCredits/pricingVersion as coming from the offer, ownerApprovedPrice as an owner-facing gate, ownerRightsDeclaration's scope and the narrow case for omitting it, and clientRequestId as a stable replay key. The one gap is `spec` — its content and 400-character intent are never described, so an agent must guess what belongs there.

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?

States a specific verb and resource up front ('creates one reusable fictional character from name and spec') plus the cost consequence ('Spends credits'). It further disambiguates the two creation modes (soclo_generated vs owner_imported), which no sibling tool covers, so an agent can separate this from soclo_actors_list/select/remove without opening a 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?

Gives explicit when-to-use routing: read soclo_actors_list for the live offer, show it to the owner, then pass ownerApprovedPrice:true with the offer's exact expectedCredits and pricingVersion. It also names the condition that selects each origin mode and prescribes the recovery path (reconcile with soclo_actors_list rather than starting another purchase) when an outcome is uncertain.

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