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

With no annotations provided, the description carries the burden of behavioral disclosure. It reveals that the tool invokes the Google Maps Platform Routes API, computes road distance rather than straight-line distance, and returns zone, fee, hours, and COD fee. This is good transparency for a non-mutating calculation tool, though it does not mention failure behavior or API rate implications.

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

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

A single dense sentence conveys the main action, inputs' purpose, fee structure, and return values with no filler. The key information is front-loaded in the verb and resource.

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

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

Given there is no output schema, the description compensates by explicitly listing the expected return values: distance, zone classification, fees, estimated hours, and COD fee. It also identifies the external API. Minor gaps remain, such as how invalid addresses are handled, but the tool is simple enough that the description is largely sufficient.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters. The description adds useful context about outputs and fee tiers, but it does not elaborate on parameter meanings beyond the schema, so the baseline score applies.

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

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

The description states a specific action (compute, classify, return) on a clear resource: delivery zone and fee for Bangladesh. It also enumerates concrete outputs (distance, zone tiers with fees, delivery hours, COD fee), which distinguishes it from sibling tools like compare_courier_rates or validate_and_geocode_address.

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

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

The description clearly implies the tool is for computing delivery zone and fee, but it does not explicitly state when to prefer it over alternatives such as compare_courier_rates or validate_and_geocode_address. Usage context is inferable but not directly stated.

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 discloses that the data is real and not mock ('100% Real Live', 'Zero mock data'), which is valuable for setting expectations. However, it does not explicitly state that the operation is read-only, mention any rate limits, authentication requirements, or potential side effects. The 'returns' wording implies a read operation, but it is not explicitly declared. This is a moderate gap given no annotations exist.

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

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

The description is a single sentence that front-loads the core purpose ('100% Real Live nationwide courier fraud check') and then lists the outputs. Every phrase serves a purpose: it clarifies the scope (nationwide Bangladesh, Steadfast API), the data quality (real, not mock), and the results (counts, success rate, risk evaluation). No wasted 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?

For a simple tool with one parameter and no output schema, the description covers the essential points: it states the operation (fraud check), the input (a phone number), the output (metrics and risk evaluation), and the data authenticity. It does not mention error handling or interpretation of the risk evaluation, but these are not strictly necessary for calling the tool correctly. The description is sufficient for an agent to understand what the tool does and what it returns.

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 for 'phone' is complete (100% coverage), stating it expects an 11-digit Bangladeshi mobile number. The tool description adds minimal extra meaning—only that the phone is used for the fraud check. It does not explain how the number is used beyond 'evaluate,' but since the schema already documents the parameter's format and purpose, a baseline of 3 is appropriate. The description does not conflict or add significant depth.

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: a nationwide courier fraud check for Bangladesh logistics networks. It names the specific data returned (delivery/cancellation counts, success rate, risk evaluation) and distinguishes itself from siblings like track_parcel or get_balance by focusing on fraud assessment. The verb 'check' and resource 'fraud risk' are explicit.

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

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

The description implies the tool is used to evaluate a phone number for fraud risk, but it does not explicitly state when to use it over alternatives or provide exclusions. It lacks guidance like 'use this before shipping to a new number' or 'use track_parcel for existing orders.' The context is clear but not explicitly framed against siblings.

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 must carry the full behavioral burden. It states that the comparison is real-time and that it recommends based on cost vs speed, but it does not disclose whether this is a read-only operation, whether external APIs are called, or any side effects or latency characteristics.

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 deliver the core function and the recommendation value without filler. The main verb appears first and each clause adds useful information, making the description easy to scan and act on.

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

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

With no output schema and no annotations, the description covers inputs and high-level behavior but does not explain how results are returned or how the priority parameter affects output. This leaves a moderate gap for an agent that needs to parse the recommendation result.

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

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

