TaskMan of London

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions checking 'availability' and 'whether a service can likely be booked soon,' implying a read-only query, but doesn't detail what the tool returns (e.g., available slots, probabilities), whether it requires authentication, or any rate limits. This leaves significant gaps in understanding its 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?

The description is a single, efficient sentence that front-loads the usage context without unnecessary words. Every part of the sentence contributes directly to understanding when to apply the tool, making it appropriately sized and well-structured.

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 complexity of a 4-parameter tool with no annotations and no output schema, the description is incomplete. It lacks details on what the tool returns, how to interpret results, and the semantics of parameters, making it insufficient for an agent to use the tool effectively without additional context or trial-and-error.

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 compensate by explaining parameters. It doesn't mention any parameters, leaving all four (service_type, postcode, preferred_date, time_preference) undocumented. The description's focus on 'dates, timing, or booking' hints at the purpose of preferred_date and time_preference but provides no concrete guidance on their use or 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?

The description states the tool's purpose as checking availability when users ask about dates/timing, but it's vague about what exactly is being checked (e.g., provider availability, service slots). It doesn't specify the resource being queried or distinguish it from siblings like 'get_customer_availability' or 'match_providers' that might serve similar purposes.

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 explicitly states when to use the tool ('when the user asks about dates, timing, or whether a service can likely be booked soon'), providing clear context for its application. However, it doesn't specify when NOT to use it or mention alternatives among the sibling tools, such as 'get_customer_availability' for customer-specific checks.

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 are provided, so the description carries the full burden. It mentions checking coverage for London postcodes but doesn't disclose behavioral traits like what the tool returns (e.g., boolean coverage status, list of available services), error handling for invalid postcodes, or any rate limits. This leaves significant gaps for a tool with no annotation coverage.

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, efficient sentence that front-loads the usage guideline. It wastes no words and is appropriately sized for the tool's complexity, making it easy to parse quickly.

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 no annotations, 0% schema coverage, and no output schema, the description is incomplete. It doesn't explain what the tool returns, how to interpret results, or details about parameters. For a tool with two parameters and no structured documentation, this leaves too much undefined for reliable agent use.

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 compensate. It mentions 'postcode' but doesn't explain its format or that it's required. It doesn't mention the 'service_type' parameter at all, leaving it undocumented. The description adds minimal value beyond the schema, failing to address the coverage gap adequately.

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 the tool checks if TaskMan covers a London postcode area, which provides a basic purpose. However, it doesn't specify the exact verb (e.g., 'check coverage' or 'validate service area') or differentiate from similar tools like 'check_availability' or 'find_services' that might also relate to service area queries. The purpose is clear but lacks sibling differentiation.

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 explicitly states 'Use when the user provides a London postcode or asks whether TaskMan covers their area,' which gives clear context for when to invoke this tool. However, it doesn't specify when NOT to use it (e.g., vs. 'check_availability' for time-based queries) or name alternatives, so it's not fully comprehensive.

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 behavioral disclosure. It mentions 'submit details for a real... booking request,' implying a write/mutation operation, but doesn't specify whether this creates a pending or confirmed booking, what permissions are needed, if it's idempotent (despite an idempotency_key parameter), or what the response looks like. This is inadequate for a 12-parameter mutation 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?

The description is a single, efficient sentence that front-loads the key action. There's no wasted verbiage, making it easy to parse quickly while conveying the essential purpose.

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 complexity (12 parameters, mutation tool, no annotations, no output schema), the description is insufficient. It doesn't explain the tool's behavior, return values, error conditions, or how it differs from siblings like 'create_customer_booking.' For a booking submission tool, this lack of context could lead to misuse.

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 compensate by explaining parameters. It mentions 'details' generically but doesn't clarify any of the 12 parameters (e.g., what 'service_type' entails, why 'idempotency_key' is needed, or what 'consent_to_contact' implies). This leaves critical parameter meaning undocumented.

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: 'submit details for a real TaskMan of London booking request.' It specifies the verb ('submit') and resource ('booking request'), but doesn't explicitly differentiate it from sibling tools like 'create_customer_booking' or 'start_booking_payment,' which prevents a perfect score.

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 some usage context with 'Use when the user is ready to submit details,' implying this is for final submission rather than preliminary steps. However, it doesn't explicitly state when NOT to use it or name alternatives among the many sibling booking-related tools, leaving room for ambiguity.

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 behavioral disclosure. It mentions the tool creates a booking but lacks details on permissions required, whether the operation is idempotent (despite an 'idempotency_key' parameter), error handling, or what happens upon success. For a mutation tool with 11 parameters, this is insufficient 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?

