Shipcloud MCP by usefulapi

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

Annotations already flag a non-readOnly, non-idempotent, non-destructive open-world write. The description adds genuine value beyond them: no shipment is created and no cost is incurred, the return is an id, and the record cannot be deleted through this server — a meaningful irreversibility warning that annotations alone do not convey.

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 short sentences, front-loaded with the WRITE marker, then scope, then return value and endpoint. Every sentence carries information an agent needs.

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 single-object write with no output schema, the definition covers the operation's side effects, what is returned (an id), and the endpoint. The only meaningful omission is guidance on the address object's contents, but the nested schema documents most fields.

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 reported as 0%, and the description says nothing about the single nested 'address' object — not which fields are required (street, zip_code, city, country) nor the ISO-2 country format or the 'give last_name or company' rule. The nested property descriptions carry that knowledge, so the description fails to compensate for the coverage 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?

States a specific verb and resource ('save an address in the shipcloud address book') and immediately scopes it away from shipment creation with '(no shipment, no cost)'. An agent can distinguish it from shipcloud_create_shipment_with_label and shipcloud_get_address 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 '(no shipment, no cost)' qualifier gives clear context on when this is the right tool versus label-creating siblings, and the note that the address cannot be removed through this server informs the use decision. It stops short of explicitly naming the alternative tools or stating prerequisites, so it is clear context rather than full 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?

Annotations already flag destructive/openWorld/non-idempotent, and the description adds genuinely new consequences: a real request is sent to the carrier, it cannot be cancelled through this server, and carriers may bill for pickups. That is exactly the risk context an agent needs before a destructive write.

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 paragraph led by the WRITE marker, with the highest-risk fact (irreversible, billable) placed early and no filler sentences. Every clause carries 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 destructive, non-idempotent mutation with no output schema, the description covers irreversibility, billing, confirm gating and shipment scoping. It omits what the call returns (presumably a pickup request id the agent would need for follow-up), which is the main remaining gap.

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 83%, so the baseline is 3, but the description adds semantics the schema only hints at: the omitted-shipment_ids default scope and the return-shipment exclusion. The confirm gating rationale is echoed from the schema rather than new, so it is not a full 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?

"WRITE: order a carrier (dpd, gls, hermes or ups) to pick up parcels at an address in a time window" gives a specific verb, resource, enumerated carriers and the two defining inputs. It is unmistakably distinct from sibling creation tools like shipcloud_create_shipment_with_label or shipcloud_create_prepared_shipment.

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 clearly states the conditions that select behavior: with shipment_ids only those parcels, without them all not-yet-picked-up shipments, and return shipments cannot be picked up at all. It also gates invocation on explicit user agreement via confirm=true. It does not name a sibling alternative (e.g. get_pickup_request to check status), so it stops short of a 5.

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

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

Goes well beyond the annotations: annotations only say readOnlyHint=false and destructiveHint=false, while the description discloses that nothing is charged, no carrier is contacted, the shipment can be deleted at any time, and an id is returned. For a write tool these are the exact side-effect facts an agent needs.

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 tight sentences, front-loaded with the WRITE marker and the core scope, then the alternative, then the endpoint. Every sentence earns its place with no repetition of schema or annotation content.

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 9-parameter nested write tool with full schema coverage and no output schema, the description supplies the missing pieces: what is and isn't charged, reversibility, the return value ('shipment id'), and the sibling that buys a label. Nothing material is 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 description coverage is 100%, so the schema already documents all 9 parameters (carrier, service, packages, addresses, etc.), making baseline 3 appropriate. The description adds no parameter-level detail beyond the conceptual 'create_shipping_label=false', which isn't even a field in the schema, so it does little extra work here.

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 ('save a shipment') plus a precise scope ('WITHOUT buying a label'), which distinguishes it cleanly from shipcloud_create_shipment_with_label. An agent can select 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?

Explicitly names the alternative and the condition that selects it: 'To buy the label use shipcloud_create_shipment_with_label.' That is exactly the routing decision an agent needs, with nothing 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?