Schema description coverage is 100%, so the baseline is 3. The description maps recipient_address, weight_kg, and cod_amount to the real-world inputs, and 'cost vs speed' loosely reflects the priority parameter, but it adds no additional syntax or precedence details beyond what the schema already 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 uses a specific verb ('compare') with a concrete resource: real-time tariff and SLA comparison across four named couriers. It also states a clear outcome (recommends the optimal carrier), which distinguishes it from siblings like list_couriers and create_parcel.

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 clearly establishes the intended scenario: comparing courier rates and SLAs for a destination, parcel weight, and COD amount. However, it does not explicitly state when not to use the tool or mention alternatives such as calculate_delivery_zone_and_fee.

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

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

The description only adds 'with normalized response' as a behavioral trait; everything else about side effects, prerequisites, or error behavior is left unstated. With no annotations, the description should carry more of the burden for a state-changing create 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?

A single, efficient sentence with no filler; the key action and scope are front-loaded. 'Across Bangladesh' and the courier list are useful context, and 'normalized response' cues expected output.

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

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

Despite complete parameter docs, the description omits return-value details, side effects, and any sequencing with sibling tools. No output schema exists, so the vague 'normalized response' doesn't tell an agent what to expect after booking.

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

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

Schema description coverage is 100%, so the schema already documents all 12 parameters. The description's mention of the four couriers and response normalization adds minimal semantic value beyond the enum and defaults already in the schema.

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

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

Begins with a specific verb ('Book') and a concrete resource ('a new parcel delivery'), names the supported couriers, and adds a response-normalization guarantee. This clearly separates it from sibling tools like track_parcel, list_couriers, and get_balance.

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 action is unambiguous and no sibling performs creation, so an agent can infer when to call it. However, it doesn't explicitly mention that validation/rate-comparison tools (e.g., validate_and_geocode_address, compare_courier_rates) could precede booking, so usage context is clear but exclusions/ordering are absent.

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

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

No annotations are provided, so the description must carry the burden. 'Retrieve' and 'current' imply a safe, read-only, fresh data lookup, which is helpful. However, it does not disclose potential errors, authentication requirements, or the shape/scope of 'payout details,' leaving some behavioral ambiguity.

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

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

One tight sentence with no filler. The core action and object are front-loaded, and the courier scoping is immediately clear.

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

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

For a one-parameter tool with no output schema, the description covers what the agent needs to decide to call it and what it will get back at a high level (balance and payout details). It is slightly incomplete in not detailing payout details or return format, but not enough to block 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 100%, so the schema already fully documents the single 'courier' parameter, including its enum values. The main description adds no extra parameter meaning beyond reinforcing that the balance is checked 'from a courier,' which matches the schema. Baseline 3 is appropriate.

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

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

The description opens with a specific verb ('Retrieve') and a precise resource ('current merchant account balance and payout details') scoped to a courier provider. Among the sibling tools, none covers balance/payout retrieval, so the tool is clearly distinguishable without opening the schema.

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

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

The description gives clear context: use this tool when you need a merchant account balance or payout details for a specific courier. It does not explicitly name alternatives or exclusions, but the sibling tools are distinct operations (tracking, parcel creation, rate comparison), so confusion is unlikely.

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

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

With no annotations, the description carries the behavioral transparency burden. It discloses a read-only operation through verbs like 'Show' and 'check', and clarifies that credential status is verified. It does not mention auth requirements or rate limits, but for a zero-parameter listing tool this is a minor gap rather than a serious omission.

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

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

A single, well-structured sentence front-loads the main action and resource, then adds the credential-checking detail. There is no filler, redundancy, or unnecessary explanation.

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 zero-parameter, no-output-schema, simple read-only tool, the description is complete enough for an agent to invoke it correctly. The only minor ambiguity is what 'spatial services' includes, but this does not block correct usage.

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 zero parameters and 100% schema coverage, so there is no parameter documentation burden. The description still adds value by indicating what the tool reports: supported couriers, spatial services, and active credentials.

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

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

The description uses a specific verb ('Show') with a clear resource ('supported Bangladeshi couriers and spatial services') and adds a second distinct function ('check which credentials are active'). It is immediately distinguishable from siblings like track_parcel, create_parcel, and get_balance, which perform different 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 gives clear context for when to use the tool: when an agent needs to discover supported couriers, spatial services, or active credentials. It does not explicitly name alternatives or exclusions, but none of the sibling tools serve the same discovery purpose, so the routing is unambiguous in this toolset.

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

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

