Zineps

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

With no annotations, the description carries the full behavioral burden, and it discloses only two facts: the operation is scoped to the signed-in partner, and the password must satisfy 'portal rules'. It says nothing about permissions required, whether a duplicate email is rejected or merged, whether the merchant is notified, or whether the call is idempotent — significant gaps for a creation mutation.

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 with zero filler, and the creation intent plus tenant scope are front-loaded. It is not padded, though it is arguably under-specified rather than genuinely concise.

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

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

For a five-parameter mutation with no annotations and no output schema, the description covers only the two required fields and omits optional phone/country/intentId, side effects, and error behavior. It is minimally adequate but leaves the agent to rely entirely on the schema for anything beyond the happy path.

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 five parameters, establishing a baseline of 3. The description adds only the password-policy constraint, and it ignores the workflow-significant intentId parameter (tied to RecordUserQuestion) that the schema names but does not explain in context.

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 ('Create a merchant') and scopes it to the signed-in partner, which is enough for an agent to distinguish it from rate/surcharge/label siblings. It does not explicitly name a related alternative such as LookupCustomer or explain the customer-vs-merchant naming, so it stops short of full sibling differentiation.

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

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

The description notes prerequisites ('Requires email and a password') but gives no when-to-use guidance, no when-not-to-use, and names no alternative tool. An agent cannot tell from this text whether AddCustomer is the right call versus LookupCustomer or any other customer-related sibling.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure for a mutation tool. It discloses one precondition on organisationId, but says nothing about side effects, what happens on duplicate/conflicting rates, required permissions, or whether the operation is reversible.

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 the action and the key precondition, with zero filler. It is efficient, though for a 9-parameter mutation the brevity shades into under-specification rather than tightness.

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

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

Given a complex 9-parameter, 5-required mutation with no annotations and no output schema, the description is far too thin. It omits how the many numeric/string parameters interact and what the call returns or affects, leaving significant gaps an agent would need filled.

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

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

Schema description coverage is 0% across 9 parameters, so the description must compensate and largely does not. It only addresses organisationId (and its customer constraint); the meaning of marginType, amount, contractPrice, carrierContractId, carrierRouteId, and franchisePercentageMargin is left entirely undocumented.

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

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

States a specific verb+resource ("Add a customer-specific shipping rate") and the qualifier "customer-specific" meaningfully distinguishes it from the sibling AddPartnerRate. It stops short of explicitly naming alternatives, but the resource and scope are unambiguous.

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?

There is one useful precondition (organisationId must be a customer of this partner), but no explicit when-to-use guidance and no routing to alternatives like AddPartnerRate, UpdateCustomRate, or AddPartnerSurcharge. The agent must infer the distinction from the word "customer-specific" alone.

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

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

No annotations are provided, so the description carries the full burden. 'Add' implies a mutation, but nothing is disclosed about permissions, whether the rate can be modified afterward, side effects, or validation failures for an 8-parameter write operation.

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

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

Three short sentences, front-loaded with the action and scope, then the two most error-prone values. No filler; efficient for its size.

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

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

For a mutation tool with no annotations, no output schema, and 8 undocumented parameters, the description is far too thin. It omits prerequisites, expected results, and the meaning of most required inputs.

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

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

Schema coverage is 0% for 8 parameters, yet the description only clarifies two: marginType (sample values FixedAmount/Percentage) and carrierRouteId (how to obtain it). The remaining six, including required carrierContractId and amount, carry no meaning anywhere.

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 (Add) and resource (partner shipping rate), and the parenthetical '(not customer-specific)' distinguishes it from the AddCustomRate sibling. Clear and specific, though it could name the sibling directly for a stronger 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?

Provides one concrete usage aid ('Find carrierRouteId via get_carrier_routes') and bounds scope via the parenthetical, but never states when to prefer this over AddCustomRate or UpdatePartnerRate. Usage is implied rather than explicit.

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

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

No annotations are provided, so the description carries the full burden for a mutation tool. It does not state whether duplicate surcharges are rejected or merged, what permissions are required, whether the write is reversible, or what happens when marginType is invalid.

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 with the core action front-loaded and no filler. However, brevity here is partly under-specification rather than disciplined conciseness for a 9-parameter mutation.

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?

A 9-parameter write tool with no annotations and no output schema needs more: the intentId/RecordUserQuestion workflow, how to obtain carrierSurchargeId and marginType, and duplicate-handling behavior are all 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?

Schema description coverage is 100%, so the baseline is 3. The description's note that organisationId makes the surcharge customer-specific largely restates the schema's own 'Customer organisation id for a customer-specific surcharge', adding no new syntax or format detail.

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 a precise resource chain: a partner surcharge price for a carrier surcharge on a contract. It is distinguishable from AddPartnerRate, UpdatePartnerSurcharge and SearchCarrierSurcharges, but it never names or contrasts those siblings 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?

No when-to-use, when-not-to-use, or prerequisite guidance. An agent is not told that carrierSurchargeId comes from SearchCarrierSurcharges/GetPartnerCarrierSurcharges, that carrierContractId comes from ListContracts, or that UpdatePartnerSurcharge is the alternative for modifying an existing entry.

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

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

No annotations are provided, so the description carries the full behavioral burden. It only defers to an external API doc ('same rules as DELETE /api/Labels/{labelId}') without stating whether the cancellation is reversible, what happens to billing/refunds, what errors occur if the carrier already collected, or what authorization is required. Referencing off-tool documentation is not usable disclosure.

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 front-loaded sentence that leads with the action and immediately follows with the gating condition. No filler or redundancy.

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, annotation-free mutation with no output schema, the description conveys the crucial precondition but omits reversibility, failure behavior, and auth requirements. The fully documented schema covers inputs, leaving the behavioral gaps as the main shortfall.

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 both labelId and the optional intentId (from RecordUserQuestion) are already documented in the schema. The description adds no additional meaning about either parameter, 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?

States a specific verb and resource (cancel a label) plus a key precondition (carrier has not collected yet), which distinguishes it from read siblings like GetLabel and from RemakeLabel. It does not explicitly name or contrast a 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?

The precondition 'carrier has not collected yet' implies when this is valid and implicitly when it is not, but no alternative tool (e.g. RemakeLabel, ReplyToTicket for support escalation) is named for the case where the label is already collected. 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?

No annotations are provided, so the description carries the full behavioral burden. It discloses one precondition state but omits whether the call purchases/charges postage, whether it is idempotent or fails when a label already exists, permission requirements, and what artifact comes back — significant gaps for a mutation tool.

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

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

Two short sentences, zero filler, with the action front-loaded and the precondition following. Nothing to trim.

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-annotation, no-output-schema write tool, the description covers the essential precondition but leaves the post-call behavior and failure modes unstated. Adequate to attempt a correct invocation, not complete enough to predict the outcome.

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 both parameters (orderId, intentId) are documented in the schema itself. The description adds no parameter-level detail 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?

States a specific verb ('Create') and resource ('shipping label') scoped to a Zineps order, which distinguishes it from retrieval siblings like GetLabel/FindLabel. It does not explicitly contrast with RemakeLabel, the closest alternative, 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?

The prerequisite ('order must already have carrier contract and product selected') is genuinely useful gating context. However, there is no guidance on when to choose this over RemakeLabel, or what to do if a label already exists — usage is implied 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?

