land_liquidity_resources

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

With no annotations, the description carries the behavioral disclosure burden Tags It does well by revealing that invalid inputs return genuinely empty arrays, that token matching is case-sensitive, and that the observed resource set is not exhaustive. This gives the agent important expectations about failure and edge-case behavior beyond what a bare list description would provide.

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 main purpose and then adds useful behavioral and field-level details. Each sentence contributes distinct information: the endpoint, validation tests, case-sensitivity, resource set, and return fields. It is slightly long due to the garbage-input validation notes, but those notes are valuable for predicting response behavior in edge cases.

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 simple two-parameter schema and absence of an output schema, the description covers the key aspects an agent needs: what the tool lists, how invalid inputs are handled, the case-sensitivity of token, the set of resource symbols, and the exact fields returned unchanged. It does not mention authentication or error statuses, but for selecting and invoking the tool, the description is substantially complete.

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 0%, so the description must compensate for parameter meaning. It names the player and token parameters in the endpoint and adds a key semantic: token matching is case-sensitive. However, it does not explain what a valid token represents, whether player is an account name or ID, or how formatting affects the request. It is minimally helpful but not fully compensating for the lack of schema documentation.

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?

Description states a clear verb and resource: 'List per-region resource rows' from a specific endpoint path. It specifies the player/token scope and the exact resource symbols, making the tool's purpose unambiguous. It doesn't explicitly differentiate from sibling land liquidity tools, but the mention of resource rows and per-region output provides enough distinction.

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?

There is no guidance on when to use this tool versus its siblings like land_liquidity_pools, land_volume, or land_resources_owned. The description validates behavior with garbage inputs but does not state the intended use case, prerequisites, or alternatives. An agent must infer when this tool is the right choice based on the resource-symbol scope.

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