TaskMan of London

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

With no annotations provided, the description carries full burden for behavioral disclosure but offers almost nothing. The word 'likely' hints at probabilistic results, but there is no information on return format, caching, rate limits, or whether this operation is read-only.

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 words. It efficiently communicates the usage trigger, though at the cost of omitting other necessary details.

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 tool with 4 parameters (2 required), 0% schema coverage, no output schema, and no annotations, the description is insufficient. It lacks return value documentation, parameter details, and behavioral constraints needed for an agent to use this 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%, requiring the description to compensate, yet it fails to document any parameters explicitly. While 'dates' and 'timing' implicitly map to preferred_date and time_preference, the required 'postcode' parameter and specific enum values for service_type are entirely unmentioned.

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 frames the tool's purpose as 'whether a service can likely be booked soon,' which essentially restates the tool name 'check_availability' without specifying what data it returns (availability slots, dates, boolean). It describes trigger conditions rather than the tool's actual function.

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 trigger conditions. However, it fails to mention alternatives like 'get_customer_availability' or 'check_service_area' for different availability contexts.

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 disclosure burden. It adds valuable geographic scope context ('London postcode') not present in the schema, but fails to disclose return value format, error handling behavior, or whether this is a read-only operation versus a logged query.

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?

Single sentence with no redundant words or fluff. However, the 'Use when...' structure prioritizes triggering conditions over functional definition, and the extreme brevity contributes to the incomplete parameter documentation.

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 zero schema descriptions and no output schema, the description should comprehensively document both parameters. It provides geographic context for postcode but fails to mention service_type at all, creating a significant documentation gap for a tool with only two parameters.

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 0% description coverage, requiring the description to compensate. While 'London postcode' provides semantic context for the required postcode parameter, the description completely omits the optional service_type parameter and its five enum values (furniture_assembly, electrician, etc.), leaving half the parameter set 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 implies the purpose (checking geographic coverage) through usage triggers ('asks whether TaskMan covers their area'), but frames it conditionally ('Use when...') rather than with an explicit action verb like 'Verify' or 'Check'. It distinguishes from siblings like check_availability by mentioning 'London postcode' and 'area', but lacks a direct functional statement.

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 'when to use' triggers ('when the user provides a London postcode' or 'asks whether TaskMan covers their area'). However, it lacks 'when not to use' guidance or explicit mentions of sibling alternatives like find_services or check_availability for different use cases.

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 the description carries full disclosure burden for this write operation. It fails to mention side effects (notifications sent, provider matching triggered), reversibility, or what makes a booking 'real' versus tentative. The presence of 'idempotency_key' parameter suggests retry-safety concerns that the description doesn't address.

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?

Extremely concise single sentence (13 words) with no redundancy. Front-loaded with conditional trigger ('Use when...'). However, for a 12-parameter mutation tool with zero schema documentation, this brevity represents underspecification rather than efficient communication.

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?

Inadequate for tool complexity (12 params, 6 required, write operation, no output schema). Missing: parameter guidance, distinction from booking creation alternatives, explanation of the submission workflow, or post-creation behavior. The 'real' qualifier suggests business logic implications that remain unexplained.

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 0% description coverage across 12 parameters, requiring the description to compensate. It mentions 'submit details' generically but doesn't explain required fields (customer_name, consent_to_contact), valid service_type values, or the purpose of idempotency_key. Marginally better than tautology but insufficient for the complexity.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States the basic action (submit details for a booking request) and identifies the specific entity (TaskMan of London), but fails to distinguish from sibling tool 'create_customer_booking'. The word 'real' hints at a distinction but doesn't clarify the difference between these similar creation 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?

Provides timing guidance ('when the user is ready'), indicating prerequisites are expected. However, it lacks explicit alternatives or exclusions—critical given the similar sibling 'create_customer_booking'—and doesn't state when NOT to use this versus other booking-related tools.

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 critical prerequisites (verification and payment required) but omits mutation side effects, idempotency behavior (despite having an idempotency_key parameter), error conditions, or notification triggers.

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?

Single, efficient sentence of 19 words with zero redundancy. Prerequisites are front-loaded, and every phrase contributes to understanding the tool's position in the workflow.

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?

