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

With no annotations, the description carries the full burden and does well: it discloses the paid nature and exact price (£2.99 one-time), the auth requirement, and the degraded no-token behavior. It omits rate limits, whether the charge is re-applied on repeat calls with the same token, and failure modes for invalid postcodes.

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-loads the most decisive fact ('PAID (£2.99 one-time)') before the feature list, so an agent can triage cost immediately. The long comma-separated inventory of data domains is dense but each item is a genuine capability distinction; only the list length risks losing the auth/fallback sentences at the end.

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?

No output schema exists, and the description compensates by naming the return format ('JSON + markdown') and the no-token return value. For a paid, two-parameter tool this is nearly complete; only the invalid-postcode and repeat-charge behavior remain unaddressed.

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 coverage is 50% (only access_token is described in the schema), but the description compensates by explaining where the token comes from and that a Bearer header is an accepted alternative. The postcode parameter receives no additional semantics beyond its name, leaving the 50% gap only partially covered.

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 concrete verb/resource pair ('Full UK Postcode Property Report') and enumerates the exact data domains returned (Land Registry sales, flood, crime, EPC, CQC, planning, amenities). The 'Full' qualifier plus the 3-month/median specifics implicitly contrast with the sibling postcode_summary, though it never names that sibling directly.

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?

Clearly states the precondition (access_token from /buy via Stripe Checkout) and the fallback behavior when no token is supplied ('returns a checkout link'), which tells the agent exactly how to respond to an unauthenticated call. It stops short of explicitly routing the agent to the buy_report_link or postcode_summary siblings by name.

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