Annotations already flag destructive/non-idempotent/open-world, but the description goes well beyond them: real EUR charge excl. VAT, no-retry semantics, possible duplicate labels after a timeout, non-atomic same-instance duplicate guard that fails across Worker instances, and the ~17:00–20:00 cancellation window. This is exactly the behavioral context an agent needs before spending money.

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 'WRITE, COSTS MONEY' signal and organized as risk → cost → retry → confirmation, with no filler sentences. It is dense and slightly repetitive (checking shipcloud after an uncertain result is stated twice) and packs multiple clauses per sentence, but every sentence carries operational weight.

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 10-parameter, nested-object, money-spending tool with no output schema, the description covers cost, side effects, idempotency hazards and the customs exclusion thoroughly. The remaining gap is return values — with no output schema, the agent is not told what comes back (label document/URL, shipment id), which matters for a purchase 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 coverage is 100%, so baseline is 3; the description still adds meaning by tying reference_number to duplicate detection after a timeout and by stressing it must be unique and serialized per reference. The confirm parameter's 'ask first, do not assume' framing reinforces but largely restates the schema text, so it does not fully exceed the schema's own guidance.

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+resource ('create a shipment AND buy its shipping label') and immediately qualifies scope with 'create_shipping_label=true', which separates it from shipcloud_create_prepared_shipment. 'POST /shipments' anchors it to the underlying endpoint, so an agent knows exactly which operation this is.

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 explicit routing: fetch the price first from shipcloud_get_shipment_quote, confirm only after the user agreed to be charged, cancel via shipcloud_delete_shipment before the carrier cut-off, and on uncertain results check shipcloud_list_shipments before retrying. It also states a hard exclusion ('shipments needing customs papers are not supported here') and the sandbox-vs-live distinction.

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?

Annotations already declare write, non-destructive, open-world, and non-idempotent behavior. The description adds valuable context beyond that: it creates a tracker, produces no label, incurs no shipping charge, requires your own carrier contract, and uses POST /trackers.

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 tight sentences, front-loaded with WRITE, then the key scope, constraints, side effects, and endpoint. The carrier list reinforces the enum without becoming bloated.

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 write tool with no output schema, the description gives purpose and key constraints but omits what the create call returns and what notification_email does. Those gaps matter for correct invocation, especially the unexplained optional parameter.

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 only 33%. The description reinforces the carrier enum and adds the important restriction that it must be your own carrier contract, but it never explains the optional notification_email parameter, so it only partially compensates for the low schema coverage.

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

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

States a specific action and resource: have shipcloud track/create a tracker for a parcel NOT created with shipcloud, using the carrier's tracking number. It clearly distinguishes this from creating a shipment with a label and from retrieving an existing tracker.

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 clear when-to-use context: parcels not created with shipcloud, only your own carrier contracts, and only dhl/dpd/gls/ups. It does not explicitly name sibling alternatives such as create_shipment_with_label or get_tracker, so it falls short of full alternative routing guidance.

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

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

Annotations already flag destructiveHint/readOnlyHint=false, but the description goes well beyond them: it discloses irreversibility ('Cannot be undone'), the carrier cut-off window that determines success or failure, the confirm-after-agreement protocol, and the underlying DELETE endpoint. This is the kind of behavioral context an agent needs before firing an irreversible write.

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 the WRITE/DESTRUCTIVE warning, then the branching success condition, then the irreversibility and confirmation requirement, then the endpoint. No filler sentences; every clause carries decision-relevant 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 two-parameter destructive tool with no output schema, the description covers safety profile, success/failure conditions, precondition for invocation, and reversibility. Nothing an agent needs in order to call it correctly is missing.

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% and the confirm parameter is already documented in detail inline, including 'Set it ONLY after the user has explicitly agreed.' The description's line about confirm=true largely restates the schema; it adds only the linkage that the confirmation also covers label cancellation. Baseline 3 is appropriate when the schema carries the 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?

States a specific verb and resource ('delete a shipment') and immediately distinguishes the two cases that matter: a prepared shipment with no label versus one already carrying a label whose cancellation is time-bounded. An agent can tell exactly what this does versus siblings like shipcloud_get_shipment or shipcloud_create_shipment_with_label.

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-it-works / when-it-fails rule (prepared shipments any time; labeled shipments only before the carrier cut-off of roughly 17:00-20:00), plus a hard precondition that the user must have agreed before confirm=true. It does not name sibling tools for checking shipment status first, so the routing guidance is context-rich but not comparative.

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?

