TPSClear

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

Annotations mark the tool as non-read-only, open-world and non-idempotent; the description adds real context beyond that by explaining no charge occurs here, a human opens and pays the link, credits post after payment, and the response carries prices in minor units. The account prerequisites are an extra behavioral constraint the annotations do not express.

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 and well ordered: what it does, what it does not do, prerequisites, then the catalogue. The pack list is long and semicolon-dense in a single sentence, which is heavy to parse, but each entry carries distinct commercial information that is not available elsewhere.

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?

Covers return value (URL), the payment flow, account prerequisites and response price units, which is strong given there is no output schema. It does not mention link expiry or that repeated calls create additional links, small but relevant gaps for a non-idempotent payment tool.

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 schema fully enumerates the pack ids but only labels them 'The pack id.' The description expands each of the 21 enum values with what it buys (checks, DNCR washes, dead number checks), quantity, currency and price, which is exactly the meaning an agent needs to pick correctly.

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: creates a Stripe Checkout payment link for a prepaid pack and returns the URL. It also names the platform (Stripe), the target account, and the concrete outcome (credits land once paid), which no sibling tool does.

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 conditions for use: needs a live, self-serve account that names its client business, and clarifies this tool does not itself charge anyone. It does not explicitly route the agent to siblings (e.g., get_account to check existing balances before buying), so it stops short of naming alternatives.

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=false, openWorldHint=true, idempotentHint=false, and destructiveHint=false. The description adds substantial context beyond annotations: OAuth or tpsc_live_ key auth, credit consumption per check, double cost for US numbers, free checks for non-mobiles and invalid numbers, and API equivalence to POST /v1/dead-number.

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?

The description is three tight sentences, front-loaded with purpose and followed by auth and billing details. Every sentence adds useful information with no wasted wording.

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 still explains the result categories, authentication requirements, billing behavior, and API equivalence. That is sufficient for an agent to understand and invoke the tool 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 single phone_numbers parameter is fully documented in the schema, including the 500-number limit and example format. The description adds cost semantics tied to number type and US status, which helps interpret the parameter values, though it does not add format details beyond 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?

The description states a specific verb and resource: live mobile network (HLR) lookups, with outcomes live, switched off, or dead. It is clear what the tool does, but it does not explicitly distinguish itself from siblings such as screen_numbers or wash_au_numbers.

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 description implies usage for checking whether mobiles are live and notes the live-account requirement. However, it gives no explicit when-to-use guidance versus alternatives and no when-not-to-use exclusions.

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/closed-world, and the description adds genuinely new context: balances a key lacks scope for surface as an error rather than being omitted, and the call is free. It does not describe response shape or ordering, but the extra scope-error and cost disclosures are substantive.

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 dense sentence that front-loads the resource ('The connected account and the key it acts as') and then enumerates each balance, followed by a short error note and a cost note. Endpoint paths add provenance without wasting space.

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 input schema, no output schema and full annotation coverage, the description carries the remaining burden and does so: it enumerates the returned account fields, each balance type, and the scope-error behavior. An agent could call this correctly and interpret the result without further documentation.

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. The description correctly reflects this by not inventing any input; all listed items are outputs, not arguments.

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: returns the connected account, the key's environment/scopes/company status, and remaining balances for UK credits, AU washes and dead-number checks. This clearly separates it from siblings like buy_credits or wash_au_numbers, which act on balances rather than report them.

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?

Implies usage well (call it to inspect account state and remaining balance before purchasing or running a paid operation) and 'Costs nothing' signals it is safe and free to call. It does not explicitly say when not to use it or name alternatives, so it stops short of the 5 bar.

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?

Beyond the read-only annotations, it discloses three substantive behaviors: phone numbers are never returned (data redaction), it requires the usage scope (authorization prerequisite), and it costs nothing (no credit consumption, relevant given balance-oriented siblings). Ordering ('newest first') and pagination mechanics are also stated, though rate limits or result caps beyond the schema's 100 are not.

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?

The definition opens with the resource and ordering, then the content breakdown, then operational notes; every clause carries information. The first sentence is dense with a long parenthetical field list, which costs some readability 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?

With no output schema, the description compensates by enumerating returned fields (time, environment, numbers checked, outcome counts, campaign_ref, request_id) and stating what is withheld (phone numbers). Combined with auth scope, cost, ordering and pagination notes, an agent has everything needed to call 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?