With no annotations, the description carries the full burden and does reasonably well: it discloses a side effect ('writes LabelLog entries'), the return payload ('JSON request/response bodies'), and a hard precondition (carrier contract + product selected in the Shipping snapshot). It omits auth/permission requirements and whether the live call incurs cost or rate limits.

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 what the tool does, then return/side-effect behavior, then the prerequisite. No filler; each sentence carries distinct 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 side-effecting, no-annotation tool with no output schema, it covers purpose, precondition, return shape, and side effects. The remaining gap is auth/permission expectations and failure behavior, which is minor but non-trivial for a live external carrier 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 three parameters are already fully documented in the schema. The description only references the draft ID conceptually and adds no format or intentId semantics beyond what the schema provides. 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: 'Call the carrier live rates API for a user's shipment draft'. It is clearly distinguishable from data-listing siblings, though it does not explicitly name a contrasting sibling. The parenthetical precondition sharpens the scope further.

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 clear prerequisite workflow: 'Use GetShipmentDraftsForUser and GetShipmentDraft first to find the draft ID', naming the alternatives to run beforehand. It stops short of stating when NOT to use it versus a non-debug rate lookup, so not a full 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?

With no annotations provided, the description carries the full burden, and it does add real behavioral context: the return is base64 bytes, two formats are offered, and large labels may truncate in JSON. It stops short of stating whether the operation is idempotent, whether regeneration has cost/side effects, or how failures (missing label) surface.

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 clauses with no filler. The core action and output format are front-loaded, and the caveat plus alternative follow immediately without redundancy.

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 describing the return shape (base64 PDF/ZPL) is valuable, and the truncation warning covers an important edge case. Minor gaps remain around failure modes and whether re-creation is safe to repeat.

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 both labelId and intentId (including its connection to RecordUserQuestion) are already documented in the schema. The description adds no parameter-level detail beyond what structured data provides, making the baseline 3 correct.

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

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

The description states a specific action and resource: re-create label bytes for download, with the output formats (PDF or ZPL as base64) named explicitly. It does not, however, differentiate itself from close siblings like GetLabel, FindLabel, or RemakeLabel, which an agent could easily confuse with this tool.

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?

"use portal for bulk" gives one clear when-not condition, which is genuinely useful. But there is no guidance on when to pick this over GetLabel/FindLabel/RemakeLabel, so the routing decision among siblings 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?

No annotations are provided, so the description carries the full burden. It helpfully discloses the surprising multi-match behavior of numeric queries and how to disambiguate, but says nothing about read-only nature (only implied by 'Fetch'), auth/shop credential requirements, or failure modes for a tool hitting a live external API.

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 core purpose and then packs disambiguation and routing details into a dense but mostly information-bearing block. A few clauses overlap (the multiple-match note is restated), but there is little filler.

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

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

For a 7-parameter, no-annotation tool with no output schema, the description covers the tricky parts an agent needs: source systems, disambiguation strategy, and conditional parameter usage. It stops short of describing the returned order shape or error behavior, which leaves some completeness gap given 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?

Schema coverage is 100%, so baseline is 3, and the description adds real meaning: concrete shopId example (2508), the externalOrderId-vs-prefixed-display-number distinction (Creme10129), and the use of recipientName/organizationQuery for disambiguation. However it references 'externalOrderId' and 'ordernumber_full' which do not appear as schema properties, introducing naming 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?

States a specific verb and resource with scope: 'Fetch an order from the live webshop API ... by order number or external order id,' and explicitly names the sibling it is not for (GetShopifyOrderLineItems). Slightly muddled by listing Shopify as a supported source while telling the agent to use it for WooCommerce/CCV shops, which blurs the boundary with the Shopify-specific tool.

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 ('Use for WooCommerce/CCV shops, not GetShopifyOrderLineItems') plus conditional guidance: provide shopId when known, organizationQuery when the shop is unknown, recipientName when the number matches multiple shops. It doesn't address when to prefer this over the sibling FindOrder, but the primary selection condition is clear.

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. 'Find' implies a safe read and the org-scope note clarifies the search boundary, but the description says nothing about permissions, result shape, or pagination behavior (despite a limit parameter).

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 with the primary purpose front-loaded and the scoping caveat second. 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 4-parameter tool with no annotations and no output schema, the description is adequate but thin. It never explains what an invoice record contains or how intentId from RecordUserQuestion should be used, leaving meaningful gaps for an agent calling it unsupervised.

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 all four parameters (query, limit, intentId, unpaidOnly) are already documented in the schema. The description restates the query keys without adding format, syntax, or edge-case guidance, which is the correct baseline when the schema does the heavy lifting.

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 ('Find customer invoice(s)') plus the two lookup keys (invoice number or customer email), which is enough to distinguish it from LookupCustomer or InvoiceInvestigation at a glance. It stops short of explicitly naming those siblings, so it lands at 4 rather than 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?

'No organisationId needed' tells the agent a required scoping input is absent, which is useful usage context. However, there is no explicit when-to-use statement or routing to InvoiceInvestigation, which appears to be the closest alternative for invoice problems.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing: whether results are paginated, what fields are returned, how the lookup behaves on partial or ambiguous matches, or whether it is strictly read-only. 'Find' implies a read, but that is inferred, not stated.

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 tight sentence with the resource front-loaded and the accepted identifiers following. It wastes no words, though the terseness is partly what leaves the behavioral and routing gaps open.

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 three-parameter read tool with no output schema and no annotations, the description does the minimum: it explains what can be searched but not what comes back or how results are capped. Adequate but clearly incomplete for a tool embedded in a dense family of label lookups.

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 each parameter is documented in the schema, including the default limit and the intentId source. The description restates the query key options rather than adding format or syntax detail beyond the schema, so the baseline of 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 specific verb ('Find') and resource ('shipping labels') plus the lookup keys it accepts, so an agent understands the operation immediately. However, it does not distinguish itself from several near-siblings such as SearchShippingLabels, GetLabel, ListRecentLabels, or LookupByTrackTrace, leaving the agent to guess which finder to use.

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 lists accepted query inputs but gives no guidance on when to use this tool versus the many overlapping lookup siblings. There are no stated prerequisites, exclusions, or conditions that route the agent to an alternative.

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 burden and usefully discloses non-obvious search behavior: numeric queries can match both externalOrderId and prefixed display numbers such as Creme10129. It also explains that shopId limits to one shop and recipientName disambiguates, but it does not describe return shape, permissions, or default search scope explicitly.

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

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

The description is front-loaded with the core purpose and alternative tool, then adds compact behavioral details. It is appropriately sized, though the recipientName reference is questionable and slightly weakens an otherwise efficient 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?

For a five-parameter search tool with no output schema and full schema description coverage, the description covers the main search modes, the key sibling alternative, numeric matching behavior, and result-limiting guidance. It omits some context around intentId and permissions, but the core invocation needs are addressed.

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 schema already documents limit, query, shopId, intentId, and openOnly. The description adds valuable query-matching semantics and shopId/disambiguation guidance, but it references a recipientName parameter that does not appear in the schema, while intentId is only covered by the schema description.

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: find orders in Zineps by order number, track & trace, or recipient email. It also explicitly distinguishes itself from the sibling FetchWebshopOrder for live webshop data, so an agent can route correctly 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 gives an explicit alternative tool and the condition for using it: use FetchWebshopOrder instead for live Shopify/WooCommerce/CCV Shop data. It also specifies when to use shopId to limit results and recipientName to disambiguate, leaving little inference for the agent.

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

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

No annotations exist, so the description carries the burden, and it does disclose two useful facts: no organisationId is required and it returns a user profile plus quick stats. It does not cover auth needs, rate limits, or whether results are truncated by limit, leaving a few gaps for an unannotated 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 short sentences, front-loaded with purpose, then routing guidance, then scope and return note. No filler and nothing buried.

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 notes the return shape (profile and quick stats), and with no annotations it flags the organisationId independence. Minor gaps remain around the intentId workflow and how limit interacts with ranking, but the core calling 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?

