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

With no annotations, the description carries the full burden and does well: it declares READ-ONLY, zero external side effects, and that it does not book shipments, and it discloses the external dependency (Google Maps Platform Routes API v2:computeRoutes), which implies a network call and possible latency/failure. It stops short of stating auth requirements, rate limits, or fallback behavior when geocoding fails, which keeps it from a 5.

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?

Dense but front-loaded: the computed outputs and their tier values come first, then the read-only guarantee, then routing guidance. The parenthetical tariff table is efficient rather than padding, though the single long sentence with nested parentheses is harder to scan than a short bulleted structure.

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?

There is no output schema, so the description must convey what comes back; it does so conceptually (zone, distance, SLA window, COD percentage) and even supplies the concrete tier values. The remaining gap is the unexplained weight-to-fee relationship and how the origin default ('Dhaka Central Hub') interacts with distance measurement.

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. The description clarifies that only one destination is handled and gives the distance thresholds that recipient_address feeds into, but it never explains how weight_kg changes the quoted fee — a material gap for a fee calculator whose schema only says 'default: 0.5'.

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 a specific verb (calculate) and enumerates exactly what is computed: zone tier, road distance, SLA, and COD percentage for a single destination. It also names the sibling tool it is not ('compare_courier_rates'), so an agent can distinguish it without opening either 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?

Explicit when-to-use ('quoting shipping charges to a customer or determining flat delivery tiers for an order') and explicit when-not-to-use with the alternative named ('side-by-side multi-carrier tariff quotes with weight breaks... use compare_courier_rates instead'). Nothing is left to inference.

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 supplied, the description carries the burden and does well: it declares the operation read-only ('READ-ONLY DIAGNOSTIC QUERY'), the data source ('live nationwide Bangladesh logistics databases'), and the three output dimensions. It omits edge-case behavior such as what is returned when a number has no history, and says nothing about rate limits or cost.

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?

Front-loads purpose and scope, then moves to usage and exclusions, then parameter format – a sensible order. Some wording is promotional rather than functional ('Zero mock data, authentic carrier telemetry only'), which costs a little density but does convey data authenticity.

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?

There is no output schema, so the description must describe returns, and it does list the three key metrics. It stops short of explaining result shape, score ranges, or no-match behavior, which would matter for a single-parameter diagnostic tool.

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% and the single parameter is already documented as an '11-digit Bangladeshi mobile number', so the schema does the heavy lifting. The description restates the format and adds a concrete pattern ('01XXXXXXXXX'), which is marginal added meaning rather than new 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?

Uses a specific verb ('Screen') plus the exact resource (a customer phone number) and names the returned metrics: delivery success rate, cancellation counts, and return fraud risk score. This is clearly distinguishable from siblings like validate_and_geocode_address or track_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?

States the trigger condition explicitly ('before confirming high-value COD orders to screen for chronic returners or fake orders') and names two concrete exclusions with the sibling tools to use instead (geocoding, parcel booking). Nothing about when-to-use is left to inference.

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 supplied, the description carries the full burden and does so for the most important trait: 'READ-ONLY CALCULATION ENGINE: Has zero external side effects and does not create orders.' It does not disclose whether rates are live or cached, any rate limits, or credential requirements, which keeps it short of a 5 for a zero-annotation 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?

Three sentences, front-loaded with the operation and followed immediately by safety profile and routing exclusions — good ordering with no filler. The all-caps safety clause is slightly louder than necessary, but it earns its place given the absence of annotations.

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?

There is no output schema, so the description should clarify the return shape; 'side-by-side comparisons' plus 'select the recommended courier' implies both a per-courier breakdown and a recommendation, but it never states whether all four carriers always appear or how ties are broken. Otherwise complete for a four-parameter, single-required-field read tool.

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 four parameters including the enum values. The description adds purpose-level framing ('exact parcel weight, declared COD amount, and optimization priority ... to select the recommended courier') and notes nationwide destination scope, but no format or unit guidance beyond what the schema states.

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?

Opens with a specific verb and resource ('Execute side-by-side tariff, SLA, and COD collection fee comparisons') and names the exact four couriers and the inputs that drive the comparison. An agent can distinguish this from list_couriers or calculate_delivery_zone_and_fee without opening any 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?

Explicitly states the use case ('when deciding which carrier offers the best commercial rate or fastest SLA ... before booking') and adds two negative exclusions that name the correct alternatives: 'calculate_delivery_zone_and_fee' for flat-rate zone lookup and 'create_parcel' for booking. Routing is unambiguous.

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 exist, so the description carries the full burden and does: it discloses that this writes a real billable shipment to the carrier's production database, assigns an official tracking code, deducts fees on pickup, and that cancellation afterward requires courier portal operations. It also names two failure modes (missing courier credentials, invalid recipient phone), which is unusually complete 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?