Schema coverage is 100%, so limit and before are already fully documented, including the next_before hint. The description only reinforces the pagination contract and ordering ('newest first'), adding little semantics beyond the schema, which supports the baseline 3.

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 specific resource ('the account's recent activity') and enumerates exactly what it contains: UK screening calls with their fields, plus movements on the UK credit, AU wash and dead number balances. That distinguishes it from screen_numbers and check_dead_numbers, though it never names a sibling explicitly.

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 by the content description (you call it to review recent screening and balance activity), and pagination guidance is given ('Page back by passing next_before as before'). There is no explicit when-to-use/when-not or contrast with alternatives such as get_account, so the agent must infer selection.

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 openWorldHint=false, so the safety profile is fully covered by structured data. The description adds real value beyond that with 'Costs nothing' (no billing impact) and the fact that it returns the full catalogue rather than a page, but it is silent on ordering and pagination, so it is an increment rather than a deep disclosure.

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?

One dense, front-loaded sentence with no filler; the scope statement comes first and the most agent-relevant detail (the id that buy_credits consumes) is emphasised inline rather than buried.

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, so the description must carry the return shape, and it does: it names every field an agent needs, including the awkward but important detail that prices are in minor units ex VAT. Nothing needed to call this tool or interpret its result 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 description coverage is 100% and the single enum parameter is documented in detail in the schema itself, so the baseline is 3. The description only repeats 'Optionally filter by kind' and adds no semantics the schema does not already carry.

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 and resource (list prepaid packs) and enumerates exactly what each record contains: id, name, what it buys, price in minor units ex VAT, currency, and credit duration. It also ties the returned id to the sibling buy_credits, making the tool distinguishable from every other sibling at a glance.

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 parenthetical 'the one buy_credits takes' implies the intended workflow (look up pack ids before purchasing), and 'Optionally filter by kind' plus 'Costs nothing' tell the agent it is a free, filterable read. It stops short of an explicit when-not statement or a named alternative for the purchase step.

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?

The description adds genuinely useful behavior beyond annotations: it discloses billing (prepaid UK credits, one per distinct valid number), the fixture behavior of test API keys, and the possible result values. The credit-charging detail is especially valuable since annotations declare readOnlyHint=false without explaining why a screening call is a non-read operation.

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 tightly packed sentences, front-loaded with purpose, then result values, then cost behavior, then API mapping. Every sentence carries distinct information with no repetition of the name or title.

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 two-parameter tool with full schema coverage and no output schema, the description supplies everything an agent needs: what it does, when to use it, what the outputs mean, and the cost implication of each call including the zero-cost test path.

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 100%, so both parameters (campaign_ref, phone_numbers) are fully documented in structured fields. The description adds only an indirect hint ('one per distinct valid number') about billing/deduplication, but nothing about parameter formats or limits beyond what the schema already states.

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 and resource (screen UK phone numbers against TPS and CTPS) plus the timing context ('before calling'). It clearly distinguishes itself from siblings like check_dead_numbers (dead numbers, not regulatory screening) and wash_au_numbers (Australian numbers), so an agent can select it without opening a 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?

'...before calling' gives a clear usage context, and the TPS/CTPS register framing implies the compliance use case. However, it never explicitly names the sibling alternatives (check_dead_numbers, wash_au_numbers) or states when NOT to use this tool, so it stops short of full routing guidance.

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=false, destructive=false and idempotent=true, so the safety profile is covered. The description adds genuinely useful context beyond that: the endpoint, the gating relationship to live-key screening, and the regulatory reason the field exists. It doesn't mention validation failures or whether a post-screening name change is permitted, but against existing annotations this is solid.

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?

The operation and prerequisite are front-loaded, which is good. However, the trailing explanation about Voll Studios Ltd and DMA licensing is backstory that doesn't change how the agent invokes the tool, and it takes up roughly half the 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?

For a one-parameter setter with full schema coverage and clear annotations, the description supplies the one thing structured fields can't: that this must be called before a live key can screen. Nothing essential to correct invocation 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 property already documents 'the legal name of the client business' with an example and length bounds. The description's phrase 'legal name' restates the schema rather than adding new semantics, so the 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?

States a specific verb and resource ('Set the legal name of the business this account screens numbers for') and even names the underlying endpoint PATCH /v1/me. It is clearly distinguishable from siblings like get_account or screen_numbers, which read or act on numbers rather than configuring the account identity.

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 a concrete prerequisite: 'Required before a live key can screen,' which tells the agent when this call is mandatory rather than optional. It does not discuss what to do if the name is already set or whether it can be changed later, so it stops short of full when/when-not guidance.

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=false, openWorldHint=true, idempotentHint=false, and destructiveHint=false. The description adds substantial operational context beyond those annotations: OAuth or live key required, no test mode, one prepaid wash per distinct valid number, free invalid numbers, and refunds for unanswered register checks.

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 purpose, followed by authentication, billing, and endpoint details. Each sentence carries useful information without repetition or 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?

The description adequately covers authentication, cost, refunds, and the equivalent endpoint for a one-parameter tool with annotations. It stops short of explaining what each washed number returns and does not explicitly differentiate from sibling tools, which are modest gaps given the lack of an output 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?

There is only one parameter, and schema description coverage is 100%, including the 500-number limit and an example format. The description adds the billing-relevant idea of a distinct valid number but does not need to expand further on parameter syntax.

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: washing Australian phone numbers against the Do Not Call Register, with the equivalent endpoint. It is clear what the tool does, but it does not explicitly differentiate itself from siblings such as screen_numbers or check_dead_numbers.

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 description gives prerequisites and constraints such as needing a live account and the absence of a test mode, plus billing behavior. However, it does not explicitly state when to choose this tool over screen_numbers or check_dead_numbers, so usage is only implied.

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