Schema coverage is 100%, so the schema already documents query, limit, and intentId. The description's restatement of 'email, company name, or person name' largely duplicates the query description without adding matching behavior or precedence rules, so 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 specific verb and resource ('Find a customer/user') and lists the identifier types that locate the record. It attempts differentiation by naming SearchUsers, but that is not one of the actual sibling tools (LookupCustomer is), so the routing help is partly aimed outside the visible toolset.

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?

'Prefer this over SearchUsers when you have a specific identifier' gives a clear when-to-use condition and names the alternative. It lacks exclusions against the real sibling LookupCustomer and gives no guidance on when the limit/intentId parameters matter.

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

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

No annotations are provided, so the description carries the full burden. It discloses data scoping (merchant vs partner, own organisation restriction) and date format, but says nothing about permissions required, result size, caching, or whether the response is a snapshot. For a read-only analytics endpoint the omission is moderate rather than severe.

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 dense sentences covering outputs, date format, and audience-scoping logic with no filler. The content is front-loaded and efficient, though the second sentence packs routing rules that could be slightly more structured.

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

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

For a 4-parameter, no-output-schema analytics tool with no annotations, the description covers scoping and date format but leaves return shape and volume unspecified. An agent knows what to pass but not what to expect back, which is a notable gap given the lack 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?

Schema coverage is 100%: every parameter already has a description including defaults and formats. The description adds only the yyyy-MM-dd format reminder and the partner-specific organisationId rule, which the schema already states. Baseline 3 is appropriate when the schema does the heavy lifting.

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 (analytics) and resource (shipments), and enumerates the concrete outputs: order/label/return counts, chart, carrier mix, shop/customer mix, and delivery performance. It also distinguishes the merchant vs partner use case. The only gap is that no sibling tool overlaps meaningfully, so no explicit differentiation is needed.

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?

Clearly explains when to use it for each audience: merchants get their own data, partners pass a single customer organisation id or omit it for the whole book. This routing logic is actionable. It stops short of naming a sibling alternative (e.g., PartnerSummary, SummarizeUsageRecords) that an agent might otherwise confuse for analytics.

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

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

No annotations are provided, so the description carries the full burden. 'Resolve...to lane details' strongly implies a read-only lookup with no side effects, which is adequate for a low-risk resolution tool, but it never states that explicitly, nor does it mention permissions, rate limits, or behavior for unknown/invalid route IDs.

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: the first front-loads what is returned, the second covers when to call it and how to pass input. No filler, no restatement of the tool name.

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 enumerates the returned lane fields, and both parameters are schema-documented. It is nearly complete for a 2-parameter lookup; only the absence of any note on invalid/missing route IDs or the role of the optional intentId keeps it from a 5.

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

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

Schema description coverage is 100%, so the schema already documents both parameters. The description restates carrierRouteIds as 'one or more numeric route IDs, comma-separated', which matches the schema's own text and adds no new syntax or edge-case guidance; 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 specific verb ('Resolve') and resource ('carrier route IDs to lane details'), and enumerates exactly what a lane contains: carrier, product code, origin/destination countries, weight band. This is specific enough that an agent can distinguish it from sibling lookup tools like LookupByTrackTrace or PartnerSummary 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 explicit sequencing ('Use after GetPartnerCarrierRates when you need to map carrierRouteId values to lanes') plus a concrete scenario (NL→LK UPS Express). It lacks when-not-to-use or an explicitly named alternative, which keeps it out of the top band.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it says nothing beyond the return fields. It does not state that this is a read-only lookup, what happens when the labelId is unknown, or any permission/rate constraint. 'Full details' is the only behavioral hint, and it is weak.

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

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

A single sentence with zero filler, front-loading the identity of the resource and then the value it returns. Nothing could be trimmed without losing 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?

With no output schema, the field enumeration usefully tells the agent what comes back, and the two-parameter surface is simple. However, in a toolset containing FindLabel, GetLabelsForOrder, ListRecentLabels, and get_label_log, the description never positions this tool, which is the main completeness 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 description coverage is 100%, so both parameters are already documented in the schema (labelId as 'Label usage id (integer)', intentId tied to RecordUserQuestion). The description restates the label-id concept but adds no format, sourcing, or usage nuance for intentId, 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?

States a specific verb and resource ('Full details for one label usage id') and enumerates the payload (order link, carrier, contract, product), which is more than a restatement of the name. It does not distinguish itself from close siblings like FindLabel, GetLabelsForOrder, or SearchShippingLabels, so an agent must guess which retrieval tool applies.

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?

There is no guidance on when to use this versus the many sibling lookup tools (FindLabel, GetLabelsForOrder, ListRecentLabels, InvestigateLabelByTrackTrace). The phrase 'one label usage id' hints at single-item lookup, but the agent is left to infer the selection rule entirely.

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 burden well: it discloses that bodies are redacted, capped at 100 KB each, and that Admin/Superuser access is required. It omits an explicit read-only statement and error/not-found behavior, but the key operational traits are surfaced.

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 what is returned, then the id provenance, then the access requirement. No filler; 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 single-item getter with no output schema and full schema coverage, the definition covers return content, id sourcing, and access control. Minor gap: no mention of behavior when the log does not exist or the optional intentId's role.

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 both parameters are already documented. The description adds mild value by mapping the id to 'labelLogId' and naming its source tools, but does not explain the optional intentId, so the baseline 3 is appropriate.

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

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

States a specific verb (Get), a precise resource (one label creation HTTP log), and the scope constraint (by id, singular). 'One ... by id' cleanly distinguishes it from the sibling search_label_logs, which handles the plural/search case, without needing to open 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 tells the agent where to obtain the required id ('Use labelLogId from LookupByTrackTrace or GetUsageRecordsForUser') and states the access prerequisite (Admin or Superuser). It stops short of naming when-not-to-use or pointing to search_label_logs as the alternative, so it is clear context but not full 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?

No annotations are provided, so the description carries the full behavioral burden. 'List' implies a read operation, but nothing is disclosed about permissions, pagination, ordering, or whether results are capped, which is a notable gap for a list endpoint.

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 front-loaded sentence with no waste. It is efficient, though its brevity contributes to the gaps in behavioral detail rather than resolving them.

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

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

For a simple two-parameter read tool with no output schema, the description is minimally adequate but leaves return contents, ordering, and pagination unknown. With no annotations to fall back on, a bit more behavior would help.

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 orderId and intentId are already documented in the schema. The description restates orderId semantics ('WebOrder id / GUID') but adds nothing about intentId or the intent/record flow. 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 specific verb ('List') and resource ('labels created for a Zineps order'), with the 'for a Zineps order' scope distinguishing it from siblings like ListRecentLabels or GetLabel. It does not explicitly name the alternatives, keeping it 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?

Usage is only implied: an agent can infer it is used when an order GUID is in hand and the labels for that order are wanted. No when-to-use condition, prerequisites, or named alternatives (e.g., vs FindLabel or SearchShippingLabels) 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?

With no annotations, the description carries the full behavioral burden. It hints at return content (status + recent events) but says nothing about whether data is live or cached, how far back 'recent' extends, whether authentication or carrier credentials are needed, or how extensive the event list is.

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 front-loaded sentence with no filler; the resource and scope come first. It is efficient, though the brevity leaves gaps that a second sentence could cheaply close.

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 read with no output schema, the description at least signals the return content, which is more than nothing. However it omits pagination/volume expectations and any auth or freshness context, leaving meaningful gaps for an agent deciding how to use the result.

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

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

