land_resources_balances_history_count

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

With no annotations, the description carries the full burden and does so exceptionally well. It discloses the response shape, unchanged numeric count semantics, error behaviors for malformed dates and excessive list limits, zero-count cases, and explicitly refuses to overclaim the count-list relationship.

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 front-loaded first sentence is strong and specific, but the middle section becomes verbose with detailed list-probe results such as limit=3&offset=1/2/3 and HTTP 400 cases. Much of this detail is about a different route/parameter set and could be summarized in one or two sentences without losing value.

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 lack of annotations and output schema, the description provides a remarkably complete picture: route semantics, response shape, error conditions, edge-case counts, and explicit non-assertions. The main remaining gap is the absence of a concrete date format or date-parameter naming, which leaves a small but real invocation ambiguity.

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 missing parameter documentation. It adds meaningful context by clarifying that player is a path segment and that dates are optional, but it never names startDate/endDate directly, provides no date format, and gives only anecdotal behavior about far-past and malformed dates.

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 states a specific verb/resource ('Get the resource-balance history count'), a specific upstream route, and a clear scope of one account with optional dates. It also distinguishes itself from the list counterpart by emphasizing that it returns only the count.

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 tool is clearly positioned as count-only, and the description compares it with paired list probes, giving useful context. However, it never explicitly names the sibling list tool or states a decision rule for when to choose count versus list, so the usage guidance remains implicit rather than explicit.

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