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

With no annotations, the description carries the full burden and does well: it discloses the failure mode (illegal build returns 400 with an {errors} list to fix and resubmit) and the conditional dependency on rollId. It does not state what a successful call returns or whether creation is idempotent, which are the remaining gaps 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?

Three sentences, front-loaded with the core action and the required-field list. The middle sentence enumerates optional field names that the schema already lists, which is partly redundant, but it is doing work by grouping them as conditional rather than always-required.

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 20-parameter, nested-object tool with no annotations and no output schema, the description covers required vs. conditional fields, the rollId prerequisite, and the error path. It omits the success return shape (no output schema exists to compensate) and does not name ad_get_build_options directly.

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%, so the baseline is 3; the description earns above that by explaining conditional relevance — the optional pick fields are "used where the chosen race, class, and background call for them" — and by calling out the rollId condition tied to abilities.type. That is meaning the schema cannot express on its own.

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 ("Create a character") plus the input contract ("from a full build object"), which distinguishes it from the read-oriented siblings like ad_get_build_options and ad_get_rolls. An agent immediately knows this is the write path that consumes a build object rather than producing one.

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?

Prerequisites are stated concretely: rolled ability scores require a rollId from POST /api/ability-rolls, and race/class/background values must come "exactly as listed in the build options" (i.e. from ad_get_build_options). No explicit when-not guidance or named sibling tool reference, but the ordering of operations is clear.

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