With no annotations, the description must disclose behavior, but it is ambiguous whether this tool actually sends the WhatsApp message or merely generates it, and whether 'escalation/hold instructions' are actionable side effects. It does not mention reversibility, permissions, rate limits, or other consequences, leaving the agent uncertain about real-world impact.

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 two sentences with no wasted words. It front-loads the core purpose and then enumerates the two key outputs, making it easy to scan and understand.

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 (7 parameters, no output schema, no annotations), the description is too high-level. It omits expected return values, conditional logic, and behavioral side effects, so an agent cannot fully predict what will happen when invoking it, especially around sending messages or imposing carrier holds.

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

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

Schema coverage is 100%, so the baseline is 3 even though the description adds no parameter-specific detail. The description refers to 'customer' and 'carrier' broadly but does not explain conditional parameters (e.g., reschedule_date for reschedule_requested, corrected_address for wrong_address) that the schema implies.

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

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

The description states a specific verb ('resolve') and resource ('NDR issue'), and clearly outlines the outputs ('WhatsApp re-engagement message' and 'escalation/hold instructions'). It is distinct from sibling tools like track_parcel or create_parcel, so an agent can identify its unique role without needing to open schemas.

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

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

The phrase 'failed courier delivery attempts' gives clear context for when to use this tool, and the sibling list confirms it is the only NDR-resolution tool. However, it does not explicitly state when not to use it or name alternative tools, leaving some inference to the agent.

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 states the tool tracks delivery status but does not disclose what the response looks like, whether it supports all listed couriers equally, what happens with invalid tracking codes, or any rate limits or auth requirements. For a read-only tracking tool, this is a notable 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 sentence that is concise and front-loaded with the primary action and resource. It names the couriers and the required input. No wasted words, though it could be slightly more structured with explicit usage 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?

For a simple two-parameter tracking tool, the description is mostly adequate. However, with no output schema and no annotations, the agent is left without information about the return format, error behavior, or courier-specific nuances. The description covers the core purpose but not the full context needed for robust 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 100%, so the schema already documents both parameters. The description adds the context that tracking_code is a Consignment ID or tracking code, which matches the schema. It does not add meaning beyond the schema, so baseline 3 is appropriate.

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

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

The description states a specific verb ('Track') and resource ('shipment delivery status') and names the supported couriers (Steadfast or Pathao). It distinguishes itself from siblings like create_parcel and get_balance, though it doesn't explicitly differentiate from other tracking-like tools (none exist among 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 implies when to use the tool: when you need to track a shipment's delivery status. It does not explicitly state when not to use it or mention alternatives, but the sibling list (create_parcel, get_balance, etc.) makes the context reasonably clear. No explicit exclusions or alternative routing.

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?

There are no annotations, so the description must carry the full behavioral burden. It does disclose the external Google Maps Platform dependency and the expected outputs, but it does not state whether the operation is read-only, whether it makes a network call with associated cost, or what happens on validation/geocoding failure.

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

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

A single sentence packs in the tool's purpose, geographic scope, external API, and main outputs without excess. Key information is 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?

The description mentions the important output concepts (sublocality, coordinates, confidence score), which is useful given there is no output schema. However, it does not explain the meaning of the confidence score, how optional thana/district parameters affect results, or failure/edge-case behavior, leaving some ambiguity for a tool with no annotations.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters. The description adds no parameter-specific detail beyond what is in the schema, so the baseline score of 3 is appropriate.

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

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

The description names a specific verb-resource pair ('Validate and geocode a Bangladesh delivery address') and states the key outputs: administrative sublocality, lat/lng coordinates, and delivery confidence score. This clearly distinguishes it from siblings like list_couriers, track_parcel, and check_fraud_risk.

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

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

The description implies the tool is used when address validation or geocoding is needed, but it gives no explicit guidance on when to choose this tool over alternatives such as calculate_delivery_zone_and_fee or check_fraud_risk. No exclusions, preconditions, or alternative conditions are mentioned.

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