land_tracts_counts

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

With no annotations present, the description carries the full burden of behavioral disclosure. It transparently states that the unscoped call returns an empty list, that a named-player response returned 36 rows, that all six fields were present and non-null, and it explicitly declines to make unmeasured absence claims. This is honest and useful, though it omits auth/rate-limit details that might matter in practice.

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 front-loaded with purpose, then presents behavioral details and a cautionary scope note. Each sentence earns its place: endpoint identification, empty-case behavior, observed response shape, and uncertainty caveat. It is slightly longer than minimal, but the length is justified given the absence of annotations and output schema.

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?

Without an output schema, the description usefully explains the return shape, field names, non-null behavior, and both observed cases. It is reasonably complete for a read-only list endpoint. The main gaps are explicit parameter usage and exclusion criteria, which were covered in other dimensions, so the overall contextual picture is strong but not flawless.

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 explain the player parameter, but it only refers indirectly to a 'captured named-player response' and 'the account holds a deed.' It never states that player is optional, what format it should take, or how it scopes results. This is insufficient compensation for an undocumented parameter.

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: 'List the tract count rows returned by GET /land/tracts/counts.' It clearly identifies the endpoint and the data shape, and the phrase 'tract count rows' distinguishes it from the broader land count endpoints. However, it does not explicitly contrast it with siblings like land_regions_counts or land_deeds_owned, so the differentiation is implicit rather than stated.

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 alternatives, no conditions for choosing it over land_regions_counts or land_deeds_owned, and no explanation of when to provide the player parameter. The contrast between 'unscoped call' and 'captured named-player response' hints at usage, but the agent is left to infer when and how to invoke the tool.

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