UK Leads

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

Annotations already declare readOnly, idempotent and non-destructive, but the description adds two pieces of non-obvious context: authentication is required ('Needs you to sign in to UK Leads') and the call has no quota cost ('Never spends an unlock'). That cost/auth disclosure is the kind of thing an agent cannot get from the annotations.

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?

Two short sentences, front-loaded with what is returned, followed by the prerequisite and the cost guarantee. Every clause carries information.

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?

With no output schema, the description compensates by enumerating the returned values (plan, unlocks left, rate limits). For a zero-parameter read tool, an agent has everything needed to call it and interpret the result.

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 tool takes zero parameters and the schema is an empty object, so there is nothing for the description to disambiguate. Baseline 4 applies; no parameter claims are made or needed.

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 gives a specific verb ('Show') and an enumerated resource set: the desk's plan, unlocks remaining this month, and rate limits. It implicitly separates itself from the 'unlock' sibling via 'Never spends an unlock', though it does not name the other siblings (coverage, search) 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?

Usage is only implied: an agent can infer this is the read-side quota check to call before spending unlocks. There is no explicit 'use this when...' statement or comparison to 'coverage' or 'search', so routing relies on inference.

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

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

Annotations already cover read-only, idempotent, non-destructive, closed-world behavior, so the bar is lower; the description still adds real context by stating no authentication is required, that counts are consistent with the website, and that the unlock rule is included in the payload. It does not describe response shape, but with no output schema the content list partially compensates.

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?

A single front-loaded sentence covering scope, dimensions, and the unlock rule. The closing clauses ('Numbers match the website') are slightly promotional but short and arguably convey data fidelity, so waste is minimal.

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?

For a simple, zero-parameter read-only tool this is close to adequate, but with no output schema the description never hints at the response structure (flat list of cities/regions vs. nested breakdown) or size, which is the main thing an agent would still need to guess.

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 tool takes zero parameters, so there is no parameter semantics to explain and the baseline of 4 applies. Nothing in the description misleads about inputs.

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 the resource and its contents precisely: counts of businesses, verified and named owners, and lines broken down by city and dental region, plus the unlock rule. An agent can tell this is a dataset-coverage/counts tool rather than a search or unlock action. It stops short of explicitly contrasting itself with the siblings (search, unlock, balance).

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?

Usage is only implied: an agent can infer this is the tool to call to see whether a city or region has data, but the description never says when to prefer it over search, unlock, or balance, nor any sequencing (e.g., check coverage before unlocking). The only stated precondition is 'No sign-in needed'.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds material context beyond them: only public fields are returned, owner names and numbers are withheld, no sign-in needed, and authenticated calls surface prior unlocks. This tells the agent exactly what it will and will not get, which is the important behavioral caveat for this tool.

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?

Dense but well front-loaded: purpose first, then coverage caveats, then return shape, then the unlock handoff. A few clauses about sign-in state could be tightened, but no sentence is filler.

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?

There is no output schema, and the description compensates by enumerating the returned fields (name, street, postcode, shop/practice line, owner-held flag, unlock cost). Combined with the auth-state note and the unlock handoff, an agent has everything needed to call and interpret results.

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 100%, so the baseline is 3; the description earns above that by explaining that salon, barber and beauty draw from a single regional list while dental covers independent practices nationwide and accepts a region name. That semantic distinction is not derivable from the enum alone, though 'limit' and postcode formatting are left entirely to the schema.

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?

Opens with a specific verb and resource plus a geographic scope ('Find independent businesses near a town, borough or postcode in England'). It immediately distinguishes itself from unlock by stating owner names never appear here, so an agent can separate it from its sibling without opening either 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?

Explicitly routes follow-up work: 'Pass a result's id to unlock to get them,' and clarifies that no sign-in is required while noting signed-in results add unlock status. It also scopes trade coverage (salon/barber/beauty share one list limited to five cities, dental is England-wide and accepts regions), which helps an agent pick a valid query. No guidance on when to prefer coverage or balance instead, so not a full 5.

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

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

Goes well beyond the annotations by disclosing the authentication requirement (sign in to UK Leads), the credit consumption model (verified owner costs one unlock, named owner free, re-unlocking the same owner free), and that dental results indicate TPS/CTPS checking. This is rich behavioral context that the structured fields do not carry.

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 primary action and its return value before moving to prerequisites and cost. Dense but every sentence carries functional weight, though the TPS/CTPS instruction sits slightly apart from the core unlock mechanics.

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?

For a single-parameter tool with no output schema, the description covers what is revealed, the auth requirement, and the cost behavior. It is essentially complete, with only the exact shape of the returned owner data left implicit.

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 single parameter is fully described in the schema (100% coverage), and the description adds no syntax or format detail beyond 'one business from search'. Baseline 3 is appropriate when the schema already documents the only input.

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 (reveal) and the exact resources returned (owner's name, phone, public email) for a single business from search. This clearly distinguishes it from the sibling tools search, balance, and coverage, which handle discovery and credit-checking rather than owner revelation.

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?

Makes clear this operates on 'one business from search', implying search precedes unlock, and notes the sign-in requirement and cost model that gate its use. It stops short of explicitly naming alternatives or stating when not to use it, but the operational context is clear.

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