Schema description coverage is 100%, so both labelId and intentId are already documented in the schema, making 3 the baseline. The description restates 'label usage id' but adds no format, range, or source detail, and ignores intentId entirely.

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 resource and scope: carrier tracking status plus recent tracking events, keyed on a label usage id. An agent can tell roughly what it returns, but the description never distinguishes it from near-neighbors like GetShipmentStatus, GetLabel, or get_label_log.

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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives despite several plausible overlapping siblings (GetShipmentStatus, LookupByTrackTrace, get_label_log). Usage must be inferred entirely from the resource name.

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. "Return" and "authenticated user" imply a read-only, auth-required operation, but the description says nothing about permissions needed, rate limits, or whether partner data is scoped to the caller. It adds some behavioral context (auth binding) but leaves key traits unstated.

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 with the primary capability front-loaded, followed by sequencing and an alternative-tool pointer. No filler, though the phrasings are slightly clipped.

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-param, no-annotation, no-output-schema tool the description only sketches the return payload at a high level; "partner context" and "user list for partners" are not concrete enough for an agent to know what shape of data to expect. It is minimally viable but does not fully compensate for the missing 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 schema defines zero parameters, so there is nothing to document and no ambiguity to resolve. This is the baseline for a no-argument tool and the description correctly implies no input is needed.

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 pairs a clear verb ("Return") with specific outputs: authenticated user scope, partner context, and the user list for partners. It is distinguishable from retrieval siblings like FindUser or PartnerSummary, though "partner context" remains vague about exactly what data is included.

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 explicit sequencing ("Call after RecordUserQuestion") and routes tool-selection questions to the sibling GetToolGuide. That is clear usage context, but it never states when this tool should NOT be used or how it differs from the user/partner lookup siblings.

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

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

With no annotations, the description carries the full behavioral burden and does disclose a real trait: per-partner visibility restriction ('Partners only see their own surcharges') and the underlying endpoint. It omits read-only confirmation, result ordering, and pagination behavior beyond the schema's limit default.

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 with no filler; the purpose is front-loaded and the usage hint plus permission constraint follow immediately. Every clause 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 seven-parameter read tool with no annotations and no output schema, the description covers purpose, filterable fields, a usage example, and access scoping. Return-format details are not needed (list semantics), but pagination and ordering behavior 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?

Schema description coverage is 100%, so the schema already documents all seven parameters with examples (e.g. amount=55 for €55). The description's mention of 'margin, contract, linked carrier products' loosely maps to amount, carrierContractId, and carrier, but adds no new syntax or semantics 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?

States a specific verb and resource ('List partner carrier surcharges') plus the resource path and the fields it returns (margin, contract, linked carrier products). It does not explicitly differentiate itself from the sibling SearchCarrierSurcharges, but the 'partner' scoping is clear enough to infer the distinction.

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

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

Provides concrete usage context with an example question ('are DPD surcharges correct for partner X?') and a scoping rule ('Partners only see their own surcharges'). It stops short of naming when to prefer the sibling SearchCarrierSurcharges, so no explicit exclusions 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?

With no annotations, the description carries the full behavioral burden, and it does disclose a non-obvious trait: the carrier status is refreshed only when older than 12 hours, implying cached/stale reads and possible upstream carrier calls. It omits permissions, failure behavior, and cost/latency implications of that refresh.

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, front-loaded with the scope before the refresh nuance. The endpoint-mapping clause is marginally useful for developers but is the weakest-earning sentence for an agent.

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-resource read with a 2-param, fully documented schema and no output schema, the description covers scope, staleness semantics, and the underlying endpoint. Missing only explicit sibling routing and error/empty-state 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 coverage is 100%, so both parameters are already documented. The REST mapping ('GET /api/Labels/Status/{labelId}') confirms labelId is the path key, but adds no format, range, or intentId usage guidance 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+resource ('current shipment status') and scopes it to 'one label', which implicitly separates it from the plural sibling GetShipmentStatuses. It does not name that sibling explicitly, so differentiation relies on the reader inferring it from the singular/plural distinction.

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?

No explicit guidance on when to use this versus GetShipmentStatuses, GetLabelTrackingStatus, or GetLabel, all of which are adjacent in the sibling list. The 'when older than 12 hours' clause describes internal refresh behavior, not a usage condition for the caller.

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. It usefully discloses the out-of-scope behavior ('Ids outside your scope are returned as notFound') and hints at caching/refresh via a pointer to GetShipmentStatus, but defers the actual refresh rules rather than stating them, and says nothing about auth or return 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?

Three short, front-loaded sentences with no filler; the scope, refresh pointer, and error behavior each occupy one clause. The middle sentence is slightly hand-wavy but not 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 simple read tool with no output schema and no annotations, it covers the essentials (input cap, out-of-scope handling) but leaves the refresh/caching behavior to an external reference and says nothing about the response format an agent would need to interpret results.

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 schema already documents both parameters; baseline 3 applies. The description's 'up to 100 label ids' merely restates the schema's 'max 100' and it never mentions intentId.

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 ('Shipment status for up to 100 label ids') and implicitly positions itself as the batch counterpart to the singular GetShipmentStatus. The batch scope and cap distinguish it, though it relies on the sibling for the actual refresh semantics.

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?

No explicit when-to-use guidance: it never says to prefer this over GetShipmentStatus when querying multiple labels, nor does it state exclusions. The reference to 'Same refresh rules as GetShipmentStatus' presumes the caller already knows that tool, but doesn't route between them.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose return content (the raw GraphQL fields, including a resolved material) and clarifies the id semantics, which is genuine added value absent an output schema. It stops short of disclosing auth/permission needs, rate limits, or behavior when the order or shop id is invalid, so the burden is only partly met.

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 payload description front-loaded and the identifier guidance second. The field list is dense but scannable; the only mild cost is that it reads as a comma-stuffed inventory rather than a structured list.

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 fetch with no output schema, listing the returned attributes is exactly the right compensation, and identifier semantics are covered. Missing is whether the result is a collection, how large orders are paginated, and what happens on a not-found order, which are the remaining gaps for an agent to call it confidently.

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, but the description goes beyond by giving a concrete order-number example (BU741087) that demonstrates the accepted format, and it explicitly ties shopId to the ApiCredential.Id concept. It leaves intentId (from RecordUserQuestion) entirely unexplained in the prose, which keeps it from a 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 (Fetch) and a precise resource (raw Shopify GraphQL line items for an order), then enumerates the returned attributes (product, variant, SKU, customAttributes, product-linked flag, resolved material). This clearly separates it from siblings like GetLabelsForOrder, FetchWebshopOrder, and FindOrder 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?

Gives usable invocation guidance (supply shopId as ApiCredential.Id, accept either an order number like BU741087 or an external Shopify order id), which is implied 'how'. However, it never states when to prefer this tool over alternatives such as FetchWebshopOrder or OrderInvestigation, and offers no exclusions or preconditions.

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

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

No annotations are provided, so the description carries the disclosure burden. It clarifies this is an informational, zero-side-effect guide and explicitly steers away from data lookup, which is strong behavioral guidance. It stops short of describing the guide's output shape, keeping it below 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?

