Add a character who talks

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

Annotations only carry idempotent/destructive hints; the description adds the transaction/atomicity guarantee ('if any part fails, nothing is written'), the reply shape (map rendered around the new NPC), the two consequential defaults (priorityType 1, replace true), and the note that script/raw escape hatches are echoed back in the reply. This is substantial disclosure beyond the annotations and is consistent with idempotentHint=true and destructiveHint=true.

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?

Front-loaded with the core behavior, then defaults, then the escape-hatch caveat. Sentences are dense but each carries distinct information (atomicity, defaults, alternatives). It is on the long side for a tool description, but little is filler.

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 complex, deeply nested tool with no output schema, it covers the write semantics, the reply's rendered map, defaults, and the escape-hatch limitation. It omits error/validation detail beyond the characterName failure (which the schema already states) but is otherwise complete enough to invoke confidently.

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 22 params at 64% coverage, the description adds real meaning the schema does not: the rationale and default for priorityType 1 and replace true, and that `patrol` writes the page's movement route run by moveType 1. It leaves other params (e.g. moveSpeed, moveFrequency, walkAnime) to the schema, so it does not fully compensate for the coverage gap.

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?

Opens with a specific verb+resource ('Place a non-player character in one call') and enumerates exactly what it creates: graphic, movement, dialogue, and an optional follow page. It is clearly separable from sibling place_event (raw event) and make_choice_scene (branching scenes).

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 a clear routing rule for adjacent needs — 'For more than talk — choices, gates, battles — use `script` here or make_choice_scene' — and explains the replace default as the build-script idiom. It does not exhaustively state when NOT to use it (e.g. vs place_event), so it stops short of a 5.

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