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

With no annotations, the description carries the full burden. It discloses the key behavioral trait that the address is disposable, real, and can receive mail for a short time, which goes beyond the tool name. However, it doesn't mention expiration specifics or side effects, though the parameter schema covers TTL.

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 a single, front-loaded sentence with no filler. It conveys what the tool does, why to use it, and what to do next, all without redundancy.

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 creation tool with one optional parameter and no output schema, the description gives adequate context: purpose, usage, and next step. It doesn't explicitly state the return value format, but the phrase 'Get a fresh, real email address' implies the result, and the overall completeness is strong.

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 input schema provides 100% coverage with a clear description of ttlMinutes, including default, maximum, and meaning. The tool description itself does not add any parameter-specific guidance, so the baseline score of 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?

The description clearly states the tool's function: obtaining a fresh, real email address for receiving mail temporarily. It distinguishes itself from siblings by explicitly mentioning the follow-up call to get_test_email_messages, and the title reinforces the purpose.

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 provides a clear usage scenario: sign up for something being tested, then check messages with get_test_email_messages. It names the sibling tool as the next step, but doesn't explicitly state when not to use this tool or compare to alternatives like rent_test_phone_number.

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?

With no annotations, the description carries the transparency burden. It adds the behavioral nuance of 'received so far', indicating a non-waiting snapshot of current messages. It also discloses the prerequisite of an address created by create_test_email, but does not mention return format or error handling.

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 a single, front-loaded sentence that efficiently conveys purpose, scope, and prerequisite. There is 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?

For a simple one-parameter tool, the description is nearly complete: it specifies what is returned (messages), the source (address), and the condition ('received so far'). It lacks explicit details about the return message format, but the absence is acceptable given the tool's straightforward nature.

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 input schema already has 100% description coverage for the 'address' parameter, so the baseline is 3. The tool description primarily echoes the schema's description, reinforcing the link to create_test_email but adding little extra semantic meaning.

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 clearly states the tool retrieves messages for a test email address, using the verb 'Get' and specifying the resource 'messages'. It distinguishes itself from siblings like wait_for_test_sms and list_services by referencing the test email address.

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 the tool is used after create_test_email, as it specifies 'created with create_test_email'. It clearly indicates the context of use, though it does not explicitly name alternative tools or state when not 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?

With no annotations, the description carries the full burden. It clearly indicates this is a read-only listing operation by using the verb 'List' and further adds value by mentioning that prices are included. It does not explicitly state that no rental occurs, but the contrast with sibling tools makes this sufficiently clear.

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 a single, well-structured sentence that front-loads the core purpose, provides concrete examples, and mentions prices. There is no wasted wording; every element 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?

For a simple, parameterless list tool with no output schema, the description is complete. It tells the user exactly what will be returned (services and prices) and gives illustrative examples, leaving no critical gaps for the intended use case.

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 has zero parameters, so the baseline is 4. The description needs to add no parameter meaning, and it appropriately focuses on the output (list of services and prices). The schema coverage is trivially 100% since there are no properties.

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 clearly states the tool's purpose with a specific verb ('List') and resource ('services a real UK phone number can be rented for'), and includes examples (WhatsApp, Telegram, Google, Discord) to eliminate ambiguity. It distinguishes itself from sibling tools like rent_test_phone_number by focusing on the listing aspect rather than the rental action.

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 provides clear context—this is for seeing available services and prices before renting a UK phone number—which implies when to use it. However, it does not explicitly state exclusionary guidance (e.g., 'use rent_test_phone_number to actually rent') or mention a specific alternative tool, so it falls short of a 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?

With no annotations provided, the description carries the full burden of disclosing side effects. It explicitly states 'Debits the account balance' and 'Returns a rentalId', which are important behavioral traits. It does not mention potential failures like insufficient balance or cancellation, but the key side effects are covered.

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 sentences, all substantive and free of fluff. It front-loads the core purpose, then adds the critical side effect, and finally gives actionable follow-up guidance.

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?

Given there is no output schema and no annotations, the description provides enough context: it explains what the tool does, what it returns (rentalId), and how that return value is used with a sibling tool. It could mention error cases or cost details, but for a two-parameter tool, it is reasonably 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?

Schema description coverage is 100%, so the parameters are already well-documented. The description adds little beyond the schema, aside from contextualizing serviceSlug as a 'given service' and period implicitly affecting the debit. This meets the baseline but does not exceed it.

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 clearly identifies the action ('Rent'), the resource ('a real UK phone number'), and the purpose ('receive an SMS/OTP verification code'). It is easily distinguished from sibling tools like create_test_email or wait_for_test_sms by focusing on the phone number rental and service-specific context.

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 conveys when to use the tool: when you need a phone number to receive an SMS/OTP for a specific service. It also tells the user to use wait_for_test_sms with the returned rentalId, providing a clear next step. However, it does not explicitly exclude alternatives or compare with other tools, so it falls short of a 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?

With no annotations provided, the description carries the full burden. It discloses that the tool blocks and can time out, which is useful. However, it does not specify what happens on timeout (error vs. empty result), what the return value is (the OTP code?), or that it polls at intervalMs. This leaves important behavior undocumented.

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 a single sentence that is concise and front-loaded with the key action ('Block until...'). Every word contributes to understanding the tool's core function, with no filler or repetition.

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?

Despite having only 3 parameters and no output schema, the description is too sparse. It omits the return value, timeout behavior, and relationship to sibling tools like rent_test_phone_number. Given the lack of annotations and output schema, the description should provide more context about what the caller can expect upon success or timeout.

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%, as each parameter has a description. The tool description itself adds no parameter details beyond stating the blocking/timeout behavior. Since the schema already explains the parameters well, a baseline score of 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?

The description states a specific action: 'Block until the first SMS/OTP code arrives on a phone rental, or time out.' It clearly identifies the resource (SMS/OTP code on a phone rental) and distinguishes itself from sibling tools like rent_test_phone_number (which creates the rental) and email-related tools.

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 phrase 'on a phone rental' implies the user must have already rented a phone, and the parameter description for rentalId ('returned by rent_test_phone_number') reinforces this prerequisite. However, the description does not explicitly state when to use this tool versus alternatives, nor does it mention what to do for email (e.g., use get_test_email_messages). Usage context is implied but not explicitly guided.

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