Three short sentences, front-loaded with the primary 'start here' instruction, followed by what it returns and a clear exclusion with the alternative. 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 zero-parameter, no-output-schema routing tool, the description tells the agent everything needed to invoke it correctly and where to go instead. Slightly more detail on the guide's contents would round it out.

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 to document and the schema is trivially complete. Baseline of 4 applies since no parameter semantics are needed.

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 purpose: it returns a decision guide for partners and admins, and signals via 'Start here' that it is a meta-routing tool rather than a data tool. It distinguishes itself from siblings like RecordUserQuestion and the investigation tools, though it doesn't spell out what the guide actually contains.

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 on when to use ('when unsure which tool to use'), when not to use ('Do NOT use for data lookup'), and the correct alternative path ('call RecordUserQuestion first, then an investigation tool'). This is close to ideal 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?

With no annotations the description carries the full behavioral burden, and it does disclose the rich payload (label metadata, DB vs Shopify line items, Nova Post invoice sent-vs-current comparison), which is genuine behavioral context. However it never states the operation is read-only, nor any permission, auth, or side-effect profile, leaving a real gap for a no-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?

Front-loaded with the core action, then a single dense sentence listing returned fields. Every sentence earns its place, though the field enumeration is packed and could be trimmed slightly.

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 compensates well by spelling out the returned data groups, which is exactly what an agent needs before calling. The remaining gap is the missing behavioral/safety profile that no annotation supplies.

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 both parameters are already documented by the schema. The description mentions the track & trace key only implicitly and adds no format or syntax detail (and nothing on intentId), so it does not go beyond the structured field. 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 specific verb+resource ('label/material investigation by track & trace') and then enumerates exactly what it surfaces, which clearly separates it from LookupByTrackTrace (plain lookup), InvoiceInvestigation and OrderInvestigation. An agent can tell what it does and how it differs from siblings 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?

'Prefer this for customs/material disputes' gives an explicit scenario that selects this tool over the plain track & trace lookups. It stops short of naming alternatives or stating when NOT to use it, so it is clear context rather than full 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?

With no annotations, the description carries the full burden. It does disclose the return content (header, line items, label count, surcharges), which substitutes for a missing output schema and implies a read-only operation, but it says nothing about permissions, rate limits, or side effects.

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

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

A single dense sentence that front-loads the keying parameter and lists returns compactly, with no filler. The fragment style is telegraphic but every clause carries 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?

The description usefully covers the return payload in the absence of an output schema, but with no annotations it omits behavioral context such as safety, permissions, and how it relates to the sibling FindInvoice. Adequate but with clear gaps.

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

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

Schema description coverage is 100%, so both parameters are already documented (invoiceNumber as customer invoice number, intentId from RecordUserQuestion). The description adds no format or edge-case detail beyond 'by invoice number', 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?

States a specific resource (invoice) and enumerates the payload it returns — header, line items, label count in period, related surcharges — which is more than a restated name. It does not explicitly differentiate itself from the sibling FindInvoice, leaving the agent to infer 'deep-dive' vs simple lookup.

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 'deep-dive by invoice number' implies a fuller investigation than a plain lookup, which hints at when to prefer it over FindInvoice, but no alternative is named and no when-not conditions 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?

With no annotations, the description carries the full behavioral burden. The parenthetical "same data as GET /api/Brands" weakly implies a non-mutating read, but it says nothing about permissions, whether results are paginated or filtered by organisation, or result size limits.

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 short sentence with the resource front-loaded and zero filler. It is efficient, though arguably so terse that it borders on under-specification rather than deliberate conciseness.

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

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

There is no output schema, so the description is the only place an agent could learn what a brand record contains or how results are shaped, and it does not say. No pagination, ordering, or error behavior is described either.

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?

Both parameters are fully documented in the schema (intentId provenance, organisationId defaulting to the signed-in organisation), so coverage is 100% and the baseline is 3. The description adds no meaning beyond the schema, which is acceptable here since nothing is left undocumented.

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

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

The description states the resource and its scope ("brands for the company"), and the name supplies the verb "List". However, it gives no differentiation from sibling list tools like ListContracts, ListSenders, or ListShippingMethods, leaving purpose clear but generic.

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?

There is no statement of when to use this tool, when not to, or what alternatives exist. An agent gets no routing guidance at all, which matters in a 47-tool set with several other List* tools.

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

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

With no annotations, the description carries the full burden. It does add real value by disclosing a security-relevant trait ('Does not return API keys or passwords') and mapping the tool to a REST endpoint, but it never states that this is a safe read-only operation, nor does it mention pagination, result limits, or permission 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?

Two short sentences with the resource identified first and the security caveat second. Every clause earns its place and nothing is 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 two-parameter read tool with no output schema and no annotations, the description covers what is returned and what is deliberately excluded, which is the core need. It remains thin on return shape and pagination, leaving gaps an agent would have to discover empirically.

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 both parameters (intentId, organisationId) are documented in the schema, so the baseline of 3 applies. The description adds no parameter-level meaning, such as how organisationsID interacts with the default signed-in organisation.

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 resource ('Carrier contracts the company can ship with'), which is concrete enough to separate it from sibling list tools like ListBrands, ListSenders, or ListShippingMethods. It stops short of naming any sibling explicitly, so it is clear but not fully differentiated.

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?

There is no when-to-use / when-not-to-use guidance and no mention of alternatives. The 'same data as GET /api/Contracts' note implies it is the read path for contracts, but the agent is left to infer the trigger conditions on its own.

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 it does disclose two meaningful traits: results are scoped to the caller's tenant ('in your scope') and ordered newest first. It stops short of covering the read-only/safety profile, pagination or truncation behavior beyond limit=100, or what happens when no labels match.

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, zero filler, and the core purpose plus ordering is front-loaded before the workflow hint. Nothing could be removed without losing 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 zero-required-parameter, four-optional-parameter list tool, the description covers purpose, ordering and scope, but with no annotations and no output schema it leaves the result shape (what fields a label entry carries) and pagination limits unexplained. Adequate to invoke correctly, thin on what the agent gets back.

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 all four parameters (limit, carrier, dateFrom, intentId) are already documented with defaults and formats. The description adds no syntax or format detail for any of them; 'in your scope' only hints at an implicit scope filter not exposed as a parameter. Baseline 3 applies when the schema does the heavy lifting.

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 recent shipping labels) plus two real qualifiers: scope-limited ('in your scope') and sorted newest first. That is far more precise than siblings like GetLabel or FindLabel, though it never explicitly contrasts itself with SearchShippingLabels or GetLabelsForOrder, so sibling differentiation is only partial.

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 one concrete usage hook — 'Use before batch RemakeLabel' — which tells the agent this is a discovery step preceding a bulk re-creation flow. However, there is no when-not guidance and no indication of how it differs from SearchShippingLabels or FindLabel for the same discovery need, so selection between alternatives 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 disclosure burden. Referencing 'the same data as GET /api/Senders' usefully signals a side-effect-free read, but nothing is said about pagination, volume limits, required permissions, or whether the result is cached/filtered by signed-in organisation.

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 with the resource stated up front and the practical hint about 'Code' following it. The REST endpoint parenthetical is slightly incidental but cheap and aids recognition for agents that know the API surface.

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

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

For a simple two-parameter read tool with no output schema, the definition covers the gist but could do more: it names only one returned field ('Code') and omits when to call it relative to label creation, which is the main reason an agent would reach for 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 description coverage is 100%, so intentId and organisationId are already documented in the schema and baseline is 3. The description's mention of 'Code' actually describes a return field rather than either parameter, so it adds no parameter-level 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 names the resource (sender addresses for the company) and maps it to a concrete REST endpoint (GET /api/Senders), so an agent can tell it apart from siblings like ListBrands or ListContracts. It lacks an explicit verb, but 'Sender addresses for the company' communicates a list operation unambiguously.

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?