The description is a single, efficient sentence that front-loads key information: usage prerequisites and the core action. Every word earns its place, with no redundancy or unnecessary elaboration, making it easy for an agent to parse quickly.

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 complexity (11 parameters, no annotations, no output schema), the description is incomplete. It covers usage timing but misses behavioral traits, parameter explanations, and output details. For a tool that likely creates a persistent booking record, more context on side effects, errors, or return values is needed for safe and effective use.

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 compensate by explaining parameters. However, it adds no meaning beyond the schema—it doesn't clarify what 'session_token' or 'payment_session_id' represent, the significance of enums like 'service_type', or how parameters interact. With 11 parameters (4 required), this leaves critical gaps in understanding.

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: 'to create a booking scoped to the verified customer.' It specifies the action (create) and resource (booking), though it doesn't explicitly differentiate from sibling tools like 'create_booking_request' beyond the 'verified customer' scope. The description is specific but could better distinguish from similar 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 description provides explicit usage guidelines: 'Use after verification, detail collection, and confirmed paid payment session.' This clearly indicates prerequisites and timing, helping the agent understand when to invoke this tool versus alternatives like 'start_booking_payment' or 'create_booking_request'. It effectively guides usage in the workflow context.

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 are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool helps 'identify' services, implying a read-only lookup, but doesn't describe what the tool returns (e.g., a list of services, recommendations), any rate limits, authentication needs, or error conditions. For a tool with zero annotation coverage, this leaves significant gaps in understanding its 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?

The description is a single, well-structured sentence that efficiently conveys the tool's purpose and usage context. It's front-loaded with the key information and has no wasted words, making it easy to parse quickly.

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 complexity (3 parameters, no annotations, no output schema), the description is incomplete. It lacks details on parameter usage, return values, and behavioral traits like error handling or performance. While it sets a clear context, it doesn't provide enough information for an agent to confidently invoke the tool without guessing.

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 description coverage is 0%, meaning none of the three parameters (area, query, urgency) are documented in the schema. The description doesn't add any meaning about these parameters—it doesn't explain what 'area' refers to, what 'query' should contain, or how 'urgency' affects the results. With low coverage and no compensation in the description, this is inadequate.

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: 'identifying which TaskMan of London service fits their job.' It specifies the domain (home-service requests in London) and target use case (vague requests). However, it doesn't explicitly differentiate from siblings like 'list_service_types' or 'match_providers,' which might offer similar functionality.

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 explicit guidance on when to use this tool: 'when the user needs help identifying which TaskMan of London service fits their job, especially for vague home-service requests in London.' This gives clear context for application. However, it doesn't specify when NOT to use it or name alternatives among siblings, which could help avoid misuse.

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 are provided, so the description carries the full burden. It states the tool checks payment status but doesn't disclose behavioral traits like authentication requirements, rate limits, error handling, or what happens if the session is invalid. For a tool with no annotation coverage, this leaves significant gaps in understanding its 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?

The description is a single, efficient sentence that front-loads the core purpose and usage context. Every word earns its place, with no redundancy or unnecessary details, making it highly concise and well-structured.

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 complexity (payment status checking), no annotations, no output schema, and low parameter coverage, the description is incomplete. It doesn't explain the return values (e.g., what 'pending' means), error cases, or dependencies, leaving the agent with insufficient context for reliable use.

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 compensate for undocumented parameters. It mentions 'session_token' and 'payment_session_id' implicitly but doesn't explain their meaning, format, or how they relate to the payment session. With 2 parameters and no schema descriptions, this adds minimal value beyond what the schema provides.

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: 'check whether a booking payment session is pending, paid, failed, canceled, or expired.' It specifies the verb ('check') and resource ('booking payment session'), and distinguishes it from booking creation tools. However, it doesn't explicitly differentiate from the sibling 'get_booking_status' tool, which might have overlapping functionality.

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 for when to use this tool: 'before attempting booking creation.' This implies it should be used as a prerequisite check. It doesn't specify when NOT to use it or name explicit alternatives among siblings, but the context is sufficient for basic 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. While it implies a read-only operation (getting an update), it doesn't specify whether this requires authentication, what data is returned, error conditions, or rate limits. For a tool with no annotation coverage, this leaves significant behavioral gaps, though it doesn't contradict any 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?

