land_tracts_counts

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

With no annotations, the description carries the full burden and does substantially more than a boilerplate line: it states the empty unscoped result, the observed row count and composition, that all fields were non-null, and explicitly limits claims where behavior is unmeasured. It could add auth/pagination/rate-limit details, but for a simple list endpoint this is strong behavioral disclosure.

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 longer than average, but each sentence adds information: endpoint, empty-case behavior, observed row shape, non-null guarantee, and scope limits. The uncertainty caveat at the end is intentionally transparent rather than filler, so the structure earns the length.

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 no output schema and no annotations, the description compensates with row fields, empty-case behavior, and row semantics. It is still missing explicit parameter documentation and usage direction, but for a one-optional-parameter list endpoint it leaves an agent reasonably equipped to understand what a successful response looks like.

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?

The input schema provides only a bare optional 'player' string at 0% description coverage, so the description needed to compensate. It adds some meaning by contrasting unscoped vs named-player responses, implying 'player' is a named account that scopes the result, but it never explicitly defines the parameter, its format, or its effect beyond that observed contrast.

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 names a concrete verb and resource: listing the rows returned by GET /land/tracts/counts. It is specific enough to be distinguished from the sibling land_regions_counts and other land endpoints by its endpoint and row contents, though it doesn't explicitly contrast those siblings.

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?

No explicit when-to-use guidance or comparison with alternatives is provided. The only usable hint is the contrast between the 'unscoped call' returning empty and a 'captured named-player response' returning 36 rows, which implies the player parameter matters but never states when to call it or what criteria select this tool over land_regions_counts or land_deeds_owned.

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