RegTail

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

Annotations already cover readOnly/idempotent/openWorld/non-destructive, so the bar is low, yet the description adds genuinely useful non-structural facts: no account or credit required, duplicate plates collapse to one lookup, and prediction-based ranking is deliberately excluded. The only gap is what happens when a plate fails to resolve.

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?

Four short sentences, front-loaded with the core action and with no filler. Some phrasing is awkward and low-information ("Includes questions from free facts, comparison image and report links"), which slightly dilutes an otherwise tight block.

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 not be enumerated, and the description still adds auth posture, dedupe behaviour and the free-vs-detailed boundary. What is missing is failure handling and any hint about the cost of a call, both relevant for an openWorld tool with no credit requirement.

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 a single parameter and the schema already giving format guidance ("UK registration plate, any spacing or case"), the description adds the cardinality constraint ("exactly two plates") and the dedupe rule, which are semantic behaviours the schema's min/max items alone do not explain. Limited headroom remains for a single-param tool.

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 and resource ("Compare ... for exactly two plates") and enumerates the compared facets: identity, status and latest MOT test. It also bounds scope against the paid sibling by saying next-MOT estimates and likely repairs "stay in the detailed report". The word "projections" is jargon that is never defined, which keeps it just short of a 5.

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 implied rather than stated: the description makes clear this is the free two-plate comparison and that deeper analysis lives in "the detailed report", but it never names the actual alternatives (free_check, full_report, decode_plate) or says when a single-plate lookup should be used instead. It also does not say what to do when more than two vehicles need comparing.

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 readOnlyHint, idempotentHint, destructiveHint=false and closed-world, so the safety profile is fully covered. The description contributes the account-linking prerequisite and the fact that a pricing URL is returned, but adds no further behavioral detail (e.g., refresh/caching, failure mode when unlinked).

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 compact clauses, front-loaded with what the tool returns and ending with the prerequisite. Slightly awkward flow around the pricing_url aside, there is no wasted text.

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 inputs, full annotation coverage, and an output schema handling return values, the description only needs to state purpose and prerequisites, which it does. Additional context on credit consumption or when a balance check should precede a report would make it fully complete.

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 the baseline is 4 and no schema semantics need compensating. The description correctly does not invent parameters.

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 a concrete resource (the user's RegTail account credit balance) and specifies a second return value (pricing_url), so an agent knows exactly what this tool yields. It is distinguishable from the sibling vehicle-report tools, though it does not explicitly say so.

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?

It states a prerequisite ('Needs the user's RegTail account linked'), which is useful context for invocation. However, it gives no when-to-use guidance relative to siblings such as free_check or unlock_report, leaving the agent to infer that this is a pre-flight credit check.

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 closed-world, so the safety bar is covered. The description adds real context beyond that: it is offline, it does not perform a vehicle lookup, and no account is needed — the last point being auth information the annotations 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?

Three short sentences with no filler; the derived output is front-loaded, followed by the boundary condition and the auth note. Nothing repeats the schema or annotations unnecessarily.

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, read-only lookup with an output schema, the description need not explain return format, and it correctly focuses on scope, offline behavior, and the sibling alternative. It is essentially complete, though it could note edge cases (non-UK or malformed plates) that the minLength 2/maxLength 16 schema hints at.

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?

There is only one parameter and schema coverage is 100%, with the schema already documenting that the plate accepts any spacing or case. The description clarifies what the plate value is used to derive (format/age identifier/issue window) but adds no input syntax or format constraint beyond the schema, so baseline 3 applies.

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 states precisely what the tool computes — the issue window (format, age identifier, first/last month) from the plate alone — rather than the generic 'decode a plate' of the title. It also explicitly carves out a sibling, saying it does not look the car up and to use free_check for that, so an agent can separate it from free_check/full_report without reading schemas.

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?

It names the alternative (free_check) and the condition that selects it (you want the car looked up), which is genuine routing guidance. It stops short of stating broader when-to-use context (e.g., what task the issue-date window serves) or other exclusions, so it is clear but not exhaustive.

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, openWorld and non-destructive, so the safety profile is covered. The description adds useful non-obvious behavior: no account or credit required, the output contains locked teasers and a verdict image, and it can pose up to three questions. It does not discuss rate limits or caching, but with annotations carrying the safety burden this is strong.

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 payload contents before the scoping and presentation notes, and every sentence carries information. The middle list of returned elements is dense but not padded; it reads as efficient rather than sprawling.

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?

Output schema exists, so return-value documentation is not required, yet the description still complements it with scope, exclusions, an auth/credit note and a rendering instruction. For a single-parameter read tool with rich annotations, an agent has everything needed to invoke it correctly.

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?

There is a single required parameter and schema description coverage is 100%; the schema already documents 'UK registration plate, any spacing or case'. The description adds no format, validation or normalization detail beyond that, so the baseline of 3 for a fully documented schema is appropriate.

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 specific resource (a UK car's free check) and enumerates exactly what it covers: identity, tax, MOT status, latest test, defects, mileage and summary flags. It also implicitly distinguishes itself from the heavier sibling by stating that next-MOT estimates, repair prices, mileage analysis and older MOT details 'require the detailed report', pointing at full_report.

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?

It defines the boundary explicitly: this tool gives the free facts plus teasers, and the deeper fields need the detailed report. It also states the entry condition ('No account or credit needed') and instructs the agent to show the returned markdown field as-is, leaving no ambiguity about when and how to use it.

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: it explicitly never spends credits, requires the user's RegTail account to be linked, and specifies the degraded return path (unlocked=false plus message) with the required user-confirmation step before escalating.

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 resource and its contents, then usage, prerequisites, and the non-spending guarantee in a compact flow. The section enumeration is long but each item describes real report content, so it mostly earns its place.

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 an output schema present, return-value detail is unnecessary; the description instead covers the things structured data cannot express — account prerequisite, credit behavior, and the not-unlocked fallback with the required confirmation step. Nothing an agent needs to call this correctly is missing.

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% and the single plate parameter is fully documented there (UK plate, any spacing or case), so the schema does the heavy lifting. The description only ties plate to unlock state as a precondition, adding little beyond the schema; baseline 3 is appropriate.

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+resource — the detailed report of a car the user has unlocked on RegTail — and enumerates its contents (verdict, MOT tests, mileage, checklist, gaps). This is clearly distinguishable from free_check, sample_report, and unlock_report among the 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?

"Use to discuss a car in depth" gives the positive condition, and the fallback rule ("for a plate that is not unlocked it returns unlocked=false and a message; then ask the user before calling unlock_report") names the alternative tool and the exact condition that selects it.

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 this is a read-only, idempotent, non-destructive, closed-world read. The description adds value beyond them by disclosing the auth precondition (RegTail account must be linked) and the fact that unlock windows carry an expiry. It does not discuss rate limits or freshness of the 'recent checks' list.

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?

Roughly two sentences, front-loaded with what is returned, followed by the motive and the prerequisite. Slightly circuitous in the clause about picking up a previously checked car, but no sentence is wasted.

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 not be restated, and with no parameters there is little else to specify. The description covers the auth prerequisite and the data shape, leaving only minor gaps such as how many recent checks are returned.

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, which is the baseline-4 case. Nothing further is needed from the description about argument semantics.

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 the specific resources returned: the cars the user has unlocked (with unlock expiry) plus their recent checks. That is a concrete retrieval purpose distinguishable from write-oriented siblings like unlock_report and decode_plate. It does not, however, explicitly differentiate itself from similar retrieval siblings such as free_check or sample_report.

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 an implied use case ('so a conversation can pick up a car checked earlier') and a prerequisite ('Needs the user's RegTail account linked'). It stops short of naming when a sibling like full_report or free_check would be the better choice, so the routing guidance is only implied.

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, openWorld and non-destructive, so the safety bar is low. The description adds genuinely new context the annotations cannot convey: 'No account or spend' tells the agent there is no cost or login prerequisite, and the confirm/fallback rule describes behavior on ambiguous input.

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?

Three short sentences, front-loaded with the core action and free of filler. Every sentence either defines the input, the cost profile, or the next step.

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 not be explained, and the description already signals the output is a plate. Combined with the fallback guidance, it covers what an agent needs to invoke this single-parameter tool correctly; only input size limits are left to the schema.

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 must carry the burden; it does map the three accepted forms (typed plate, car photo data URL, supported advert URL) onto the discriminated union and hints that only 'supported' advert URLs work. It omits constraints the schema enforces silently, such as the 16-char plate limit and the 5.6 MB photo payload cap, so it only partially compensates.

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 and resource ('Resolve a typed plate, car photo data URL or supported advert URL') and narrows the outcome ('to a plate only'). It is clearly distinguishable from siblings like decode_plate and full_report without opening any 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 an explicit fallback workflow ('If uncertain, ask the user to confirm; if unavailable, ask for the typed plate') and routes to the next tool ('Then use free_check'). It stops short of stating when this tool should NOT be used versus alternatives such as decode_plate, so it is strong but not complete.

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 readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavioral context beyond that: no account/authentication is required, and the output is deterministic static sample data rather than live user data. It does not, however, say anything about output shape or size, though an output schema exists to cover that.

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?

Three short sentences with no filler, front-loading what the tool returns and then the usage condition. The fixed sample car is identified concretely, which is the single most decision-relevant fact.

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 the description need not explain return values. Combined with explicit usage conditions, the auth-free nature, and the deterministic sample behaviour, an agent has everything needed to call this correctly.

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 nothing for the description to disambiguate; the baseline for a parameterless tool applies. The description correctly communicates that no arguments are needed and none vary the result.

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 (the detailed report plus viewing advice for one named public sample car, CX52HHM) and its scope: it demonstrates what a detailed report contains rather than reporting on a real vehicle. This distinguishes it cleanly from siblings full_report and viewing_advice, which handle the user's own vehicle.

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 an explicit trigger ("Use when the user asks what RegTail's detailed report looks like") and an explicit exclusion ("It is always the same sample car, never the user's car"), which routes the agent away from this tool when the user wants their own car's data. No inference required.

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 credit cost, the 30-day durability, the idempotent re-unlock behavior ('already unlocked costs nothing again'), the account-linking prerequisite, and the no-credit no-op. None of this is derivable from readOnlyHint=false / idempotentHint=true alone, and nothing contradicts them.

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?

Four tight sentences, front-loaded with the cost and the returned artifact, followed by the consent ritual and the edge cases. No filler and nothing repeated from the schema or 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?

For a spend-a-credit mutation with an output schema, the description covers cost, prerequisite auth, consent gating, idempotency, and failure mode. Return values are delegated to the output schema, which is correct.

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?

Both parameters are fully described in the schema, so the baseline is 3. The description nevertheless adds workflow meaning to 'confirmed' by tying it to the ask-first ritual, making it clear the flag encodes a just-given user consent rather than a static setting.

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?

Names a specific verb+resource with its full economics: spends one RegTail credit, unlocks the detailed report for a plate for 30 days, and returns the report. It also positions itself against the sibling full_report ('as full_report does'), so an agent can tell the paid-unlock path from the plain report path.

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 explicit when and when-not: ask the user first, every time, call only after they agree, and never unlock on your own initiative or to answer a general question. The re-unlock case and the no-credit case are both resolved, leaving no inference to the agent.

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 behavior, and the description adds what they cannot: the account-link and plate-unlock preconditions and an explicit 'never spends' credit guarantee. It doesn't mention rate limits or failure modes, but the cost/safety picture is notably enriched beyond 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 tight sentences with the purpose front-loaded and the constraints and output content following. Slightly dense in the second clause, but essentially zero waste.

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 an output schema present, return values needn't be explained, yet the description still sketches them helpfully. Prerequisites, cost behavior, and read-only status are all covered; only explicit sibling routing is absent.

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 documented in the schema ('UK registration plate, any spacing or case'), so the baseline is 3. The description's only added meaning is the requirement that the plate be unlocked, which is useful but tied to state rather than parameter format.

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+resource ('Advice for viewing an unlocked car in person') and enumerates the payload ('a summary, priorities to check ... and known weak spots of the model'). This clearly separates it from siblings like full_report, compare_vehicles, or free_check without needing to open any 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 the operative context and prerequisites: it applies to an unlocked car and requires a linked account plus an unlocked plate, implying unlock_report/free_check must run first. It stops short of naming those sibling tools or stating when NOT to use this over alternatives, so it stays at 4 rather than 5.

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