The description is a single, efficient sentence that front-loads the usage context. It wastes no words and directly addresses the tool's purpose and when to invoke it, making it easy for an agent to parse quickly.

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 complexity (3 parameters, no output schema, no annotations), the description is incomplete. It adequately states purpose and usage but lacks parameter explanations, return value details, or behavioral traits like authentication needs. For a tool with undocumented parameters and no structured output, this leaves too many gaps for reliable agent use.

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%, meaning none of the three parameters (booking_request_id, email, phone) are documented in the schema. The description provides no information about these parameters—it doesn't explain what booking_request_id is, why email or phone might be needed, or their relationships. This fails to compensate for the lack of schema documentation.

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: to provide an update on an existing booking request. It specifies the verb ('get an update') and resource ('TaskMan booking request'), making it distinct from creation tools like 'create_booking_request'. However, it doesn't explicitly differentiate from similar status-checking siblings like 'get_booking_payment_status', which slightly reduces clarity.

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 explicitly states when to use this tool: 'when the user already has a TaskMan booking request and wants an update.' This provides clear context for invocation, distinguishing it from tools for creating bookings or checking availability. It effectively guides the agent to use this only for existing requests, not new ones.

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 are provided, so the description carries the full burden. It mentions 'after verification' as a prerequisite, which adds some behavioral context. However, it lacks details on permissions, rate limits, error handling, or what the output looks like (e.g., availability slots, timeframes). For a tool with no annotations, this is insufficient.

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, efficient sentence that front-loads key information: usage context and purpose. There is no wasted text, and it's 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 no annotations, 0% schema description coverage, 5 parameters, and no output schema, the description is incomplete. It lacks details on parameters, behavioral traits, and output format. For a tool that likely returns availability data, this leaves significant gaps for an AI agent.

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 compensate. It mentions 'verified customer' and 'selected saved address', which loosely relate to 'session_token' and 'address_id', but doesn't explain any parameters explicitly. With 5 parameters (2 required) and no schema descriptions, the description adds minimal semantic value beyond vague hints.

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: 'check availability for a verified customer at a selected saved address.' It specifies the verb ('check availability'), resource ('verified customer'), and context ('selected saved address'). However, it doesn't explicitly differentiate from sibling tools like 'check_availability' or 'check_service_area', which prevents a perfect score.

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 some usage context: 'Use after verification to check availability.' This implies a prerequisite (verification) but doesn't specify when to use this tool versus alternatives like 'check_availability' or 'check_service_area'. No explicit exclusions or detailed alternatives are mentioned, leaving gaps in 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'scoped' details and 'after verification,' which hints at security constraints, but doesn't specify what 'scoped' means, whether it's read-only, what data is returned, or any rate limits. For a tool accessing customer data with no annotations, this is insufficient.

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: 'Use after verification to load scoped customer profile details from CRM for booking.' It's front-loaded with usage guidance and purpose, with zero wasted words, making it highly efficient.

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 no annotations, no output schema, and 1 parameter with 0% schema coverage, the description is incomplete. It covers purpose and usage context but lacks details on behavior, return values, and parameter meaning. For a tool in a CRM/booking system, this leaves significant gaps.

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 has 1 parameter with 0% description coverage. The description doesn't mention the 'session_token' parameter at all, so it adds no semantic value beyond the schema. However, with only 1 parameter, the baseline is 4, but since the description fails to explain its purpose or usage, it's scored lower at 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 clearly states the tool's purpose: 'load scoped customer profile details from CRM for booking.' It specifies the action (load), resource (customer profile details), and context (CRM for booking). However, it doesn't explicitly differentiate from siblings like 'get_customer_availability' or 'list_customer_addresses,' which prevents a perfect score.

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 usage context: 'Use after verification to load scoped customer profile details.' This indicates when to use it (post-verification) and implies it's for accessing customer data in a booking context. It doesn't explicitly state when not to use it or name alternatives, 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?