There is no explicit when-to-use or when-not-to-use statement. The trailing clause 'Code is the sender id used when creating a label' implies the tool's purpose (fetch sender IDs before label creation), but the agent must infer this rather than being told to call it ahead of CreateLabelForOrder.

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

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

No annotations are provided, so the description carries the full burden. It does disclose that this is a read operation ('same data as GET') and surfaces the meaningful output semantic that the product code feeds ProductCode at label creation, but it omits response shape, filtering behavior, and error/empty-result handling.

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 tightly packed sentences with the core purpose front-loaded and no wasted words; the parenthetical endpoint reference and the ProductCode linkage both earn their 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?

There is no output schema and no annotations, so the description should explain the return values more. It does provide the single most important output semantic (ProductCode for label creation), but for a 9-parameter listing tool it leaves the rest of the response structure and behavior unstated.

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 each of the 9 parameters is self-documenting in the schema. The description adds the label-creation meaning of the resulting product code but nothing about the input parameters, so 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 specific verb+resource ('Shipping methods available for a route') and pins the purpose by equating it to GET /api/Shippingmethods. Clear what it returns, but it doesn't differentiate itself from the similar sibling get_carrier_routes.

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 through the note that the product code is used as ProductCode when creating a label, which hints at the create-label workflow, but it never states when to prefer this over alternatives like get_carrier_routes or SearchParcelShops.

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 burden, and it does disclose the concrete return payload (usage records, matching orders, label surcharges, return orders) and that matching is exact. It does not mention permission needs or what happens on a non-match, so it is not fully exhaustive, but it adds genuine behavioral context beyond the structured 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?

Three sentences, zero filler, with the core capability front-loaded and the routing/exclusion guidance following. 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 lookup with no output schema and no annotations, the description usefully enumerates the return contents and disambiguates from siblings. It stops short of stating failure behavior or auth requirements, which for a 2-parameter read tool is a minor gap rather than a blocking one.

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 both parameters (trackTrace, intentId) are documented in the schema itself. The description reinforces the 'exact match' semantics of trackTrace but adds no format examples or edge-case guidance beyond that; baseline 3 applies when the schema does the heavy lifting.

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-call shipment investigation by exact track & trace') and enumerates what it returns (usage records, matching orders, label surcharges, return orders). This clearly separates it from the many other lookup/label tools in the sibling list.

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

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

Explicitly names two alternatives with the condition that selects each: LookupByTrackTraceBatch for CSV/bulk billing reconciliation ('never call this per CSV row') and InvestigateLabelByTrackTrace for material/customs/line-item questions. This is exactly the when-to-use/when-not guidance an agent needs.

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; it discloses the batch cap (max 200) and the return shape (labels, orders, surcharges keyed by track & trace). It is silent on failure behavior for unknown/duplicate codes, whether results are partial, and auth requirements, which keeps it short of 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?

Two sentences, zero filler; the batch/scope fact, the use case, the prohibition, and the return contents are all front-loaded and non-redundant.

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 correctly summarizes returns, and it covers the batching contract and use case. Remaining gaps (ordering of results against input, handling of unmatched codes) are minor but leave a small amount an agent could still get wrong.

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, but the description adds a real constraint the schema omits: the array is capped at 200 codes. The intentId parameter is left to the schema's own description, so it does not reach 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 (batch lookup), resource (shipment by track & trace codes), and scope (many codes in one call, max 200). It is immediately distinguishable from the sibling LookupByTrackTrace, which it names.

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 ('carrier invoice / surcharge CSV reconciliation') and an explicit anti-pattern ('never call LookupByTrackTrace per row'), routing the agent to the correct tool with no inference required.

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 behavioral burden. It usefully discloses the breadth of data returned, implying an aggregated read, but says nothing about read-only safety, permissions/authentication, rate limits, or whether the lookup is fuzzy or exact. It adds context but is not complete.

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 compact sentence that front-loads the verb and identifiers before the payload list. Nothing is wasted. The trailing 'label stats' is terse to the point of ambiguity, which keeps it just under a 5.

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 return values, and it does list the categories of data returned, which is the minimum needed. Missing are match behavior (what happens on ambiguous or zero results) and any sense of result size or structure.

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

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

Schema coverage is 100% – both 'query' and 'intentId' are documented in the schema. The description echoes the identifier types but adds no matching semantics (exact vs partial match, precedence when multiple customers match) or guidance on intentId. Baseline 3 when the schema does the heavy lifting.

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 resource (customer) and the identifiers used to find it (email, company, name), then enumerates what the '360°' view contains: profile, orders, invoices, subscription, tickets, label stats. It is far more specific than a tautology. It does not, however, differentiate itself from any sibling, 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?

Usage is only implied: an agent can infer it should call this when it has an email, company, or customer name and wants a consolidated view. There is no explicit 'use this instead of X when Y', and no sibling is named even though the sibling list is long. Adequate but leaves routing 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?

No annotations are provided, so the description carries the full burden. It discloses the scope of returned data (an aggregation across usage records, payment orders, and tickets), which is genuinely useful, but never states that this is a read-only operation, whether it hits rate limits, or what permissions are needed.

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 front-loaded sentence that states the operation and then lists its outputs. There is no filler, hedging, or redundant restatement.

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

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

With no output schema and no annotations, the description does double duty and partially compensates by enumerating return contents. However, for an 'investigation' tool sitting among several overlapping order/trace lookups, the missing routing guidance and read-only assurance leave real gaps.

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

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

Schema description coverage is 100%, so both parameters are already documented; the description's restatement of 'order number or track & trace' duplicates the schema's own wording. The intentId parameter (tied to RecordUserQuestion) is not mentioned in the description at all.

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?

Names a specific verb+resource ('Full order investigation') and enumerates the payload ('order details, usage records, payment orders, related tickets'), which separates it from thin lookups like FindOrder or FetchWebshopOrder. It stops short of naming any sibling explicitly, so an agent must infer the boundary itself.

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 'by order number or track & trace' implies when the tool applies, but there is no guidance on when to choose it over FindOrder, FetchWebshopOrder, LookupByTrackTrace, or InvoiceInvestigation. Usage is left to inference from the description's breadth.

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

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

No annotations are provided, so the description carries the burden. It usefully discloses the authorization/scoping behavior (partners are scoped to their own data, admins must supply partnerId), which is the key operational trait, but it omits whether this is a pure read, any rate limits, or result 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?

Two tight sentences with zero waste, front-loading the returned metrics before the access-scope rule. Every clause 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?

With no output schema and no annotations, the description reasonably covers what the summary contains and the calling scope. It stops short of describing return shape or default behavior, but for a dashboard summary tool it is largely sufficient.

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

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

Schema description coverage is 100%, so the schema already documents month, intentId, and partnerId including the 'admins only; partners use own scope' note. The description's partnerId mention merely restates the schema, adding no 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?

States a specific resource (partner dashboard/summary) and enumerates exactly what it returns: label count, revenue, open tickets, unpaid invoices. The 'partner dashboard' framing plus the explicit metrics set it apart from generic siblings like GetAnalytics and SummarizeUsageRecords, though no sibling is named directly.

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

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

Provides role-based scope context ('Partners see own data; admins pass partnerId') that hints at who should call it, but gives no explicit when-to-use vs alternatives guidance and no exclusions against the many sibling reporting/invoice tools.

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

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

With no annotations, the description carries the full burden and does disclose meaningful behavior: the question is persisted for product improvement (a side effect the agent should know about), and it returns an intentId plus suggested tools that get threaded into later calls. It stops short of auth requirements, idempotency, or exact return shape beyond naming the 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?

