land_projects_count

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals important non-obvious traits: the call returns only a count, the count's equivalence to the history tool is unverified, reference resolution may add an extra GET with a hard two-request limit, and populated resolved results contain all three plot identities and resolution freshness. This goes well beyond a basic statement of function.

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 but efficient: purpose is front-loaded, followed by essential caveatsressing, input constraints, and a note on request behavior. Every sentence contributes distinct information without redundancy. The structure flows logically from what to how, making it easy for an agent to parse and apply.

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 modest complexity (2 optional parameters, no output schema, no annotations) and the presence of many sibling land tools, the description covers the key operational details: what is returned, how to supply identifiers, and the potential extra request. It could be slightly more complete by explicitly naming the related history tool for routing, but the current text is sufficient for correct invocation.

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 schema has 0% description coverage)Skip, so the description must compensate. It explains that exactly one of plot_id or deed_uid must be supplied, and clarifies accepted forms: plot_id can be numeric or display label, and the original UID spelling is accepted. This adds meaningful semantics beyond the raw schema, though it does not detail every possible nuance of the resolved output.

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 count of land project records the upstream reports for one deed uid.' It clearly distinguishes itself from record-returning tools by stating 'returns the upstream's count only, not the records,' and references the history tool as a point of comparison. This is a precise statement of what the tool does and how it differs from related 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?

The description provides clear usage context: it is for obtaining a count for one deed uid, and it explicitly notes this is a single call rather than a records retrieval. It does not definitively name the alternative tool to use when records are needed, though 'the history tool' is implied. The caution about unverified coverage overlap with the history tool gives useful selection guidance, but a direct when-to-use/when-not-to-use statement is missing.

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