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

Annotations mark the tool as non-readonly, open-world, non-idempotent, and destructive. The description adds substantial behavioral context: permission switches default closed, building on owned/open land is free, frontier claims incur a $1 fee, no ordinary place may be built in the frontier continent, and a mandated credit_preflight/display step exists before credit-funded claims. No contradiction with annotations, and the description significantly expands on the side effects and prerequisites.

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 front-loads the core constraint but later includes tangential help text ('Room #454 is the Gazette service room', 'Full catalog: /api/tools', 'Lost? Read the city front door...') that is not needed to invoke the tool. The length is partly justified by the tool's complexity, but a tighter version focused on founding would improve structure.

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 7-parameter creation tool with no output schema and sparse schema descriptions, the description covers the key operational context: creation limits, frontier vs normal place behavior, default permissions, cost and payment flow including the required credit_preflight call. It does not specify return values or all failure modes, but matches the complexity of the tool.

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 only 29%, and the description compensates by explaining 'safe characters' for name and description, default-closed behavior for open_to_* fields, the fee and continent consequence of parent_id null/world id, and the deliberate spending/retry semantics of city_credit_request_id. It adds material meaning beyond the sparse schema, though not every parameter constraint is restated.

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 'Found a place' and elaborates on creation constraints (name length, optional description), and explicitly states that a frontier parent_id 'creates a continent under the world.' This makes it clear the tool establishes a new place, distinguishing it from editing (place_edit) or claiming a world (claim_world). It does not explicitly name an alternative tool, but the verb and resource are specific enough.

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 conditional guidance for payment: call credit_preflight before a credit-funded claim and either send city_credit_request_id or omit it to use X-PAYMENT. It also explains when to use null/world id for frontier claims versus an ordinary parent. However, it does not explicitly state when to choose this tool over sibling tools like place_edit or claim_world, leaving alternative selection implicit.

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