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

The description goes far beyond the annotations (destructiveHint=true, openWorldHint=true). It spells out the exact conditions under which a visitor's use may destroy the thing (must have both open_to_use and shared_use_may_destroy true), the permanent nature of ingredient withdrawal on successful crafting, and the output difference between crafted and kindless makes (consumed_ingredient_ids present or omitted). It also discloses that open_to_reach and open_to_convert reset to false on owner change, and wake_enabled defaults to true with room constraints. Every behavioral edge case the agent needs to know is explicitly stated, with no contradiction to the annotations.

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 description is long but every sentence carries essential operational information—no filler. It front-loads the core purpose in the first clause and then methodically addresses constraints, defaults, destructive interactions, output detail, special-room workflow, and fallback. The density is justified by the tool's complexity (10 params, many conditionals). Loses one point only because a slightly more compressed structure (e.g., grouping related toggles) would ease parsing, but it remains efficient.

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?

Given the tool's complexity—10 parameters, no output schema, many interaction rules—the description covers all the ground an agent needs: prerequisites, quota limits, failure modes, naming constraints, response content (reading-cost meter, consumed_ingredient_ids), default behaviors, destructive gating, owner-change resets, the Gazette special workflow, and even a catalog and fallback reference. There is no obvious missing piece that would prevent a correct invocation. The absence of an output schema is mitigated by describing the response shape qualitatively.

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?

Although the schema already covers 80% of parameter descriptions, the description adds critical cross-parameter meaning. It explains that place_id must be active and owned/open, name must be 1-120 safe characters, ingredient_ids must be empty unless kind_id is supplied, and all the boolean defaults are clarified in context (e.g., shared_use_may_destroy matters only when open_to_use is true). It also explains that kind_id pins the current revision at birth, which the schema does not state. The description compensates well for the 20% gap and enriches the existing schema 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 description opens with a precise verb-resource pairing ('Make a text thing while standing in place_id') and immediately scopes it with the active/ownership/open requirement. It clearly distinguishes this from sibling tools like thing_edit (which edits rather than creates) and invent_kind (which creates kinds rather than things), and it names the specific action of creating a text thing in a location. The later reference to the Gazette workflow adds situational purpose. The resource and action are unambiguous even before considering the sibling list.

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 explicit prerequisites: place_id must be active and either owned or open to things, and the 20-free-per-UTC-day quota. It states when the tool refuses to work (retired place before quota/ingredients change) and directs the agent to restore first or choose another place. It also provides a clear precondition for the Gazette room: call browse with view=gazette and no issue_number first, then follow the live submission_room and withdrawal_contract. These are concrete, actionable 'when to use' and 'when not to use' instructions, far beyond vague hints.

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