Inadequate for an 11-parameter mutation tool with complex business logic. No output schema, no annotations, and 0% parameter documentation means the description should explain parameter relationships, return values, or error scenarios—it provides none of these.

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%, requiring the description to compensate. It implicitly references 'session_token' and 'payment_session_id' via workflow prerequisites, but leaves 9 other parameters (including required fields 'service_type' and 'task_summary') completely 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?

Clearly states the action ('create a booking') and scope ('scoped to the verified customer'), distinguishing it as a customer-specific operation. However, it does not explicitly differentiate from sibling 'create_booking_request'.

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 prerequisites ('Use after verification, detail collection, and confirmed paid payment session'), establishing clear workflow sequencing. Lacks explicit contrast with alternative tools like 'create_booking_request'.

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 full burden for behavioral disclosure. It fails to mention what the tool returns (service recommendations? categories? matches?), whether it performs fuzzy matching, or any constraints like rate limits. It only describes the invocation trigger, not the tool's behavior or side effects.

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?

Single sentence with zero redundancy. Front-loaded with conditional 'Use when...' putting the trigger condition first. However, given the lack of schema documentation and output schema, the description is arguably too concise and under-specified for the complexity of the task.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With zero schema descriptions, no annotations, and no output schema, the description should explain what the tool returns and parameter semantics. Currently it only covers invocation triggers. Missing: return value description, parameter details, and behavioral constraints necessary for a discovery tool with 3 parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% with three undocumented parameters. The description only implicitly hints at 'query' (vague requests) and 'area' (London) through usage context but provides no guidance on the 'urgency' enum or expected formats for area/query. Insufficient compensation for the complete lack of schema descriptions.

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 identifies which TaskMan of London service fits the user's job, with specific context about 'vague home-service requests.' It distinguishes from booking-oriented siblings (create_booking_request, get_quote_estimate) by focusing on service discovery rather than transaction. However, it doesn't explicitly state what output to expect (recommendations vs. list).

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 trigger conditions: 'Use when the user needs help identifying... especially for vague home-service requests in London.' This clearly signals when to invoke the tool versus direct booking tools. Lacks explicit 'when not to use' guidance or comparison to list_service_types, which appears to be a sibling with similar functionality.

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 effectively discloses the possible return statuses (pending, paid, failed, canceled, expired) which is crucial behavioral information. However, it omits other traits like idempotency, caching behavior, or what actions to take based on each status.

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?

Single, well-structured sentence that is front-loaded with the action ('Use to check'). Every clause earns its place: the resource type, the enumerated statuses, and the workflow prerequisite. No redundancy or filler words.

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 output schema, listing the possible statuses provides essential behavioral context. However, with two required parameters having zero schema documentation, the description's failure to explain these inputs creates a significant gap. Adequate but incomplete for a tool requiring specific IDs.

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%, requiring the description to compensate. While it mentions 'payment session' (contextualizing payment_session_id), it fails to explain what 'session_token' represents or the relationship between the two parameters. This leaves critical input semantics 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?

Clearly states the tool checks a booking payment session's status, explicitly listing five possible states (pending, paid, failed, canceled, expired). The mention of 'payment session' distinguishes it from the sibling 'get_booking_status', though it doesn't explicitly contrast with 'start_booking_payment'.

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 workflow timing ('before attempting booking creation'), implying it should be used after starting payment but before creating the booking. However, it lacks explicit 'when not to use' guidance or direct comparison to siblings like 'start_booking_payment' or 'get_booking_status'.

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 but offers minimal information. It does not describe what status information is returned, error conditions for invalid booking_request_id values, authentication requirements, or whether this operation is idempotent.

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 concise sentence (12 words) that is appropriately front-loaded with the usage condition. However, the brevity comes at the cost of omitting critical information about the tool's behavior and parameters, making it under-informative rather than efficiently concise.

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 complex booking domain (17 sibling tools), lack of output schema, 0% parameter documentation, and no annotations, the description is insufficient. It fails to explain what status data is returned, how to handle the optional identification parameters (email/phone vs ID), or what distinguishes this from get_booking_payment_status.

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%, requiring the description to compensate for undocumented parameters. The description fails to explain the three parameters (booking_request_id, email, phone), their relationships, or why email and phone are optional when booking_request_id is required. No parameter syntax, validation rules, or usage patterns are provided.

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 implies the tool retrieves status updates for existing TaskMan bookings, but uses indirect phrasing ('wants an update') rather than stating explicitly what the tool returns. It differentiates from siblings by mentioning 'TaskMan booking request,' though the actual action (retrieve/fetch/get) is not clearly articulated.

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 a clear 'when to use' condition ('when the user already has a TaskMan booking request'), implicitly distinguishing it from create_booking_request. However, it lacks explicit 'when not to use' guidance and fails to differentiate from closely related siblings like get_booking_payment_status or check_availability.

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 verification prerequisite and saved address requirement, but omits details on return format, error conditions for unverified sessions, or rate limiting.

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?

