land_stake_dec_region

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

With no annotations at all, the description fully carries the transparency burden and does so thoroughly. It discloses the successful response shape, zero-figure records, upstream empty-array behavior, the tool's refusal of incomplete requests, strict JSON-number wire-type handling, and the lack of silent conversion or cross-region aggregation.

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 dense and front-loaded, but it is a single rambling paragraph with redundancy. For example, the empty-array behavior for incomplete requests and the resulting refusal is stated twice, and the 'does not add/compare' limitation appears in slightly different forms. It would be more concise and readable with clear structure or bullets.

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 there is no output schema, no annotations, and many sibling tools, the description is unusually complete: it explains the response object, the fields, edge-case zero records, refusal semantics, wire-type strictness, and explicit non-aggregation behavior. An agent has enough context to call this tool correctly for its intended single-account/single-region use case.

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, and it does: it explicitly says both player and region_uid must be supplied, describes the upstream behavior when they are omitted, and notes that different region_uid values yield different figures. It adds meaning beyond the bare schema, though it does not explicitly spell out the expected format or semantic meaning of each parameter beyond their names and the 'one account/one region' framing.

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 specific verb and resource: 'Get the DEC staking figures the upstream reports for one account and one land region.' It further sets scope by naming the response fields and explicitly stating it does not aggregate across regions or compare with other routes, which differentiates it from sibling tools like land_stake_dec_overall.

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 clearly establishes when this tool applies: for a single account and single land region, reporting only the upstream record. It also gives when-not behavior ('does not add figures across regions and does not compare them with any other route's'), but it does not explicitly name an alternative tool or provide a direct decision rule such as 'use X instead for totals.'

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