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

Adds substantial context beyond the annotations: UK-only coverage, a 25-credit cost, and a crucial interpretation caveat that name-matched results are a candidate set and the response declares which kind you got. It also explains the n_distinct_titles vs n_rows discrepancy, which prevents a serious misreading of the returned counts.

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 what the tool returns, then the input-mode choice, then interpretation warnings and cost. Every sentence carries information an agent needs; nothing is redundant with the annotations.

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-value documentation is optional, and the description still pre-empts the main misreading of the counts. Cost, geography and match semantics are all covered; the only gap is unmentioned pagination/limit behavior on a tool defaulting to 200 rows.

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?

With 0% schema description coverage the description must carry parameter meaning, and it does for the two decision-critical params: exact company_number vs fuzzy name, including the deduplication caveat. The limit parameter and its default of 200 are never mentioned, leaving one of three parameters 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 resource (a proprietor's Land Registry profile) and enumerates exactly what it returns: titles held, company status, country of incorporation, directors and PSCs. The exact-vs-fuzzy distinction and the 'proprietor' framing separate it from siblings like ownership_by_company and entity_relationships without needing the schema.

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?

Gives clear selection guidance between the two input modes: company_number for an exact match, name as a fuzzy substring search with an explicit warning that name matches are a candidate set, not a portfolio. It does not name a specific sibling as the alternative for the fuzzy case, so it stops short of the top band.

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