Three tight sentences with the most important instruction (call this first) front-loaded, followed by what it stores and what it returns. No filler; every clause carries an instruction the agent must act on.

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

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

No output schema exists, so the description must cover return values — it does name the intentId and suggested tools, and explains how to use intentId downstream. Both the required and optional parameters are covered, leaving only minor gaps about persistence guarantees or error 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 100%, so the 'question' verbatim requirement and the category override enum list are already fully documented in the schema. The description reinforces 'exact natural-language question' but adds no syntax or format detail beyond the schema, which is the expected baseline (3).

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

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

States a specific verb (record/store) and resource (the user's natural-language question), plus its exact position in the workflow ('before any other Zineps tool'). An agent can instantly distinguish it from all 45+ siblings, which are retrieval/action tools rather than a mandatory intake step.

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 rule ('ALWAYS call this first... before any other Zineps tool') and an explicit downstream rule ('Pass intentId to subsequent tools when possible'). Since the tool is mandatory-first, there are no real alternatives to exclude, so the sequencing guidance is complete.

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

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

No annotations are provided, so the description carries the full burden. It correctly signals a write operation ("Create a NEW"), but discloses nothing about side effects: whether the carrier is charged, what happens to the referenced existing label, whether it requires permissions, or whether the call is idempotent. For a label-creating mutation with zero annotation coverage this is a significant gap.

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

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

Two tight sentences with zero padding. The core action is front-loaded and the caveat about completed orders is appended where it belongs.

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 mutation with no annotations and no output schema, the description explains the intent and the copy-from-existing behavior, which is enough to pick it. It stops short of the behavioral disclosure (cost, fate of old label, permissions) that an unannotated write tool ideally needs.

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%; both parameters are already documented in the schema (labelId as the source, intentId from RecordUserQuestion). The description adds no further detail about parameter format or constraints, 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 ("Create a NEW shipping label") and, crucially, the source of the settings (the same Zineps order and carrier contract/product as an existing label), which separates it from the sibling CreateLabelForOrder. It does not name that sibling explicitly, so the differentiation is implicit rather than explicit.

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

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

"Works even when the order is already complete" gives a useful usage condition and hints at when this is preferable to creating a fresh label. However, it never names an alternative (e.g., CreateLabelForOrder) or states when NOT to use it, so the routing guidance is only implied.

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 it does disclose one valuable trait: the reply does not alter ticket status, and the action is scoped to "your scope." It is silent on whether the reply notifies the customer, permission requirements, or idempotency/duplicate-reply behavior.

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

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

Two sentences, no filler, and the primary action is front-loaded ahead of the clarifying exclusion. Every clause 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 3-parameter tool with no output schema and no annotations, the description covers purpose and one key behavioral constraint but omits return shape, notification side effects, and permission context. Adequate but with clear gaps an agent would want filled.

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% (ticketId, message, intentId all documented in the schema), so the baseline is 3. The description adds no field-level meaning such as format expectations for the reply text or when intentId should be supplied.

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 ("Add a reply on a support ticket") plus a scope qualifier ("in your scope"). It also explicitly separates itself from the neighboring mutation tool UpdateTicket, so an agent can pick correctly 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 one explicit when-not and names the alternative: "Does not change ticket status; use UpdateTicket for that." It lacks guidance on other plausible paths (e.g. how this relates to RecordUserQuestion, whose intentId it consumes), so it is clear context rather than complete 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?

No annotations are provided, so the description carries the full burden. It usefully discloses domain scope (master definitions in a global catalog vs. applied label surcharges), which is the key behavioral distinction here, and 'Search' implies a read. However it says nothing about permissions, rate limits, pagination beyond the schema's limit field, or result 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 sentences, zero filler, with the core scope stated first and the disambiguation second. Every clause 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 parameter-light read tool with a fully documented schema, the definition covers selection and routing well. The residual gap is return shape/pagination behavior, which is not covered by any output schema or annotation and goes unmentioned.

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 each of the four parameters documented inline (limit, search, carrier, intentId). The description adds no filtering syntax, matching rules, or enum guidance beyond what the schema already states, so the baseline of 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 specific verb ('Search') plus the resource and its scope ('global carrier surcharge catalog (master definitions)'), and explicitly contrasts it with the sibling SearchLabelSurcharges. An agent can distinguish it from the applied-surcharge tool 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?

Gives both positive guidance ('use before configuring partner surcharges') and an explicit exclusion with the correct alternative ('not for applied label surcharges (use SearchLabelSurcharges)'). The when/when-not/alternative triad is fully covered.

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

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

No annotations are provided, so the description carries full burden, and it delivers real substance: it discloses that results are summary rows without bodies and that combined filters use AND. Notably it states 'Admin or Superuser access required', an auth prerequisite not recoverable from the schema. It stops short of return format/pagination specifics.

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 compact sentences with zero filler. The most decision-critical constraint (summary-only, no bodies) is front-loaded, followed by the routing hint and the auth requirement.

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 optional-filter search with full schema coverage and no output schema, the description covers scope, filter semantics, alternative routing, and access requirements. Return-shape detail is the only notable omission, and the summary-rows disclosure partly compensates.

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 each parameter individually described, so the schema does the heavy lifting. The description adds the AND-combination semantics for filters, marginal value, so baseline 3 is appropriate.

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

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

States a specific verb+resource ('Search/list label logs') and adds a scope qualifier ('summary rows only — no bodies') that distinguishes it from body-returning siblings. It does not explicitly name the log-specific alternatives among the many sibling tools, but the resource is unambiguous.

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 routes the agent: 'Prefer LookupByTrackTrace then get_label_log', naming both alternatives and the preferred order. This is clear when-to-use guidance, though it doesn't spell out conditions where search is preferred over the lookup path.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses that returned ids map to ParcelShopId for labeling and that the data mirrors GET /api/Parcelshops, but says nothing about result limits, ordering, pagination, or the read-only nature of the 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?

Two tight sentences with the core purpose front-loaded and the id-mapping note second. No filler, though the parenthetical API reference is marginal value for an agent.

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 six well-documented parameters and no output schema, the description is adequate but thin: it hints at the id field in the response but does not characterize the returned pickup-point records (address, opening hours, distance) that an agent would need to reason about results.

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 six parameters including the carrier default (PostNL/DHL/GLS) and organisationId default. The description adds no syntax or format detail beyond what the schema provides, so the baseline of 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 resource (pickup points / parcel shops) and a scope qualifier ('near an address'), and ties it to the sibling API endpoint GET /api/Parcelshops. It is easy to distinguish from label- and carrier-oriented siblings, though it never explicitly names a competing sibling tool.

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?

There is no when-to-use guidance, no when-not-to-use, and no named alternative among the many sibling tools. The implicit context (finding pickup points near an address) is inferable but the description does not route the agent.

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

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

No annotations exist, so the description carries the full burden. It usefully discloses the 200-row cap and the organisationId/scope behavior per caller role. But it omits anything about authentication/permissions beyond role, result shape, or ordering, which is a gap for a tool with zero annotation coverage.

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

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

Four compact sentences with the search purpose and filter set front-loaded, then scoping rules, then the cap. No significant waste, though the endpoint-as-spec framing is a little indirect.

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 7-parameter search with no output schema and no annotations, the description covers scoping and the row cap but leaves the return structure and result ordering unaddressed. Adequate but not fully complete.

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 schema already documents every parameter, including the organisationId role rule. The description confirms carrier/contract/created-range filtering but adds little syntax or format detail beyond the schema. Baseline 3 is appropriate.

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

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

States a specific verb (search) and resource (labels) plus the filter dimensions (carrier, contract, created range), and implicitly distinguishes from siblings like ListRecentLabels and FindLabel. The reference to the POST /api/Labels/Search endpoint is slightly opaque but the intent is clear.

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 role-based context (partners may omit organisationId, subpartners search only their companies), which implies when the tool applies to different callers. However it never names alternatives or the conditions that should route an agent to SearchShippingLabels over ListRecentLabels or GetLabelsForOrder.

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 behavioral burden, and it does disclose two real traits: the physical side effect (a print job is dispatched) and that the printer is fixed to the organisation default rather than selectable. It stops short of stating permission needs, failure behavior, or whether a new print job is created on each 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?

A single front-loaded sentence with no filler and no repetition of the schema. It is efficient, though slightly terse given the operation it performs.

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, no-output-schema tool, the description covers the core action but leaves gaps an agent would care about: what 'again' presupposes about prior label state, whether the labelId is a usage id versus a label id, and what happens if no default printer or PrintNode connection exists.

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% with only two parameters, so the schema already documents labelId and intentId. The description adds no meaning beyond what the schema provides; 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 specific verb and resource: sending/re-sending a label print job to PrintNode via the organisation default printer. An agent can tell this is a print-dispatch action rather than a label lookup or remake. It does not explicitly distinguish itself from lookalikes such as RemakeLabel or DownloadLabel, which would warrant 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?

The word 'again' implies this is for re-printing an existing label, which is useful implied guidance. However, there is no explicit when-to-use framing and no routing to alternatives like RemakeLabel or DownloadLabel, so the agent must infer the context.

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

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

With no annotations, the description carries the full burden and does disclose meaningful traits: 'no row limit' and 'Partners see own partner scope only' (a data-scoping/auth constraint). It also states the aggregation granularity (by carrier and user). It stops short of describing the exact return structure or any rate/format limits, so not 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?

Three tight sentences, front-loaded with the PREFERRED marker and the core purpose, followed by return shape and the sibling alternative. No filler; 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 5-optional-param aggregation tool with no output schema and no annotations, the description covers purpose, output granularity, scope restriction, and the alternative. The defaults (today UTC, same-as-dateFrom) live in the schema, but the return format detail is thin, keeping it just short of complete.

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 schema already documents all five optional parameters with types, defaults, and formats. The description only implies date and carrier usage via its example ('how many DHL labels today') and adds no syntax beyond the schema. Baseline 3 is appropriate.

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

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

States a specific verb+resource (SummarizeUsageRecords) and clarifies the output shape: aggregated counts by carrier and user. It explicitly contrasts with a sibling (SearchUsageRecords rows), so an agent can distinguish it 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?

Marks itself PREFERRED for counts and totals, gives a concrete example (how many DHL labels today), and names the alternative to avoid (fetching hundreds of SearchUsageRecords rows). When-to-use and when-not-to-use are both 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?

No annotations are provided, so the description carries the full behavioral burden. It does not state that rateId is required, whether unspecified fields are preserved, whether the change is reversible, what permissions or auth are needed, or what the response looks like. For a mutation tool with zero annotation coverage this is a substantial gap.

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

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

One short, front-loaded sentence with no filler; the verb and target resource lead. It is appropriately sized for a single-purpose update tool, though it could add a clause about the required rateId at no cost.

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?

A 7-parameter mutation tool with no annotations, no output schema, and 0% schema description coverage needs a much richer description to be callable correctly. The current text leaves most parameters and all behavioral context undocumented.

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

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

Schema description coverage is 0% across 7 parameters. The description names only three updatable fields (margin, amount, contract price) and leaves rateId, intentId, marginType, externalLedgerCode, and franchisePercentageMargin completely unexplained in both schema and description.

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 ('Update') and resource ('existing customer-specific rate'), and enumerates which fields can change. It implicitly distinguishes itself from siblings UpdatePartnerRate and UpdatePartnerSurcharge by scoping to customer-specific rates, though it never names them.

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?

No when-to-use guidance, no prerequisites, and no mention of the closely related UpdatePartnerRate / UpdatePartnerSurcharge tools. The agent must infer from the tool name alone that this applies only to custom (customer-specific) rates.

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

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

No annotations are provided, so the description carries the full burden. It implies a mutation but says nothing about reversibility, permission requirements, what happens to unset fields, or rate-limit/locking behavior on an existing rate.

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 with no filler, and the targetable fields are surfaced immediately. It is efficient, though the brevity comes at the cost of the detail the other dimensions need.

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?

A mutation tool with no annotations, no output schema, and seven parameters at 0% schema coverage. The description leaves most parameter meanings and all behavioral context undocumented.

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

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

Schema description coverage is 0%, so the description must compensate, but it only mentions margin, amount and contract price out of seven parameters. It never explains marginType vs franchisePercentageMargin, intentId, or externalLedgerCode, and gives no format/unit 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?

States a clear verb (Update) and resource (partner rate) plus the specific fields it can change. The parenthetical '(no customer)' draws a boundary against customer-scoped rates, giving partial sibling differentiation against UpdateCustomRate, though it never names that sibling directly.

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?

No statement of when to use this versus AddPartnerRate/UpdateCustomRate/UpdatePartnerSurcharge, and no prerequisites such as requiring an existing rateId. The '(no customer)' hint implies scope but is not an explicit usage rule.

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

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

With no annotations provided, the description carries the full behavioral burden but discloses nothing beyond 'update'. It does not state permissions, reversibility, whether unspecified fields are preserved (partial vs full update), or overwrite semantics — critical for a multi-field mutation with six optional parameters.

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 front-loaded sentence with no filler, listing the mutable fields efficiently. Nothing is wasted, though it is perhaps too terse for a seven-parameter mutation.

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 mutation with no annotations, no output schema, and six optional nullable fields, the description omits the key question of partial-update semantics and side effects. The schema covers parameter meaning, but nothing explains what an update actually does to the record.

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 parameters; baseline 3 applies. The description's field list loosely echoes the schema (and slightly conflates 'margin' with the 'marginType' parameter) without adding format or constraint detail.

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 ('Update') and resource ('partner surcharge') plus the mutable fields (amount, margin, VAT, carrier cost). This naturally distinguishes it from UpdatePartnerRate and UpdateCustomRate, though it never names those siblings 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?

The description implies usage only through 'existing partner surcharge' and offers no when-to-use, when-not-to-use, or alternative routing (e.g., vs UpdatePartnerRate or AddPartnerSurcharge). An agent gets no guidance on choosing between the many sibling update tools.

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

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

With no annotations, the description carries the full behavioral burden. 'Change' implies a mutation, but it says nothing about permissions, whether a status change (e.g. Closed) notifies the customer, or whether changes are reversible. For a state-mutating tool this is a real gap.

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

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

Two tight sentences with the action front-loaded and the allowed values appended. Every sentence earns its place with 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?

For a mutation tool with no annotations and no output schema, the description covers the valid status values but omits side effects, permissions, and any explanation of the optional intentId. Adequate to invoke, thin on 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 coverage is 100%, so baseline is 3, but the description adds genuine value by enumerating the valid status names (Draft, Open, Pending, Closed, Resolved, Error) even though the schema defines 'status' as a free string with no enum. This closes an enum gap the schema leaves open. It does not explain the intentId parameter.

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 ('Change a support ticket's status'), which is enough for an agent to distinguish it from mutation-adjacent siblings like ReplyToTicket or UpdateCustomRate. It stops short of explicitly naming how it differs from ReplyToTicket, but the verb+resource pair is unambiguous.

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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as ReplyToTicket. The only implicit guidance is the status list, which does not tell the agent when changing status is the right action.

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