Single sentence, efficiently front-loaded with workflow context. No redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 5-parameter booking tool with no output schema or annotations, the description is insufficient. It omits return value structure, error handling, and fails to fully compensate for the complete lack of schema documentation on 3 of 5 parameters.

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 0% description coverage. The description indirectly provides semantics for 'session_token' (from verification) and 'address_id' (saved address), but offers no guidance on 'preferred_date' format, 'time_preference' options, or 'service_type' values despite having no schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States the core action (check availability) and scope (verified customer, saved address), but does not explicitly distinguish from sibling tool 'check_availability' which appears to 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?

Provides sequencing guidance ('Use after verification'), implying prerequisite workflow steps, but lacks explicit when-not-to-use guidance or comparison to alternative tools like 'check_availability'.

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 establishes the data source ('CRM') and security context ('after verification'), implying read-only access. However, it fails to explain what 'scoped' means (field limitations, privacy restrictions), error conditions when verification is missing, or whether the operation is idempotent.

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 single-sentence structure is appropriately compact and front-loaded with the critical prerequisite condition ('Use after verification'). Every word serves a purpose, though 'scoped' introduces slight ambiguity without additional context. The efficiency is appropriate for a single-parameter tool.

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 simplicity (one parameter) but lack of annotations and output schema, the description adequately covers the business workflow context (verification → profile retrieval → booking). However, it is incomplete regarding technical implementation details: what constitutes 'scoped' data, the session_token parameter details, and expected return 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?

