land_liquidity_region

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

No annotations are provided, so the description carries the burden; it discloses that an unknown or case-mismatched player returns a genuine empty array and that the tool returns upstream rows unchanged (no transformation). It also describes what fields are gained (plots_owned, human-readable region name) and lost, giving the agent an accurate behavioral model without needing the output schema.

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?

About 100 words pack the purpose, route relationship, field differences, usage guidance, and edge-case behavior with no redundancy. Front-loads the main action ('Get one row per region') before extending details.

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 one-parameter tool with no output schema, the description covers the essential call semantics, differentiation from sibling, return transparency, and invalid-input behavior. Nothing crucial seems missing for an agent to invoke it correctly.

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 0% for a single param; the description compensates by identifying player as the path parameter in the endpoint and noting case-mismatched values yield an empty array, implying case sensitivity. It stops short of defining whether player is a username or account ID or any normalization rules, so there's slight room for improvement.

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 ('Get'), resource ('one row per region'), and exact endpoint (GET /land/liquidity/region/{player}), and explicitly contrasts with the per-token route by listing gained/lost fields. This clearly differentiates it from sibling land_liquidity_resources and other liquidity tools.

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?

Provides explicit guidance: use this as a one-call regional summary that removes fan-out, and choose the per-token route when record metadata (id, created_date, last_updated_date) are needed. This leaves no ambiguity about when to select this tool versus the named alternative.

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