Front-loaded with purpose and carrier scope, then the mutation warning, then preconditions, then alternatives, then error conditions. Every sentence carries distinct operational information; nothing is redundant or padded.

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 12-parameter, unannotated, no-output-schema mutation tool this covers the critical ground: side effects, billing, irreversibility, prerequisites, and failure modes. The only minor gap is that, absent an output schema, it does not explicitly state what the caller receives back (e.g. the tracking code field in the response), which it only implies.

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% and every parameter is already documented in the schema with types, defaults, and courier-specific notes, so the baseline of 3 applies. The description adds only a precondition on recipient phone validity and the 'auto' routing mode, neither of which extends individual parameter meaning beyond 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?

States a specific verb and resource ('Book and dispatch a physical parcel consignment') and enumerates the supported carriers including 'auto' smart routing. It is immediately distinguishable from read-only siblings like compare_courier_rates and track_parcel without opening either 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?

Explicit preconditions are given ('Use only after customer address and phone number are verified') and named alternatives handle the adjacent cases: calculate_delivery_zone_and_fee / compare_courier_rates for fee estimation and validate_and_geocode_address for address validation. An agent has both the when and the when-not.

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 at all, the description carries the full burden and does most of it: it declares the operation READ-ONLY and non-mutating ('Does not initiate payouts or mutate accounting ledgers'), states the auth prerequisite ('Requires active merchant API keys for the requested courier'), and discloses failure behavior ('throws an error if unconfigured'). Minor gaps remain around rate limits and whether results are paginated or cached, though 'live' signals freshness.

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?

Front-loaded with the purpose, then progressively narrows to constraints, exclusions, and prerequisites; nearly every clause adds decision-relevant information. The single dense block is slightly heavy for skimming, but no sentence is 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?

There is no output schema, so the description correctly compensates by enumerating the returned payload (vault balance, pending disbursement, payout ledger). For a one-parameter read tool this is close to complete; only freshness/pagination or rate-limit notes are absent.

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% and the single 'courier' parameter already carries an enum with a description, so the baseline would be 3. The description earns one step above baseline by explaining that merchant API keys are courier-specific, which tells the agent the parameter has configuration consequences beyond string selection.

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 a specific verb and resource ('Retrieve live merchant cash-on-delivery (COD) vault balance, pending disbursement amounts, and payout ledger') and scopes it to two named portals. It also separates itself from the nearest ambiguity ('Do NOT use for customer balance'), so the agent can distinguish it from siblings like calculate_delivery_zone_and_fee without opening a 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?

Gives an explicit positive condition ('Use when accounting or merchant finance operators want to verify accrued COD collections or payout readiness') and an explicit negative with the alternative named ('Do NOT use for customer balance or shipping quote estimation (use calculate_delivery_zone_and_fee)'). Routing is unambiguous.

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 supplied, the description carries the full burden and does well: it declares read-only behavior, zero external side effects, and no mutation of database or carrier state. What it does not disclose is whether the call fans out to live carrier APIs (and therefore has latency or per-call cost) or whether returned credentials are masked or truncated, which matters for a discovery tool that exposes API keys.

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 structure is front-loaded and purposeful: capability, then the read-only safety statement, then usage, then exclusions. The only mild redundancy is the capitalized 'READ-ONLY DISCOVERY TOOL' label immediately followed by a sentence that says the same thing ('zero external side effects', 'does not mutate').

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, no-annotation tool, the description supplies most of what an agent needs: scope, safety profile, and routing to alternatives. It stops short of describing the shape of the returned status data (per-courier readiness flags, credential presence vs. validity), which is the one gap left by the absence of an output schema.

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

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

The tool takes no parameters, so there is no parameter semantics to explain; the baseline for a zero-parameter schema applies. The description correctly does not invent or discuss inputs.

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 ("Inspect") and specific resources (operational health, configuration status, active API credentials) across named courier networks and Google Maps Platform. It is immediately distinguishable from siblings because it explicitly positions itself against track_parcel and calculate_delivery_zone_and_fee.

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 gives a concrete when-to-use scenario (session initialization to verify which couriers are ready for dispatch or balance checking) and explicit when-not-to-use cases with the named alternative for each: 'track_parcel' for shipment status and 'calculate_delivery_zone_and_fee' for fees. Nothing about tool selection is left to inference.

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

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

