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

The only annotation is idempotentHint:false, so the description carries the behavioral disclosure burden and handles it well. It states the exact response shape ('the compact build-configuration envelope of riddle_get', referencing riddle://reference/response-format) and the queue-modal behavior ('queued': true added when queue is set). It does not contradict the annotations, and it communicates what the agent can expect back from a create operation.

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 essential scope is front-loaded in the first sentence, followed by the reference link and the return-value statement. The text is efficient for the complexity involved, with no filler; the only minor structural weakness is that the return-value sentence and the external link share one sentence, making it slightly dense. Overall the wording is well-suited to a 6-parameter, nested-object builder tool.

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?

The tool is genuinely complex (nested build object, multiple builder variants, no output schema), and the description compensates by naming the response envelope and the queued variant, while pointing to external references for block types, preset, publish, and response format. Everything an agent needs to invoke it correctly in common cases is either in the description or the detailed inline schema docs. Only the less-common behaviors (full block-options matrix, exact preset key names) are delegated to links rather than stated inline.

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 effectively 100%, and the schema's parameter descriptions are unusually rich (omit semantics, templateId lineage, publish vs publish disambiguation, build strictness with unknown keys rejected). The tool description itself adds little parameter-specific meaning beyond naming the build configuration and the return envelope, so the baseline score of 3 applies. The schema is doing the heavy lifting, which is appropriate here.

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 verb and resource ('Builds a Story from a build configuration') and then defines the Story type precisely: 'the simplest block-based Riddle type - a sequence of content blocks (optionally with form blocks to collect lead data) plus an optional result page, with no questions, scoring or leaderboard'. This contrasts directly with sibling builders like riddle_builder_quiz and riddle_builder_leaderboard, and the blocks parameter reinforces it ('A Story has no question blocks of any kind - use riddle_builder_poll or riddle_builder_quiz if you need answers'). An agent can tell this builder apart from its siblings without opening their schemas.

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 fit criteria: use Story for linear content sequences with optional lead-capture blocks, and explicitly exclude scenarios needing questions, scoring, or leaderboard ('with no questions, scoring or leaderboard'). The blocks parameter adds an explicit when-not route ('use riddle_builder_poll or riddle_builder_quiz if you need answers'), which is good routing guidance. Coverage is not exhaustive across all sibling builders (minigame, personality, predictor, form are not individually contrasted), so it stops short of a complete decision tree.

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