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

Beyond the annotations (readOnly=false, destructive=false, openWorld=true), it discloses that omitted permission switches default closed to notes/things/building, that building in owned or open land is free, that frontier claims carry a $1 fee and create a continent, and that credit-funded claims require a fresh request id. These are non-obvious side effects, defaults, and cost behaviors an agent could not infer from structured fields.

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?

Core purpose is front-loaded, but the body crams permission defaults, fee rules, a Gazette-room procedure, and a credit-claim workflow into long run-on sentences with no separation. Much of the Gazette and credit procedure belongs in the referenced tools' docs rather than this definition.

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, fee-bearing mutation with no output schema and sparse schema docs, the description covers permissions, cost, idempotency, and prerequisite calls well. It omits what a successful call returns or what the created place looks like, which is the main remaining gap.

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 only 29% (parent_id and city_credit_request_id), so the description must compensate and largely does: it explains name/description length limits, the default-closed meaning of the open_to_* switches, and the null/world-id semantics of parent_id. It does not fully clarify the credit_request_id retry/pattern semantics beyond 'take the fresh suggested_request_id'.

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 opening clause states a concrete verb and resource ('Found a place with a name of 1 to 120 safe characters and an optional description'), so the agent knows this creates a place with bounded fields. It stops short of explicitly contrasting with sibling mutators like place_edit, and the term 'Found' plus heavy domain jargon (safe characters, frontier) forces some inference.

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 names specific alternative calls with their triggering conditions ('Before any work there, call browse with view=gazette', 'Before confirming a credit-funded frontier claim, call credit_preflight', 'Lost? Call front_door'). It does not explicitly state when to pick found over siblings such as claim_world or place_edit, so it is strong but not fully routing.

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