No annotations are provided, so the description carries the full burden. It mentions the tool is for cost estimates, but doesn't disclose behavioral traits such as whether it's a read-only operation, if it requires authentication, rate limits, what the output looks like (e.g., price range, custom quote flag), or any side effects. This is a significant gap for a tool with 9 parameters and no output schema.

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, efficient sentence that directly states the usage context without unnecessary words. It's appropriately sized and front-loaded, making it easy to understand quickly.

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 complexity (9 parameters, no annotations, no output schema), the description is incomplete. It covers usage context but lacks details on behavior, parameters, and output. For a tool that likely returns cost estimates, more information is needed to guide the agent effectively, especially with no structured fields to compensate.

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 description provides no information about parameters, and the schema description coverage is 0% (no parameter descriptions in the schema). With 9 parameters (including required ones like 'service_type' and 'task_summary'), the description fails to add any meaning beyond what the bare schema provides, such as explaining what 'brand' or 'postcode' are used for in the context of quotes.

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 the tool is used 'when the user asks about likely cost, ballpark pricing, or whether a task needs a custom quote,' which indicates it provides cost estimates. However, it's vague about what exactly the tool does (e.g., whether it returns a price range, a yes/no for custom quotes, or detailed breakdowns) and doesn't specify the resource or output clearly. It distinguishes from some siblings (e.g., 'create_booking_request') but not all (e.g., 'find_services' might also relate to pricing).

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 explicitly states when to use it: 'when the user asks about likely cost, ballpark pricing, or whether a task needs a custom quote.' This provides clear context for usage. However, it doesn't mention when not to use it or name specific alternatives among siblings (e.g., 'check_availability' or 'find_services' might be related but not directly addressed), so it falls short of a perfect score.

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 are provided, so the description carries the full burden of behavioral disclosure. While it mentions the prerequisite of verification, it doesn't describe what the tool actually returns (e.g., format of addresses, pagination, error handling), whether it's read-only or has side effects, or any rate limits or authentication requirements beyond the session_token parameter. This leaves significant gaps in understanding the tool's 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?