With no annotations, the description carries the full burden and does so well: it declares the tool is "GENERATION-ONLY (NO DIRECT DISPATCH)", does not send network messages, does not modify courier bookings, and requires review or downstream dispatch. Gaps remain around idempotency, failure behavior for an unknown consignment_id, and whether any state is persisted, which matters for a tool that produces dispute tickets.

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 most important constraint — generation-only, no dispatch — is front-loaded in capitals before any detail, and the use/do-not-use routing is compact. Some phrasing is promotional ("empathetic, conversion-tested Bengali WhatsApp re-engagement copy"), which adds adjectives but little operational 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?

For a seven-parameter tool with no annotations and no output schema, the definition covers the critical unknowns: what gets generated, that nothing is sent automatically, and when to invoke it. It does not describe the shape of the returned copy/ticket payload, which is the main remaining gap since no output schema exists 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?

Schema description coverage is 100%, so the schema already documents all seven fields and both enums, making 3 the baseline. The description links issue context to expected output (reschedule requests, wrong addresses) but does not explain how the enum values change generated copy or escalation content, adding little per-parameter meaning beyond 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?

The description gives a specific verb and resource — "Automate Non-Delivery Report (NDR) triage and dispute resolution when a courier delivery attempt fails" — and immediately clarifies it generates Bengali customer copy plus carrier escalation tickets. It explicitly names the sibling tools it is not ('track_parcel', 'create_parcel'), so an agent can disambiguate without inspecting 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?

It states explicit triggers ("parcel status changes to failed attempt, customer phone off, or reschedule requested") and explicit exclusions routed to named alternatives ("Do NOT use for general order tracking (use 'track_parcel') or creating orders (use 'create_parcel')"). Both when-to-use and when-not-to-use are covered, which is rare.

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 supplied, the description carries the full burden and does so: it declares READ-ONLY semantics, that shipment state and carrier data are unaltered, enumerates the normalized status set, and explains that the provider is auto-detected from the consignment prefix. This is behavior an agent cannot infer from the 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?

Front-loaded with purpose, then safety, then return payload, then routing exclusions - a logical order with no filler. It is dense, and the status enumeration is long, but each clause carries usable 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?

No output schema exists, so the description correctly spells out what is returned (normalized status, location, carrier notes, timestamp history). Combined with the usage boundaries, an agent has everything needed to invoke and interpret the call.

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 and the prefix-based auto-detection. The description only restates that consignment ID or tracking code is acceptable, adding no format or validation detail beyond the schema examples.

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?

Opens with a specific verb and resource ('Query live, real-time tracking milestones and delivery telemetry') and names the four carriers covered. An agent can distinguish it from siblings like create_parcel or resolve_ndr_issue without opening any 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?

Explicitly states the when ('end-customer or merchant inquires about existing shipment progress') and the when-not, naming both alternative tools ('create_parcel' for creation, 'resolve_ndr_issue' for failed deliveries). Routing is unambiguous.

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 supplied, the description carries the full burden and does so well: it declares READ-ONLY SPATIAL LOOKUP, zero side effects, and no mutation of booking data, plus discloses the backing services (Google Maps Geocoding with OpenStreetMap gazetteer fallback). It stops short of describing failure behavior or latency/rate-limit characteristics of those external dependencies, which would matter for an agent deciding whether to retry.

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

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

Three sentences, each with a distinct job: what it returns, the safety/read-only profile plus fallback stack, and the routing guidance with an explicit exclusion. Outputs and the read-only guarantee are front-loaded, and there is no 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?

There is no output schema, so the description must explain return values — and it names all three return components including the confidence score, which tells the agent how to judge result quality. For a 3-parameter lookup tool this is complete enough to call correctly.

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% and each parameter already carries its own description and example, so the schema does the heavy lifting. The description adds context about what the address is used for (Thana/District matching) but no field-level syntax, formatting, or precedence rules beyond the schema — the baseline 3 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?

States a precise compound verb (validate, clean, geocode) against a specific resource (unformatted Bangladesh delivery address) and enumerates the exact outputs: Thana/District/Division boundaries, rooftop lat/long, and a 0-100 confidence score. It is immediately distinguishable from siblings like calculate_delivery_zone_and_fee.

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?

Gives an explicit when-to-use trigger ('Use before booking parcels to detect spelling errors, verify Thana/District matching') and an explicit when-not-to-use with a named alternative ('Do NOT use for calculating delivery fees or road routing distance (use calculate_delivery_zone_and_fee instead)'). Both directions of routing are covered, so nothing is left to inference.

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