mcp

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

No annotations provided, so description carries full burden. Clearly discloses non-destructive 'peek' behavior ('Does NOT mark the OTP as consumed'), which is critical for idempotency. Missing only minor details like rate limits or pagination behavior.

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 sentences with zero waste. Front-loaded with core function (list messages) and key behavioral constraint (non-consuming). Each sentence earns its place: function definition, usage guidance, and behavioral confirmation.

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?

Complete for this complexity level. References relationship to provision_number (via session_id schema description) and wait_for_otp (via description text). Output schema exists so return values need not be described. Covers all necessary context for safe invocation.

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 has description for session_id ('Session ID returned by provision_number'). Description references 'this session' conceptually linking to the parameter but does not add format, syntax, or semantic details beyond what schema provides. Baseline score appropriate given schema coverage exists.

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 specific verb 'List' with resource 'SMS messages' and scope 'in this session'. Clearly distinguishes from sibling wait_for_otp by emphasizing 'without consuming the OTP', resolving potential confusion between inspection and consumption operations.

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 states when to use ('inspect raw messages', 'check if SMS arrived before calling wait_for_otp') and implicitly when not to use (does NOT consume OTP, implying use wait_for_otp if consumption is desired). Names specific sibling alternative directly.

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?

No annotations provided, so description carries full burden. It discloses the 'active' status filter and optional agent_id filtering behavior. However, it omits details about pagination, performance characteristics, or whether listing is real-time vs cached. Since output schema exists, return value documentation isn't required.

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 sentences with no waste. The purpose is front-loaded in sentence one, usage guidance in sentence two. Minor deduction for the 'sessions' vs 'numbers' terminology shift between sentences which could cause momentary confusion.

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?

Appropriate for a simple single-parameter tool with existing output schema. The description covers the parameter's purpose and basic usage scenarios. Could be improved by clarifying the relationship between sessions and numbers, but sufficient for invocation given the schema structure.

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 0% schema description coverage, the description compensates adequately by explaining that agent_id is used for 'filtering' and is 'optional' (consistent with default: null and not being required). This gives the agent clear semantic context that the schema fails to provide.

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 it lists 'active sessions' but the tool name is 'list_numbers' and the second sentence mentions 'numbers'. This terminology inconsistency creates ambiguity about whether the resource is sessions or numbers. It does distinguish from siblings (provision/release) by focusing on inspection/monitoring use cases.

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?

Provides implied usage through specific scenarios ('check for leaked sessions', 'inspect what numbers are active') but lacks explicit when-not-to-use guidance or named alternatives. The agent can infer this is for monitoring rather than provisioning, but explicit comparisons to provision_number or release_number are absent.

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 full disclosure burden. It successfully communicates exclusivity ('exclusively yours'), temporal limits ('ttl_seconds'), output format ('e164'), and session dependency ('session_id needed for all subsequent calls'). Minor gap: doesn't mention what happens at TTL expiration or if provisioning fails.

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 sentences with zero waste. Front-loaded with core action, followed by return values, exclusivity terms, and workflow. 'Next step:' formatting creates clear visual separation for operational 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?

Comprehensive for a provisioning tool. Despite having an output schema (per context signals), the description proactively documents return format (e164) and session management requirements. Covers the full lifecycle from provisioning through subsequent OTP retrieval.

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?

Context signals indicate 0% schema coverage (likely referring to the wrapper 'input' object), but the nested schema actually contains descriptions for all functional parameters (country, agent_id, ttl_seconds, webhook_url). The description references 'ttl_seconds' in context but doesn't explain input parameters beyond what the schema provides, warranting the baseline score.

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 uses specific verb 'Lease' with clear resource 'real mobile phone number' and purpose 'receiving SMS OTP codes'. It clearly distinguishes from siblings like list_numbers (which would list existing numbers) and wait_for_otp (which consumes the output of this tool).

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 states the workflow sequence: provision → use number on target service → call wait_for_otp with session_id. It names the specific sibling tool (wait_for_otp) as the next step, providing clear temporal guidance on when to use this tool versus others.

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 successfully discloses the resource management behavior (return to pool) and critical cleanup requirements. It could improve by mentioning idempotency or return value semantics, but the 'even on error' instruction provides essential behavioral context.

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 sentences, zero waste. First sentence establishes purpose immediately; second sentence provides mandatory cleanup instruction. Perfectly front-loaded and appropriately sized for the tool's complexity.

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 the output schema exists, the description appropriately omits return value details. It covers the resource lifecycle context and cleanup obligations necessary for a pool-management tool. Minor gap regarding idempotency or error response details, but sufficient for invocation decisions.

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?

While the context signal indicates 0% schema coverage, the provided schema actually documents session_id as returned by provision_number. The description mentions 'the session' which implicitly references the parameter, but does not explicitly describe the parameter structure or requirements, relying on the schema for that mapping.

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 action (Release), resource (provisioned number), and destination (pool). It explicitly references the provisioning lifecycle, distinguishing it from sibling provision_number by indicating this is the cleanup/counterpart operation.

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?

Exceptional guidance provided: explicitly states when to use (when done with the session), mandates usage even on error (critical edge case), and explains the consequence of omission (consuming pool capacity). This prevents resource leaks effectively.

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 fully discloses critical behavioral traits: blocking nature ('Block until'), polling mechanism ('Polls the AgentSIM API'), timeout constraints, error conditions ('If the OTP does not arrive in time'), and return values ('Returns the OTP code and the message').

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?

Five sentences, each earning its place: purpose declaration, polling mechanics, success return, error handling, and lifecycle cleanup. Front-loaded with the blocking behavior and no redundant 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?

Excellent coverage for a complex stateful tool. Since an output schema exists, the description appropriately does not detail return structure beyond naming the returned fields, while comprehensively covering the blocking lifecycle, error states, and cleanup requirements.

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?

Given 0% schema description coverage, the description partially compensates by explicitly referencing `timeout_seconds` and implying `session_id` via 'this session', but fails to mention the `auto_reroute` parameter or its automatic number-swapping behavior despite describing timeout scenarios.

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 opens with a specific action ('Block until an SMS OTP arrives') and resource, clearly distinguishing this from siblings: it follows provision_number (session creation) and precedes release_number (cleanup), establishing a clear workflow.

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?

Provides explicit workflow guidance ('Always call `release_number` after you have used the OTP') and error handling advice ('raises a ToolError with advice on retrying'). Lacks explicit contrast with get_messages for non-blocking alternatives.

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