The description is a single, efficient sentence that front-loads the key information (usage context and purpose) with zero wasted words. Every part of the sentence earns its place by contributing essential 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 the tool's complexity (listing customer data with a verification prerequisite), lack of annotations, no output schema, and low parameter schema coverage, the description is incomplete. It misses critical details like return format, error conditions, and parameter semantics, making it inadequate for reliable agent use without additional context.

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 has 1 parameter with 0% description coverage, meaning the schema provides no semantic information about 'session_token'. The description doesn't add any meaning to this parameter—it doesn't explain what a session_token is, how to obtain it, or its role in the verification context mentioned. This fails to compensate for the low schema coverage.

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 ('list') and resource ('saved addresses linked to the verified customer'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate this tool from potential sibling tools like 'get_customer_profile' or 'tag_contact' that might also handle customer data, which prevents a perfect score.

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 explicit context for when to use this tool ('Use after verification'), which is helpful guidance. However, it doesn't specify when NOT to use it or mention alternatives among the sibling tools (e.g., when to use this versus 'get_customer_profile'), leaving some ambiguity about tool 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool is used 'after verification' and 'before collecting booking details,' implying it's a read operation, but does not disclose critical traits like authentication needs (only implied via 'session_token'), rate limits, error handling, or output format. The description adds minimal context beyond basic usage timing.

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, efficient sentence that is front-loaded with key information (usage context and purpose). There is no wasted text, and it directly communicates the essential details without redundancy or unnecessary elaboration.

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 complexity (1 parameter, no annotations, no output schema), the description is incomplete. It covers usage timing but lacks details on authentication, output format, error conditions, and parameter semantics. For a tool with no structured support, it should provide more comprehensive guidance to be fully actionable.

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 has 1 parameter with 0% description coverage, and the description does not add any meaning about the 'session_token' parameter. It fails to explain what the token is, how to obtain it, or its role in the operation. With low schema coverage, the description does not compensate, leaving the parameter undocumented.

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 the tool's purpose as 'show supported service types before collecting booking details,' which is clear but vague. It specifies the action ('show') and resource ('supported service types') but lacks specificity about what 'supported' means or how the list is structured. It does not distinguish from siblings like 'find_ervices' or 'check_service_area,' which might have overlapping functions.

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 explicit guidance on when to use the tool: 'Use after verification to show supported service types before collecting booking details.' This clearly indicates the context (post-verification, pre-booking details) and sequence, though it does not specify alternatives or exclusions, such as when to use 'find_services' instead.

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 key behavioral traits: the tool returns an ordered list of candidates, the first with 'can_assign=true' is the assignee, and it's deterministic. However, it lacks details on permissions, rate limits, error handling, or whether it's read-only vs. mutative, leaving gaps for a matching 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?

The description is front-loaded with the usage scenario, followed by the return value explanation. Both sentences are essential: the first sets context, the second details the output structure. There is zero waste, making it highly efficient and well-structured.

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 no annotations and no output schema, the description partially compensates by explaining the return format ('ordered_candidates array') and assignment logic. However, for a 5-parameter tool with 0% schema coverage, it lacks details on input semantics, error cases, or side effects, making it incomplete for full contextual understanding.

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 compensate. It mentions no parameters directly, but implies usage for 'assignment' with inputs like service type and location. However, it doesn't explain parameter meanings (e.g., what 'urgency' levels entail or how 'area_postcode' affects matching), leaving significant gaps despite the schema's enum hints.

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: to return a deterministic provider-matching result for assignment. It specifies the verb ('match'), resource ('providers'), and outcome ('ordered_candidates array sorted best-to-worst'), distinguishing it from siblings like 'check_availability' or 'find_services' by focusing on assignment decisions rather than general availability or service listings.

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 explicitly states when to use this tool: 'when an agent needs a single deterministic provider-matching result for assignment.' This provides clear context for its application, distinguishing it from alternatives like 'check_availability' (which might check slots without matching) or 'create_booking_request' (which initiates booking).

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 are provided, so the description carries the full burden of behavioral disclosure. It mentions creating a payment session but doesn't disclose critical traits like whether this is a read-only or destructive operation, authentication requirements, rate limits, or what happens on success/failure. For a payment-related tool with zero annotation coverage, this is a significant gap in transparency.

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 efficiently conveys the tool's purpose and usage context without any wasted words. It's appropriately sized and front-loaded with the key 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?

Given the complexity of a payment tool with 7 parameters, 0% schema coverage, no annotations, and no output schema, the description is incomplete. It lacks details on behavioral traits, parameter meanings, return values, and error handling. This makes it inadequate for safe and effective tool invocation in a real-world scenario.

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%, meaning none of the 7 parameters are documented in the schema. The description doesn't add any parameter semantics—it doesn't explain what 'session_token,' 'service_type,' or other parameters mean or how they should be used. This leaves the agent with no guidance on parameter usage beyond the raw schema structure.

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: 'to create a Stripe checkout payment session before final booking submission.' It specifies the action (create), resource (Stripe checkout payment session), and context (before final booking submission). However, it doesn't explicitly differentiate from sibling tools like 'create_booking_request' or 'get_booking_payment_status,' which would require more specific comparison.

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 for when to use the tool: 'Use after collecting booking details.' This gives the agent a prerequisite condition. However, it doesn't specify when NOT to use it or mention alternatives among the sibling tools, such as when to use 'create_booking_request' instead, which limits the 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?

No annotations are provided, so the description carries the full burden. It mentions the action ('verify identity') and methods (OTP/magic link) but lacks critical behavioral details: whether this sends notifications, requires specific permissions, has rate limits, what happens on success/failure, or if it's idempotent. For a security-sensitive verification tool with zero annotation coverage, this is a significant gap in transparency.

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, efficient sentence that front-loads the key information: use case, action, and purpose. Every word earns its place with no redundancy or fluff. It's 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 complexity (security-sensitive verification with 3 parameters), no annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like what the tool returns, error conditions, side effects (e.g., sending SMS/email), or prerequisites. For a tool that initiates customer verification, more context about the workflow and outcomes is needed.

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 compensate for undocumented parameters. It mentions 'OTP or magic link' which relates to 'method_preference', and 'customer' implies 'identifier', but doesn't explain what 'identifier' represents (email? phone? customer ID?) or the meaning of 'auto' defaults. With 3 parameters (1 required, 2 with enums) and no schema descriptions, the description adds minimal semantic value beyond what's inferable from parameter names.

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 purpose: 'verify identity (OTP or magic link) before assistant-led booking' with a specific verb ('verify') and resource ('customer identity'). It distinguishes from siblings like 'verify_customer_otp' and 'verify_magic_link_token' by being the initiation step rather than verification of received codes. However, it doesn't explicitly mention it's for 'existing' customers as stated, which slightly reduces specificity.

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: 'when an existing customer wants to verify identity... before assistant-led booking.' This indicates when to use it (pre-booking verification) and implicitly distinguishes from tools like 'create_booking_request' or 'start_booking_payment' that handle later stages. However, it doesn't explicitly state when NOT to use it or name alternatives like the sibling verification tools for completing the process.

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 behavioral disclosure. It mentions the session is 'short-lived' and 'without OTP', which adds useful context beyond basic functionality. However, it lacks details on authentication needs, rate limits, error conditions, or what 'short-lived' entails (e.g., duration), leaving gaps in behavioral understanding for a tool that likely involves security and session management.

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 efficiently conveys the tool's purpose, context, and key behavioral trait ('short-lived booking session without OTP'). It is front-loaded with essential information and has no wasted words, making it highly concise and effective.

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 complexity of a session-starting tool with no annotations and no output schema, the description is incomplete. It covers the 'what' and 'when' but lacks details on behavioral aspects (e.g., session duration, error handling) and output (what the session returns). While it provides a good foundation, it does not fully address the tool's context, especially for a security-sensitive operation.

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 has 1 parameter with 0% description coverage, so the description must compensate. It does not mention the 'identifier' parameter at all, providing no semantic meaning beyond what the schema indicates (a string with length constraints). The baseline is 3 because the schema coverage is low, but the description fails to add value for the parameter, resulting in a minimal adequate 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 clearly states the tool's purpose: 'start a short-lived booking session without OTP' in 'trusted telephony flows' when the 'caller number is already verified by the channel provider'. It specifies the verb ('start'), resource ('trusted phone session'), and context, but does not explicitly differentiate it from sibling tools like 'start_customer_verification' or 'verify_customer_otp', which prevents a score of 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?

The description provides clear context for when to use the tool: 'in trusted telephony flows when the caller number is already verified by the channel provider and you need a short-lived booking session without OTP'. This implies usage scenarios and prerequisites, but it does not explicitly state when not to use it or name alternatives (e.g., 'verify_customer_otp' for OTP-based flows), so it falls short of a perfect score.

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 behavioral disclosure. It mentions 'add CRM tags' (implying a write operation) but doesn't cover permissions, side effects, error handling, or response format. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.

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, efficient sentence that states the purpose upfront. It avoids redundancy and wastes no words, though it could be slightly more structured for clarity.

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 mutation tool with 2 parameters, 0% schema coverage, no annotations, and no output schema, the description is inadequate. It lacks details on parameters, behavioral traits, error cases, and output, leaving the agent with insufficient context to use the tool effectively.

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 compensate. It mentions 'tags' and 'verified customer' (implied via 'session_token'), but doesn't explain parameter meanings, constraints (e.g., tag length limits, session token purpose), or relationships. The description adds minimal value beyond the bare 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 clearly states the action ('add CRM tags') and target ('verified customer'), specifying it's for 'booking workflow tracking'. It distinguishes from siblings like 'update_contact_note' by focusing on tags rather than notes, though it doesn't explicitly contrast with all 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?

The description provides minimal guidance: it implies usage for 'booking workflow tracking' but doesn't specify when to use this tool versus alternatives like 'update_contact_note' for notes or other customer-related tools. No explicit when-not-to-use or prerequisite information is given.

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 are provided, so the description carries the full burden of behavioral disclosure. It mentions that the note is 'internal' and for 'verified customers,' which adds some context about privacy and prerequisites. However, it lacks details on permissions, rate limits, error handling, or what happens if the customer is not verified, leaving significant gaps for a mutation 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?

The description is a single, efficient sentence that is front-loaded with the tool's purpose. There is no wasted text, and it directly communicates the core functionality without unnecessary elaboration.

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 tool's complexity as a mutation operation with no annotations, 0% schema description coverage, and no output schema, the description is incomplete. It misses critical details like authentication via 'session_token,' the note's impact on the CRM, error scenarios, and response format, making it inadequate for safe and effective use.

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 compensate for undocumented parameters. It does not explain the 'session_token' parameter at all, and for 'note,' it only implies it's for CRM notes without detailing format, content guidelines, or how it relates to booking. This fails to add sufficient meaning beyond the basic schema constraints.

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: 'append an internal CRM note for the verified customer during or after booking.' It specifies the verb ('append'), resource ('internal CRM note'), and target ('verified customer'), but does not explicitly differentiate it from sibling tools like 'tag_contact' or other customer-related 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?

The description provides implied usage context by mentioning 'during or after booking' and 'verified customer,' which suggests when to use it. However, it does not explicitly state when not to use it or name alternatives, such as when to use 'tag_contact' instead for non-note annotations.

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 are provided, so the description carries the full burden of behavioral disclosure. It mentions that verification 'open[s] a short-lived booking session,' which adds useful context about the outcome. However, it lacks details on permissions, error handling, rate limits, session duration, or what happens if verification fails. For a security-critical tool with zero annotation coverage, this is a significant gap.

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 efficiently conveys the tool's purpose and usage context. It is front-loaded with the key action ('verify') and includes no redundant information, making it highly concise and effective.

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 tool's complexity (security verification with session creation), lack of annotations, and no output schema, the description is incomplete. It covers the basic purpose and usage sequence but omits critical details like error responses, session lifetime, or side effects. This is adequate for a minimal viable description but has clear gaps.

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 compensate. It implies the parameters are related to an OTP challenge (challenge_id and otp_code) but doesn't explain their meanings, formats, or relationships beyond what the schema's pattern and length constraints provide. The description adds minimal semantic value, resulting in a baseline score of 3 due to the low coverage.

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: 'verify the one-time passcode and open a short-lived booking session.' It specifies the verb (verify) and resource (OTP), and distinguishes it from siblings like 'start_customer_verification' or 'verify_magic_link_token' by focusing on OTP verification. However, it doesn't explicitly mention the resource 'customer' from the tool name, making it slightly less specific than a perfect 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?

The description provides clear context for when to use this tool: 'Use after sending an OTP challenge.' This implies a prerequisite and sequence, distinguishing it from alternatives like 'start_customer_verification' (which might initiate the challenge) or 'verify_magic_link_token' (which uses a different method). However, it doesn't explicitly state when not to use it or name alternatives, preventing a score of 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the action of verification but doesn't describe what happens upon success or failure, whether it's idempotent, if it requires specific permissions, or any rate limits. For a verification tool with zero annotation coverage, this leaves significant gaps in understanding the tool's 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?

The description is a single, efficient sentence that directly states the tool's purpose and usage context. It is front-loaded with no unnecessary words, making it easy to parse and understand quickly. Every part of the sentence contributes essential 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?

Given the tool's complexity (a verification action with 1 parameter), no annotations, and no output schema, the description is minimally adequate. It covers the basic purpose and usage but lacks details on behavioral outcomes, error handling, or return values. This leaves the agent with incomplete context for reliable 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?

The input schema has 1 parameter with 0% description coverage, so the schema provides no semantic information. The description adds value by explaining that the token is provided by the customer after clicking a magic link, giving context to the parameter. However, it doesn't detail the token format or validation rules, leaving some ambiguity.

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 as verifying a magic link token when a customer clicks it. It specifies the verb 'verify' and the resource 'magic link token', making the action explicit. However, it doesn't differentiate from sibling tools like 'verify_customer_otp', which handles OTP verification instead of magic links.

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 explicitly states when to use this tool: 'Use when the customer clicks a magic link and provides the token for verification.' This provides clear context and timing, distinguishing it from alternatives like OTP verification tools. It effectively guides the agent on the specific scenario for invocation.

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