The schema has 0% description coverage, requiring the description to compensate for the undocumented 'session_token' parameter. While 'after verification' implicitly hints at the token's origin, the description never explicitly names the parameter, describes its format (20-300 char string), or explains it represents an authenticated session. This gap forces the agent to infer parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool loads customer profile details from a CRM system for booking purposes, with specific verbs ('load') and resource ('customer profile details'). It distinguishes itself from sibling address/listing tools by focusing on profile retrieval. However, the term 'scoped' is vague and doesn't specify exactly what data fields are returned.

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 temporal guidance with 'Use after verification,' establishing a clear prerequisite workflow that distinguishes it from verification tools like verify_customer_otp or start_customer_verification. However, it lacks explicit 'when-not-to-use' guidance or named alternatives (e.g., when to use list_customer_addresses 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 of behavioral disclosure but fails to mention read/write nature, rate limits, or return value structure. The only behavioral hint is 'whether a task needs a custom quote,' suggesting possible non-numeric returns, but this is insufficient for a 9-parameter 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?

Single sentence, efficiently front-loaded with no redundancy. However, given the high parameter count and lack of schema documentation, the brevity borders on under-specification rather than optimal conciseness.

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 tool with 9 undocumented parameters, no output schema, and no annotations, the description is inadequate. It covers the usage trigger but omits parameter explanations, return value descriptions, and error conditions necessary for correct 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 description coverage is 0% across 9 parameters. The description compensates minimally by implying 'task' (task_summary) and service context, but provides no explicit parameter guidance, types, or constraints beyond what the schema structure 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 implies the tool provides cost estimates through usage conditions ('likely cost, ballpark pricing'), but never explicitly states what the tool returns or accomplishes (e.g., 'Returns a price estimate'). It uses 'Use when...' rather than declaring the action, leaving the actual purpose vague.

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 when-to-use guidance ('Use when the user asks about...'), clearly signaling the user intents that should trigger this tool (cost inquiries vs bookings). However, it lacks when-NOT-to-use guidance or explicit sibling distinctions (e.g., vs create_booking_request).

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 discloses the authentication state requirement ('after verification') but lacks details on safety (read-only status), rate limits, error conditions, or pagination behavior for the address list.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise single sentence (12 words) with zero redundancy. The prerequisite ('Use after verification') is front-loaded, immediately establishing the necessary context before stating the action.

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 single-parameter listing tool without output schema, the description adequately covers the essential workflow positioning and action. It appropriately leverages the tool name for the core function, though explicit mention of the session_token parameter would strengthen completeness given the lack of schema descriptions.

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%, requiring the description to compensate. It implicitly maps to the session_token parameter by referencing 'verification' and 'verified customer,' providing semantic context that the token represents a verified session. However, it does not explicitly name the parameter or describe its format requirements.

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 saved addresses') and the scope ('linked to the verified customer'). It effectively distinguishes this from a hypothetical unverified address lookup by emphasizing the 'verified' aspect, though it relies on context from sibling verification tools to fully clarify the verification 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 temporal guidance ('Use after verification') establishing a clear prerequisite workflow. While it doesn't explicitly name alternatives for unverified scenarios, the prerequisite statement effectively signals when the tool is appropriate.

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 the description carries full disclosure burden. It implies an authentication requirement via 'after verification' but does not confirm read-only behavior, describe return values (list of strings vs objects), error states (invalid token), or side effects. The prerequisite context is the only behavioral trait disclosed.

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?

Single sentence with no redundant words. The workflow-first structure ('Use after...') slightly obscures the pure functional purpose but remains efficient. Every clause provides necessary sequencing or functional context.

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?

Adequate for a single-parameter tool without output schema. The description covers the critical workflow prerequisite (verification) but lacks detail on what 'service types' represent (categories, IDs, labels) or the response structure. Minimum viable for the complexity level.

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 0% description coverage for the session_token parameter. The description mentions 'verification' which implicitly contextualizes the token's origin, but it does not explicitly describe the parameter's purpose, format, or how it relates to the verification flow. Insufficient compensation for the schema gap.

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 'show[s] supported service types,' which clearly identifies the verb (show/list) and resource (service types). It distinguishes from siblings like create_booking_request or check_availability by focusing on cataloging available types rather than executing bookings or checks.

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 positions the tool in the workflow: 'Use after verification' and 'before collecting booking details.' This temporal guidance helps the agent sequence calls correctly relative to verify_customer_otp and create_booking_request, though it lacks explicit 'when not to use' exclusions.

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

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

With no annotations and no output schema, the description carries the full burden of explaining behavior. It successfully documents the return structure ('ordered_candidates array sorted best-to-worst') and assignment logic ('first can_assign=true candidate'), but fails to disclose whether this is a read-only operation or creates side effects/matches in the system.

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 total with zero waste: the first establishes usage context and purpose, the second explains output format. Every word earns its place and the description is appropriately front-loaded.

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 output schema, the description adequately explains the return value structure. However, with 0% parameter schema coverage, the lack of parameter guidance in the description creates a significant gap. It meets minimum viability for invocation but requires inference for parameter semantics.

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 the description must compensate for undocumented parameters. However, it provides no explanation of the 5 parameters (service_type, area_postcode, urgency, location_id, preferred_date) or their relationships, leaving critical gaps in how to populate the required fields.

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 performs 'provider-matching result for assignment' with a 'deterministic' result, distinguishing it from browsing tools like 'find_services'. It specifies the core resource (providers) and action (matching for assignment).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides a 'Use when...' condition indicating the specific scenario (needing a single deterministic assignment result), but lacks explicit guidance on when NOT to use it or which sibling tools to use instead for non-assignment scenarios like general browsing.

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 successfully identifies the external dependency (Stripe) and clarifies this does not finalize the booking. However, it omits critical behavioral details for a payment tool: return value format (likely a checkout URL), session lifecycle, idempotency guarantees, and error handling patterns.

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?

Extremely efficient single sentence (17 words) that front-loads the usage trigger ('Use after...') and packs in the action, external service, and workflow positioning. Zero redundancy; every word 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 high-stakes payment tool with 7 undocumented parameters (0% schema coverage), no output schema, and no annotations, the description is insufficient. It fails to explain the output (critical for redirect flows), the relationship between the returned session and subsequent booking confirmation, or parameter validation rules.

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 across 7 parameters, the description fails to compensate adequately. While 'collecting booking details' vaguely implies the parameter purpose, it provides no semantic clarity on specific fields like 'session_token' (auth token vs. Stripe session?), 'deposit_amount_minor' (currency units?), or 'contact_id' selection criteria.

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 creates a 'Stripe checkout payment session' and positions it within the booking workflow ('before final booking submission'). However, it could more explicitly distinguish this pre-payment step from sibling tools like 'create_customer_booking' or 'create_booking_request' that likely handle the final submission.

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 clear temporal sequencing with 'Use after collecting booking details' and implies the two-phase flow (payment authorization before final submission). Lacks explicit guidance on failure handling or the specific next step after invocation, but the 'when to use' context is present.

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 but fails to explain critical behavioral traits: it doesn't state that calling this tool sends a message (SMS/email) to the customer, doesn't describe the response format, and omits idempotency or rate limit concerns. 'OTP or magic link' implies the mechanism but not the side effect.

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 single sentence is front-loaded with the trigger condition ('Use when...') and contains no redundant words. However, given the severe lack of schema documentation and annotations, the description is overly terse rather than appropriately concise.

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 tool with side effects (sending verification messages) and three parameters with zero schema descriptions, the description is inadequate. It fails to explain what happens after invocation, what the identifier parameter expects, or how this tool fits into the verification flow with its sibling completion tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, requiring the description to fully compensate. While 'OTP or magic link' maps to method_preference, the description completely omits identifier semantics (is it email, phone, or customer ID?) and doesn't clarify channel_preference (SMS vs email). It insufficiently compensates for the undocumented 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 tool initiates identity verification using OTP or magic link methods. It effectively distinguishes from direct booking tools by specifying 'before assistant-led booking' and implies distinction from sibling completion tools (verify_customer_otp, verify_magic_link_token) by framing this as the starting point.

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 a 'Use when...' condition (existing customer verification before booking), which helps trigger selection. However, it lacks explicit guidance on when NOT to use it, doesn't clarify the relationship to the completion tools (verify_customer_otp, verify_magic_link_token), and omits prerequisites like requiring an existing customer profile.

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 'short-lived' nature and OTP bypass, but lacks specifics on session duration, what operations the session enables, side effects, or error conditions.

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?

Single sentence packs multiple critical distinctions: flow type (trusted telephony), verification state (already verified), output (short-lived booking session), and negative constraint (without OTP). No redundant words.

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?

Adequately covers the trust model and session characteristics, but omits what the session is used for (presumably subsequent booking operations) and what the return value represents. Given this is a session-establishing tool with no output schema, additional context on the session's purpose would strengthen completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% for the single 'identifier' parameter. Description mentions 'caller number' in context but never explicitly maps it to the identifier parameter or describes expected format (E.164 phone number? internal ID?). Provides implied context but not explicit parameter 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?

Description precisely defines the tool's function: creating a short-lived booking session. It distinguishes from siblings by specifying 'trusted telephony flows' and 'without OTP', clearly contrasting with verify_customer_otp and start_customer_verification in the sibling list.

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 required condition for use ('caller number is already verified by the channel provider') and the specific flow context ('trusted telephony'). Implicitly identifies when NOT to use (when OTP is needed) but doesn't explicitly name the alternative tool.

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 behavioral burden. It mentions 'verified customer' implying a prerequisite state, but fails to disclose whether tags are additive or replacing, idempotency behavior, error conditions, or what the response indicates.

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 single-sentence structure is efficient and front-loaded with the core action. However, given the complete lack of schema documentation and annotations, the extreme brevity leaves critical information gaps that additional structured sentences could address.

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 zero schema descriptions, no annotations, no output schema, and integration complexity with CRM/booking workflows, the description is incomplete. It omits session_token provenance, tag semantics, return value structure, and error scenarios necessary for correct 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 description coverage is 0%, requiring the description to compensate. While it references 'tags' generically, it provides no semantics for 'session_token' (where to obtain it, its relationship to verification) or tag formatting expectations beyond the 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 adds CRM tags to verified customers for booking workflow tracking, providing specific verb, resource, and context. However, it does not explicitly distinguish from sibling tool 'update_contact_note' which handles different contact metadata.

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 context ('for booking workflow tracking') suggesting when to use it, but lacks explicit guidance on when NOT to use it versus alternatives like 'update_contact_note', and omits prerequisites beyond the 'verified customer' reference.

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. The word 'append' is crucial behavioral disclosure (additive, not destructive). 'Internal CRM' clarifies visibility scope. However, missing: idempotency, failure modes, authorization specifics beyond session requirement, and return value for this write 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?

Single sentence with zero waste. Front-loaded action ('Use to append'), precise qualifiers ('internal CRM', 'verified customer', 'during or after booking'). Every word adds value.

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?

Adequate for a two-parameter write operation without output schema. Covers core function and timing, but as an unannotated mutation tool, should disclose safety/permission aspects (e.g., 'requires active verification session') more explicitly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, requiring description to compensate. While 'note' is mentioned and 'verified customer' hints at session_token purpose, the description fails to clarify parameter semantics, formats, or constraints (e.g., that session_token comes from verification, or note length limits).

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?

Clear specific verb ('append') and resource ('internal CRM note'). The temporal context ('during or after booking') and scope ('internal') effectively distinguish this from customer-facing communication tools. Minor gap: doesn't explicitly differentiate from sibling 'tag_contact'.

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 timing guidance ('during or after booking') and implies prerequisite ('verified customer'), but lacks explicit when-not-to-use guidance or comparison to alternatives like 'tag_contact'. Usage is implied rather than explicit.

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 the side effect (opens short-lived session) and temporal constraints, but omits error handling behavior, rate limits, or session expiration details that would help an agent handle failures.

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?

Single sentence of 19 words with zero redundancy. Front-loaded with usage guideline ('Use after...'), followed by core action and outcome. Every phrase contributes distinct information about timing, action, or result.

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 2-parameter verification tool with no output schema, the description adequately covers the authentication flow context and hints at the return value (booking session). Missing explicit error state documentation or session duration specifics prevents a 5.

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%, requiring the description to compensate. It provides semantic meaning for otp_code ('one-time passcode') and implies challenge_id context ('OTP challenge'), but does not explicitly map challenge_id to the prior step's return value or describe parameter relationships.

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 specific action (verify one-time passcode), the resource (OTP), and the outcome (open short-lived booking session). It distinguishes itself from sibling verify_magic_link_token by specifying OTP versus magic link authentication.

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 temporal sequencing ('Use after sending an OTP challenge') that establishes when to invoke this tool in the workflow. However, it does not explicitly name the prerequisite sibling tool (likely start_customer_verification) or specify error conditions/retry constraints.

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 responsibility for behavioral disclosure. It states 'verification' occurs but fails to describe the outcome (e.g., whether it returns customer identity, establishes a session, or merely returns a boolean), side effects, or failure modes.

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?

Single sentence that efficiently combines trigger condition and action. No redundant information; appropriately front-loaded with the usage trigger.

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?

Adequate for a single-parameter tool, but given the lack of output schema and annotations, the description should explain what successful verification yields (e.g., authentication state, customer profile) to complete the operational picture.

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 has 0% description coverage for the 'token' parameter. The description compensates partially by contextually identifying the token as the one 'provided' by the customer from the magic link, but omits critical constraints (minLength 24, maxLength 4000) and format expectations that would aid correct invocation.

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 tool's function (token verification) and the specific context (magic link click). It distinguishes from siblings like 'verify_customer_otp' by specifying the magic link trigger, though it frames the purpose as a usage instruction rather than a direct capability statement.

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 temporal context for invocation ('when the customer clicks a magic link'), giving clear guidance on when to select this tool over alternatives. However, it does not explicitly contrast with sibling verification methods like OTP or mention prerequisites.

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