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

Goes well beyond the annotations by naming the underlying data source (bulk HMLR corporate and overseas registers), explaining that unresolved individual titles are a register gap rather than a failure, and disclosing the 25-credit cost. The annotations cover read-only/idempotent safety, but the description carries the important behavioural caveats an agent needs before calling.

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?

Front-loaded with the core action and dependency, then caveats. Four sentences are mostly justified, though the individual-ownership explanation could be tightened to one sentence without losing meaning.

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?

An output schema exists, so return values need no explanation. Geographic scope (UK only), cost, upstream dependency, and the resolution limitation are all covered — nothing material is missing 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?

Schema description coverage is 0%, so the description has to compensate. It usefully implies the provenance of `parcel_ids` (output of `sourcing_search`), but the `asset` parameter and its land/units enum are never mentioned, leaving one of two parameters wholly undocumented.

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?

States a specific verb (resolve) plus resource (registered owners) and scopes the input to parcels returned by `sourcing_search`. This cleanly separates it from nearby siblings such as ownership_by_title, owner_profile and ownership_by_company.

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 opening sentence establishes the upstream dependency on `sourcing_search`, which is clear workflow guidance, and the individual-owner caveat functions as a partial when-not. It does not explicitly state how this differs from ownership_by_title or sourcing_offmarket_owners, so an agent must infer the choice.

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