Annotations already declare readOnlyHint, openWorldHint and non-destructive behavior. The description adds useful behavioral context beyond that: it names the external carrier network being searched and indicates the result includes opening hours and distance. It does not discuss pagination, rate limits, or error behavior, but against the annotation coverage this is solid.

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 short sentences, front-loaded with the core action and followed by the required input modes and endpoint. There is no filler or repetition.

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 read-only search with ten parameters and no output schema, the description covers the main purpose and two return fields, but it leaves out the required carrier list and the meaning/behavior of limit, radius, and state. It is minimally adequate but not complete enough to prevent misuse.

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

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

Schema description coverage is only 40%, so the description needs to compensate, and it partially does by grouping address fields (street, zip_code, city, country) versus latitude + longitude. However, it omits the required `carriers` parameter entirely, along with `state`, `limit`, and `radius`, leaving important invocation semantics unaddressed.

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 (Search) and resource (a carrier's parcel shops, lockers and drop-off points), plus scope (near an address or coordinates). No sibling tool covers drop-off/pickup location lookup, so this is clearly distinguishable.

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 implies when to use the tool by saying to provide an address or coordinates, but it never explicitly contrasts with alternatives or states when not to use it. The usage context is inferred from the tool name and the input-mode sentence rather than stated as guidance.

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

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

Beyond the annotations, the description explains a critical behavioral consequence: production means real labels and charges, while sandbox means free test labels. This is exactly the kind of context an agent needs before triggering label creation, and it does not contradict the read-only annotation.

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 definition is compact and front-loads the account lookup, then adds the key environment distinction and the usage cue. Every sentence and parenthetical 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 zero-parameter, read-only account lookup with no output schema, the description is complete enough: it lists the returned fields and explains the environment distinction that affects downstream actions. Nothing essential for correct invocation is missing.

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 the schema has nothing to document and parameter semantics are inherently simple. The description appropriately avoids unnecessary parameter discussion.

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 resource and return content: the shipcloud user behind the API key, including id, email, customer number, plan, and environment. It clearly distinguishes this account-level lookup from shipment, address, order, and label operations 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?

It gives a concrete usage cue: 'Check this before creating labels.' That clearly signals the primary context in which to call the tool, though it does not explicitly name alternatives or when not to use it.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds only the REST mapping (GET /addresses/{id}), and says nothing about error behavior for missing ids or whether deleted addresses are retrievable.

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 short fragments, front-loaded with the resource and scope, with no wasted prose. The endpoint tap is arguably redundant but is compact and non-distracting.

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 read, most of what an agent needs is in the schema and annotations. However, with no output schema, the description does not indicate what fields a saved address returns, leaving the agent to discover the response shape at call time.

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% with a single required parameter whose description is 'The id shipcloud returned', so the schema already carries the semantics. The description adds nothing beyond 'by id', which is the baseline case.

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 (get) and resource (saved address) with the lookup key (id), which distinguishes it from list_addresses and create_address. It does not name the sibling alternative explicitly, so it falls short of a 5.

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

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

'One saved address by id' implies you must already have an id, which implicitly routes agents with a known id here rather than to list_addresses. There is no explicit when/when-not guidance or statement about what to do when the id is unknown.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds useful context by mapping each enum value to the corresponding REST endpoint, but says nothing about error behavior (e.g., what happens if no default is set) or whether any kind requires extra account configuration.

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 compact sentences with the resource definition front-loaded and the endpoint mapping trailing. No filler, though the endpoint list is arguably redundant with the tool's internal implementation and does not help the agent choose or call the 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?

For a single-parameter read tool with full annotation coverage this is close to sufficient, but with no output schema the description never hints at the shape of the returned address (fields, or absence of a default). That is the main remaining gap an agent would care about.

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 enum is already documented, but the description goes beyond it by explaining what each value actually means in the account: shipping = default sender, returns = default recipient of return shipments, invoice = invoice address. That semantic gloss genuinely helps an agent pick the right enum value.

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 concrete resource — one of the account's saved default addresses — and enumerates the three variants with their business meaning (default sender, default return recipient, invoice address). It is clearly distinct from shipcloud_list_addresses or get_address by the word 'default', though it never names those siblings for contrast.

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?

Usage is only implied: the reader infers 'call this when you need the account's default sender/returns/invoice address'. There is no explicit when-to-use vs when-to-use-instead guidance (e.g., use list_addresses to enumerate all saved addresses), and no statement of prerequisites such as whether the account must have a default configured.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered by structured data. The description adds almost nothing beyond the annotated behavior — no mention of error/not-found handling, authentication, or whether the response is live vs cached. The only extra content is the endpoint path and the shape of returned fields.

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 short, front-loaded fragments with zero padding. The endpoint path is arguably redundant with the tool identity, but it costs little and clarifies the underlying resource. Efficient overall.

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 single-parameter read tool with full schema coverage and safety annotations, the description is adequate but thin: it names the returned fields yet omits what an agent may need — behavior on unknown ids, and whether nested line items are paginated or truncated. No output schema exists, so the description carries some return-value burden and only partly discharges it.

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 order_id parameter is described in the schema ('The id shipcloud returned'), so baseline is 3. The description restates 'by id' without adding format, source, or error semantics beyond the schema's pattern constraint.

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 (get) and resource (order) with scope detail: 'One order by id, with delivery address and line items.' This distinguishes it cleanly from shipcloud_list_orders (plural list) and from siblings like shipcloud_get_shipment/address. The REST endpoint reference reinforces the mapping.

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 singular 'one order by id' implies when to use it versus the list sibling, but no alternative is named and no prerequisites or when-not conditions are given. Usage is inferable rather than 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?

The annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false. The description adds only the endpoint path and does not disclose any further behavior such as not-found handling, auth requirements, or response 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?

The description is two short sentences with no waste. The core operation is front-loaded, and the endpoint is secondary.

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 read-only lookup with complete schema documentation and safety annotations, the description is largely sufficient. It could mention the returned pickup request object, but no output schema exists and the operation is straightforward.

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%, and the single parameter is documented as 'The id shipcloud returned.' The description's 'by id' phrasing adds no meaning beyond the schema, so 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?

The description states a specific verb and resource: get one pickup request by id. It distinguishes the tool from list_pickup_requests and create_pickup_request by naming the singular lookup scope.

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 'One pickup request by id' implies the tool is used when an id is known, but it does not explicitly compare against list_pickup_requests or state when not to use this 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds real value beyond that with the sandbox caveat (no tracking events, price 0) and a view of what fields come back, though it omits auth/rate-limit context.

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

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

A single dense sentence plus a short sandbox caveat and endpoint hint; return fields are front-loaded and nothing is wasted.

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, the description usefully previews the returned structure and flags the sandbox behavior, which is the key correctness risk. Minor gaps (error cases on invalid id) remain but the essential call-relevant context is present.

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?

Only one parameter with 100% schema description coverage ('The id shipcloud returned'), so the schema already documents it fully. The description's 'by id' adds no syntax detail beyond the schema, making baseline 3 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?

States a specific verb (get) and resource (one shipment by id) and enumerates the returned payload (addresses, packages with tracking events, price, label URL, tracking URL). 'One shipment by id' implicitly distinguishes it from shipcloud_list_shipments, though no sibling is named explicitly.

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?

Usage is implied by the single-item-by-id framing, but there is no explicit when-to-use/when-not or reference to alternatives like list_shipments or get_tracker. The agent must infer the retrieval scenario.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description still adds value: it clarifies nothing is created and nothing is charged, discloses the EUR-excl-VAT pricing basis, and states the carrier-contract ownership constraint. These are real behavioral facts beyond the annotation flags.

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

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

Four compact sentences with zero waste, front-loading what is charged and the read-only guarantee before the precondition and the sibling reference. Every sentence 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 read-only quote tool with no output schema, the description covers pricing unit, read-only nature, contract constraint, and recommended sequencing. It could note the response shape (e.g. a price value), but the annotations and schema carry most of the remaining burden.

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 80%, so the schema already documents carrier, service, to, from, and packages. The description adds only the carrier-contract constraint and does not clarify parameter formats or the from-defaults behavior beyond what the schema states, so the baseline 3 holds.

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+resource: returns what shipcloud would charge for a shipment, with currency and VAT basis (EUR excl. VAT). It is the only quote tool among siblings and explicitly positions itself against shipcloud_create_shipment_with_label, so an agent can tell it apart 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?

Explicitly says to use it before shipcloud_create_shipment_with_label, giving a clear ordering and alternative. It also names a hard precondition (only carrier contracts owned by shipcloud), though it does not enumerate when-not-to-use cases beyond that constraint.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false, so the safety profile is covered. The description adds useful context by naming the returned contents (status and tracking events) and the underlying endpoint, but says nothing about behavior on unknown ids, error responses, or freshness of tracking data.

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 short sentences, front-loaded with what you get and how to address it, with no filler. The endpoint reference is compact and useful for mapping to the API.

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 single-record read with full annotation coverage and full schema coverage, this is nearly complete; it even hints at the return payload despite having no output schema. Only error/not-found behavior is missing, which is minor here.

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?

One parameter with 100% schema description coverage ('The id shipcloud returned') plus a regex pattern, so the schema does the heavy lifting. The description's 'by id' merely restates it, adding no format or sourcing detail beyond what's structured.

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 ('One tracker by id') plus the payload it returns ('status and tracking events'), which is enough to distinguish it from shipcloud_list_trackers. It doesn't explicitly name the sibling, so it stops short of a 5.

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

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

'by id' implies this is the single-record fetch versus the list tool, but that choice is left to inference. No explicit when-to-use, prerequisites, or named alternative are given.

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

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

Annotations already declare `readOnlyHint: true`, `openWorldHint: true`, and `destructiveHint: false`, so the safety profile is covered. The description adds useful context that the result is paged and that returned address IDs are usable as `to`/`from`, but it does not cover auth, rate limits, or exact filtering semantics.

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 four short phrases with zero waste, front-loading the resource, filterability, paging, and endpoint. Every sentence 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 list tool with nine optional parameters, no output schema, and low schema description coverage, the description is adequate but sparse. It explains the resource, paging, filters, and ID usability, but does not fully describe the return shape or filtering match behavior.

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 only 22%, so the description needs to compensate. 'Filter by any field' gives meaning to the seven optional string filter parameters, and 'Paged' maps to `page`/`per_page`, but no field-specific semantics or matching behavior are explained.

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 and resource: 'List the address book' of 'saved addresses with ids usable as `to` / `from`.' This clearly distinguishes it from read/write siblings like `shipcloud_get_address` and `shipcloud_create_address`, though it does not explicitly name those alternatives.

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 says 'Filter by any field' and 'Paged,' which implies filtered listing, but it does not state when to use this tool instead of `shipcloud_get_address`, `shipcloud_get_default_address`, or `shipcloud_create_address`. No when-not guidance or prerequisites are provided.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so safety is covered. The description adds value by disclosing the shape of the returned data (services, package types, additional services, label formats per service) and the underlying endpoint, which is important since no output schema exists.

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: the first front-loads what the caller gets, the second states the downstream use, followed by the endpoint. No filler and no repetition of the title.

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, read-only list call with no output schema, the description carries the full burden of telling the agent what comes back and why it matters, and it does so in enough detail to act on.

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 zero parameters, so there is nothing for the description to disambiguate. The baseline for a no-parameter tool applies, and nothing in the text misleads about 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 the specific resource (carriers available to this account) and enumerates the payload it carries: services, package types, additional services, and label formats per service. No sibling tool covers carriers, so the agent can select it unambiguously even without an explicit 'not X, use Y' clause.

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 clause 'Use the values when creating shipments' gives a downstream purpose, implying this is reference data to fetch before shipment creation. However, it does not state when the call is unnecessary (e.g. cached values) or name an alternative source, so the guidance 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful context about payload content (line items) and cross-entity linkage, but says nothing about how many orders come back or whether the response is paginated — a notable gap for an unfiltered list call.

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 front-loaded sentence carrying the scope, payload contents and linkage, followed by a short endpoint reference. Compact and waste-free, though 'GET /orders.' adds little for an agent that already knows this is a read 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?

With no output schema and no parameters, the description carries the burden of saying what comes back, and it does (orders with line items, keyed by order_id). The only missing piece an agent would want is expected result volume / pagination behavior.

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 zero parameters, so the schema has nothing to explain and the baseline of 4 applies. The description correctly implies no filtering or arguments are accepted.

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 ('List orders sent to shipcloud') and adds substantive scope detail: order data includes line items, is used by the Return Portal, and links to shipments via order_id. This distinguishes an order from a shipment or tracker among the many list_* siblings, though it never explicitly contrasts itself with shipcloud_get_order.

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?

Usage is only implied by the verb 'List' and the note that orders are linked to shipments by order_id, which hints that per-order detail belongs in shipcloud_get_order. There is no explicit when-to-use/when-not statement, and nothing about result size or pagination for a tool with zero filter parameters.

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?

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by naming the returned fields and the underlying GET endpoint, though it does not mention pagination, rate limits, or authentication requirements.

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 resource and returned fields, then adds the endpoint path as compact supporting detail.

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 parameterless read-only list tool with annotations covering safety, the description gives enough context to invoke it correctly and summarizes the return content since no output schema exists. The main omission is pagination or result-limit behavior, which would matter for a list endpoint.

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 has zero parameters, so the baseline score is 4. The description appropriately does not invent parameter details, and the empty input schema is consistent with a parameterless list endpoint.

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 and resource: it lists carrier pickup requests and enumerates the included data fields. This clearly separates it from get_pickup_request and create_pickup_request, though it does not explicitly name those siblings as alternatives.

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 says what the tool lists but gives no guidance on when to use it versus alternatives such as get_pickup_request, nor any preconditions or exclusions. The usage is implied by the verb 'List' but not explicitly framed.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds genuinely non-obvious behavior: shipcloud returns no totals so next_page is a guess, and a full page suggests more results. That is exactly the kind of caveat an agent needs to page safely and avoid trusting a terminal empty page.

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 resource and return payload, then the paging caveat; nearly every clause carries information. The trailing 'GET /shipments' is low value for an agent and the paging sentences are slightly run-on, but there is no padding overall.

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 13 optional params and no output schema, the description compensates by enumerating returned fields and explaining the pagination heuristic, which covers the main risks of calling this tool. It stops short of clarifying ordering/filter interaction with page number (e.g. whether filters reset paging), which is the remaining gap.

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 85%, so most of the 13 parameters are self-documenting, and the baseline is 3. The description reinforces that filters are combinable and explains the page-chaining convention, but adds no syntax or interpretation beyond what the schema already states for each field.

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 (list shipments) and enumerates the payload an agent can expect (carrier, service, price, tracking number/URL, label URL, addresses, tracking events), which is more than the title gives. It does not explicitly distinguish itself from shipcloud_get_shipment or shipcloud_list_trackers, so sibling routing is left to inference.

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?

'Filters can be combined' and the paging instruction give operational context, and 'newest first as shipcloud returns them' sets ordering expectations. However, there is no statement of when to use this list versus shipcloud_get_shipment (single lookup) or shipcloud_list_trackers, and no mention of prerequisites. Usage is implied rather than routed.

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?

Annotations already cover read-only, non-destructive, open-world, so the description's added value is the domain precondition (own carrier contracts) and the fact that returned data includes status and tracking events. Pagination/result-limit behavior for a list endpoint is not 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?

One dense sentence plus the endpoint path, front-loading the resource and then the defining scope caveat. No filler or restatement of the title.

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, the description usefully previews the return content (status and tracking events) and the eligibility constraint. The main missing piece for a list tool is whether results are paginated or bounded.

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 zero parameters, so there is nothing for the description to disambiguate; baseline for a no-param tool applies. The description adds no parameter-level confusion.

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?

Specific verb ('List') and resource ('trackers'), plus a precise scoping definition: shipments created outside shipcloud tracked via the carrier's tracking number. That scope cleanly separates it from shipcloud_list_shipments, though it does not name the get_tracker/create_tracker 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?

Gives a clear applicability rule — only trackers for shipments created outside shipcloud and only for your own carrier contracts — which tells an agent when this list is meaningful versus the shipment list. It stops short of explicitly naming alternatives or stating when not to call it.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds non-obvious context worth having: credentials of a webhook are never exposed in the response, and the underlying endpoint is GET /webhooks. It does not mention pagination or response envelope shape.

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 compact sentences plus the endpoint reference; every clause carries information (fields returned, credential-hiding behavior, method/path). Front-loaded with the verb+resource, no filler or restated title.

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 no-argument read tool with no output schema, the description supplies the key facts an agent needs: what record fields come back, that secrets are withheld, and the HTTP endpoint. Only pagination and result ordering are left unaddressed.

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 zero parameters, and the description correctly implies an account-wide, unfiltered listing rather than suggesting optional filters. Baseline 4 applies for a no-parameter tool.

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 (list webhooks in the account) and enumerates what is returned (target URL, event types, deactivated flag). It is distinguishable from sibling list_* tools by resource, though it doesn't say what a webhook is used for beyond the field 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?

Usage is only implied: an agent can infer this is the discovery call for webhook configuration. There are no explicit when-to-use/when-not conditions, no prerequisites, and no sibling routing (none of the listed siblings is a webhook tool, so there is little to route against).

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