packing-list

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

Annotations already indicate a non-read-only mutation, and the description adds useful behavioral context: it return a C01-style id, requires whole-gram weights and whole-centimetre dimensions, and explains that dimensions enable chargeable weight. No contradiction exists with the annotations.

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 with no filler: the first states the action and return values, the second gives a meaningful rationale for the optional dimensions. The structure is front-loaded and every phrase 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?

The description covers the action, the return value, and the semantic importance of dimensions. Although there is no output schema, the description gives enough about the C01-style id and fields an agent can expect; remaining details are already carried by the input 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 description coverage is 86%, so the baseline is 3. The description adds value beyond the schema by emphasizing WHOLE units and by explaining why the optional dimensions matter ('Dimensions are what make a chargeable weight possible'), helping the agent decide whether to supply them.

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

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

The description uses a specific verb and resource: 'Add a carton to a packing list', and clarifies that it returns a C01-style id plus dimension and weight fields. This clearly distinguishes it from siblings like pack_item or packing_list_create.

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 use when a carton must be added to a packing list, but gives no explicit when-to-use or when-not-to-use guidance and does not mention any alternative sibling tools. An agent must infer the appropriate context from the tool name and basic action.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds meaningful behavior beyond that: the chargeable-weight rule and the explicit 'null, never a guess' policy for cartons without dimensions, which is valuable edge-case transparency.

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 no filler. The scope is front-loaded, and the crucial null-handling edge case is stated explicitly rather than 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?

For a read-only reporting tool with two inputs and no output schema, the description covers the computed fields and the key edge case well. It could be slightly more complete with an example or rounding/divisor effect note, but the schema already covers divisor.

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 packing_list and divisor are already documented. The description adds no parameter-level detail beyond what the schema provides; the formula it gives concerns output semantics rather than input parameters.

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

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

The description clearly states what the tool reports: per-carton and per-shipment weight metrics including tare, net, gross, volume, volumetric weight, and chargeable weight. This is a specific calculation/report purpose, though it does not explicitly contrast itself with sibling tools like packing_list_show or packing_slip.

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

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

The description gives no when-to-use guidance, prerequisites, or exclusions. It does not mention when to prefer carton_report over related packing/reporting siblings, leaving the agent to infer usage solely from the metric list.

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

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

Annotations already indicate this is not read-only and not destructive, and the description adds useful behavioral detail: existing data under the token stays, and a wrong or expired key changes nothing. This goes beyond the annotation hints by explaining failure semantics and safety of the 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?

The description is two sentences with no filler. It front-loads the core action, then gives the key format and safety guarantees, and closes with the verification tool. Every sentence contributes essential 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-parameter activation tool with annotations covering the safety profile, the description is complete: it states what the tool does, what input is needed, what happens on failure, and how to confirm success. There is no missing critical information for an agent to call it correctly.

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

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

The schema already documents the key parameter and its format with 100% coverage. The description adds meaning by specifying that the key must be issued at checkout for this server or the bundle, which clarifies validity requirements not present in the schema.

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

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

The description uses a specific verb and resource: it 'turns Pro on' for the connection using a license key. It also distinguishes itself from the sibling license_status tool by saying license_status confirms the activation. This leaves no ambiguity about what the tool accomplishes.

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 provides clear context for use: the key must be an MCPL1.<payload>.<signature> issued at checkout for this server or the bundle. It does not explicitly list exclusions or alternative tools, but it does reference license_status as the confirmation path, giving the agent a sense of the workflow.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds useful context beyond annotations by specifying the JSON response contents and stating 'nothing changes,' reinforcing 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 dense sentences cover output, purpose, usage context, and side-effect guarantee. Every sentence earns its place and the most important information is front-loaded.

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

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

With no output schema, the description sufficiently describes the return value. With no parameters, annotations covering safety, and a clear use case, nothing essential is missing for an agent to invoke this tool correctly.

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

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

There are zero parameters and the schema already fully documents that fact. The description explicitly says 'No arguments,' which is accurate and reinforces the schema without needing further elaboration.

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 begins with a specific verb ('Report') and a precise resource ('this endpoint's licence state for your token'), and enumerates the exact output fields: product, tier, reason, and checkout URL. This clearly distinguishes it from sibling tools like license_activate.

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

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

The description explicitly states when to call it: 'Call it to explain a free-tier refusal.' This is clear contextual guidance, though it does not name alternatives or explicitly state when not to use it.

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

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

Beyond the annotations, the description reveals that the tool appends a line, that the values are user-stated rather than sourced from other stores, and that the action affects shortfall calculations. It could say more about duplicate calls or matching behavior, but it adds meaningful behavioral context without contradicting annotations.

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

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

The description is two focused sentences with the action front-loaded and the most important qualification immediately after. Every sentence earns its place, and there is no filler or redundant restating of the schema.

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 mutation tool with complete schema documentation and no output schema, the description supplies the essential operational context: it adds to a packing list, affects shortfall, and does not read from other stores. It does not explain duplicate handling or failure modes, but those are minor given the tool's low complexity.

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

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

The input schema already documents all four parameters with 100% coverage, so the baseline is 3. The description names three of the four parameters but adds no extra format, constraints, or semantic detail beyond what the schema provides.

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

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

The description states a specific action ('Add an ordered line to a packing list') and names the payload fields (SKU, description, quantity). It is clear about the resource and purpose, but it does not explicitly differentiate from sibling tools such as pack_item or packing_shortfall.

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 clear context: use this to declare what the order says so the shortfall becomes real, and it explicitly notes that no data is read from quotes, work orders, or invoices. It lacks an explicit 'when not to use' or a named alternative, so it stops short of full guidance.

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

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

Annotations only carry negative hints (not read-only, not idempotent, not destructive), so the description must bear the burden of behavior. It discloses a meaningful behavioral constraint: only 3 lists can be open at once on the free tier, and shipping or cancelling frees a slot. This goes beyond the annotations and helps the agent anticipate quota-related failures.

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

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

The description is two sentences with no filler. The core action and return value are front-loaded, and the quota behavior earns its place as operational guidance an agent needs before calling the tool.

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

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

With no output schema, the description usefully states what is returned: the PL number plus order reference, consignee, ship-to, and date. It also covers the free-tier limitation. It is not exhaustive about error conditions or edge cases, but it is complete enough given the rich schema and the quota disclosure.

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 86%, so the parameters are already well documented in the schema. The description adds little beyond echoing reference, consignee, ship-to, and date; it does not explain note, duplicate_ok, or reference_kind beyond what the schema already provides. Baseline 3 is appropriate.

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

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

The description names a specific action ('Open a packing list against an order') and a concrete resource, and states the returned artifact ('PL-YYYY-NNNN number'). It is clearly differentiated from sibling tools like packing_list_list, packing_list_show, and packing_list_delete, which describe listing, viewing, and deleting rather than opening.

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

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

The description implies the tool is used when opening a packing list against an order, and the free-tier quota adds operational context. However, it does not explicitly state when to prefer this over alternatives such as packing_slip, pack_item, or packing_list_show, nor does it give exclusions or when-not-to-use guidance.

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

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

Beyond the destructiveHint annotation, the description discloses the reach of the deletion ('with its cartons and packed lines'), the permanence implied by 'for good,' and the guard behavior for shipped lists. This is exactly the added behavioral context an agent needs before invoking a destructive 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?

The description is three tight sentences with no filler. The core destructive effect is front-loaded, followed by the key exception and the safer alternative, so critical information is immediately visible.

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

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

For a two-parameter destructive tool with a rich destructiveHint annotation, the description covers the operation, its scope, its guard, and the alternative. Nothing an agent needs to decide whether and how to call this tool correctly is missing.

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

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

Schema description coverage is 100%, so the schema already fully documents both parameters: packing_list identifies the target and confirm must be true. The description does not add parameter-specific meaning, but it does not need to because the schema carries the load.

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: 'Delete a packing list for good, with its cartons and packed lines.' It also distinguishes the tool from cancellation by refusing shipped lists, so an agent can tell it apart from related packing-list tools.

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

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

It explicitly says when deletion is inappropriate: a shipped list is refused because it is the shipment record. It also names the alternative path: 'Cancel a list you no longer want instead of deleting a real shipment,' giving clear when-to-use and when-not-to-use guidance.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint false). The description adds useful behavioral detail beyond annotations: newest-first ordering, the 500-row cap, and the inclusion of computed short-line counts.

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

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

Two sentences deliver the main behavior, key output fields, ordering, filters, and a row limit with no filler. The most important information is front-loaded.

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

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

For a read-only list tool with full schema coverage and no output schema, the description covers return contents, ordering, filters, and the row limit. An agent has enough to invoke it correctly and interpret the result shape.

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 fully documents all five parameters. The description only restates a few filter concepts and does not add new meaning to parameters like divisor or open_only, but it does not need to given the schema quality.

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

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

The description clearly states the operation: listing packing lists, with explicit output fields (cartons, units, gross weight, short ordered lines), ordering (newest first), and filters. This distinguishes it from siblings like packing_list_show or packing_list_status.

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

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

The description gives clear usage context: filter by status, order reference, or consignee, and returns up to 500 rows. It does not explicitly name alternative tools or state when not to use it, but the context is sufficient for most list-vs-detail decisions.

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

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

The readOnlyHint, idempotentHint, and destructiveHint annotations already establish safety, and the description adds meaningful context: 'Nothing here is stored; it is computed.' This clarifies that the output is a derived view with no persistence side effects, and it also discloses that weights are derived and ship-readiness includes a reason.

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

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

The description is two sentences with no wasted words. It front-loads the core purpose ('the whole packing list') and then efficiently enumerates the full set of returned information, ending with a valuable behavioral note about computed data.

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 low-complexity, two-parameter tool with complete schema coverage and strong annotations, the description is sufficient. It names all major output dimensions (cartons, contents, weights, lines, shortfall, ship-readiness, status history) and clarifies the computed, non-persisted nature of 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 the schema fully documents both parameters. The description does not add parameter-specific guidance beyond mentioning 'derived weights,' which relates to the divisor but is not explicit. Baseline 3 is appropriate given the schema carries the parameter documentation burden.

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

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

The description uses the specific verb 'show' with the resource 'one packing list' and immediately scopes it as 'the whole packing list.' The enumerated contents (cartons, ordered lines, shortfall, ship-readiness, status history) clearly distinguish this full-detail view from siblings like packing_list_status, packing_shortfall, and packing_list_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?

The usage context is implied: if you need the complete packing list view, this is the tool. However, it does not explicitly state when to use this over packing_list_status, packing_list_list, packing_shortfall, or packing_slip, nor does it name alternatives or exclusions.

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

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

The text clearly describes a state-changing mutation: moving statuses, recording shipping data, and freezing the list. This directly contradicts the annotation readOnlyHint=true. Per the rubric, a description that contradicts annotations scores 1 regardless of the useful freeze/irreversibility detail it adds.

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 no filler. The first sentence front-loads the action and transition path, the second explains shipping side effects, and the third states the irreversible consequence. Each 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?

The core workflow and the irreversible shipped state are covered, and the schema fills parameter details. However, there is no output/return guidance, cancellation behavior is only named and not explained, and the annotation contradiction leaves the agent with conflicting signals about whether this tool mutates state.

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 already documents 6 of 7 parameters, so the baseline is 3. The description adds valuable cross-parameter meaning: carrier, tracking, and date are recorded specifically when moving to shipped, and status follows the draft->packed->shipped path. This helps the agent understand when those optional parameters matter.

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 ('Move') and resource ('packing list') and enumerates the exact status transitions: draft to packed to shipped, or cancel. It is clearly distinguishable from siblings like packing_list_create, packing_list_list, and packing_list_delete because it is the workflow-status mutation 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?

The description makes the tool's scope clear: use it when advancing or canceling a packing list's status. It does not explicitly name alternatives or state when not to use it, but the workflow context is specific enough for an agent to select it over the create/list/show/delete 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?

The description adds a valuable behavioral guarantee: a packed line with no ordered line is reported, never dropped. This edge-case disclosure goes beyond the annotations, which are all false and provide no safety or mutation hints. It does not mention side effects, but the reporting framing suggests a non-mutating 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?

Two compact sentences with no filler. The first sentence front-loads the comparison and the three output categories; the second adds a concise, meaningful edge-case guarantee. Every word earns its place.

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

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

For a single-parameter reporting tool, the description covers purpose, scope, and a key edge case, and the schema handles parameter semantics. The only minor gap is that with no output schema, the exact response shape is not specified, though 'line by line' and the listed categories give a reasonable picture.

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

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

Schema description coverage is 100%, and the schema already explains the packing_list parameter well, including an example and the order-reference fallback. The tool description adds no additional parameter-level detail, so the baseline of 3 is appropriate.

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

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

The description clearly defines the tool as a comparison of ordered versus packed lines and enumerates three specific result categories: short, over-packed, and packed-but-not-ordered. This makes the tool's scope unmistakable and distinguishes it from siblings like packing_expect or packing_slip, even without naming 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?

Usage context is implied: this is the discrepancy report to consult after packing to find shortages or overages. However, it does not explicitly say when to prefer this over related tools such as packing_expect or packing_slip, nor does it give exclusions or prerequisites.

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

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

The description discloses substantial behavior beyond the all-false annotations: output is plain text, no prices are included, Pro receives a .txt download link valid for one hour, and an existing out_path is refused unless overwrite is requested. It also signals the failure mode for naming conflicts. No contradiction with annotations exists.

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

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

Two sentences capture the main result and the Pro file behavior with no filler. Every clause adds useful information: content details, tier access, absence of prices, download link expiry, naming, and overwrite policy.

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 uninformative annotations, the description must carry the burden of explaining return values and edge behavior; it does so by specifying the slip contents, the no-prices guarantee, the download link expiry, and the overwrite refusal. The Pro plan prerequisite is implied and supported by the schema. The description is complete for a simple text-producing tool.

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

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

The input schema covers all four parameters with meaningful descriptions, including Pro-only status and overwrite behavior, so the description does not need to duplicate parameter details. The tool description adds global context such as the one-hour link and no-prices rule, but not per-parameter semantics. Baseline 3 is appropriate given full schema coverage.

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

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

The description clearly identifies the deliverable: a packing slip as plain text with cartons, contents, weights, a signature line, and no prices. Combined with the title, it is evident this tool produces a slip rather than managing lists. It does not explicitly differentiate from sibling tools like packing_list_show, but the content specification makes the resource distinct.

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 guidance is given on when to choose packing_slip over sibling tools such as packing_list_show, packing_list_status, or packing_expect. The tier note (every tier vs Pro) is the only usage context, and even that focuses on output format rather than decision logic.

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 annotations only saying readOnly=false, idempotent=false, and destructive=false, the description adds a meaningful behavioral trait: omitting unit_grams makes the returned carton gross a lower bound. It also makes clear the operation mutates carton contents without contradicting any annotation.

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

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

Two sentences with no filler: the core operation is front-loaded, and the optional-weight caveat is placed right after. Every phrase 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 7-parameter mutating tool with no output schema, the schema descriptions carry most of the load, but the definition leaves gaps. It does not state whether the carton or packing list must already exist, and the 'note' parameter is undocumented, so an agent could still call it incorrectly.

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 high (86%), so the baseline is 3. The description mostly restates what the schema already documents—description, quantity, unit_grams, and the omit-when-not-weighed rule—and does not clarify the undocumented 'note' parameter or add detail beyond the schema's sku/packing_list matching descriptions.

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

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

The description states a specific action and resource pair: 'Put a quantity of one item into a named carton', and even covers the key unit_grams caveat. It is unambiguous, but it does not explicitly contrast with siblings such as unpack_item or carton_add, 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 intended use is implied by the name, title, and action verb, but there is no explicit when-to-use guidance or pointer to alternatives like unpack_item for removal. The conditional packing instruction ('Leave unit_grams out... lower bound') is procedural, not usage-selection 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?

Annotation Contradiction: the annotations set destructiveHint=false, but the description explicitly says 'The line is deleted, not zeroed' — a hard deletion of a resource. This directly contradicts the annotation. Apart from the contradiction, the description does usefully disclose the delete-not-zero behavior and the slip consequence.

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

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

Two sentences: the first fronts the action, resource, id style, and return value; the second explains the deletion behavior and why it matters. Every clause 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 two-parameter tool with no output schema, the description covers what action to take, what id format to use, what side effect occurs, and what is returned. It does not mention not-found or error behavior, and the destructiveHint contradiction slightly undermines completeness, but the core call is adequately specified.

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 are already well described in the schema. The description adds no genuine parameter-level meaning beyond restating the id style and packing-list/or-order-reference format, 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 ('Remove'), a precise resource ('one packed line from a packing list'), an addressing scheme ('L01-style id'), and the expected result ('return the carton it came out of'). This clearly differentiates it from siblings like pack_item (adding lines) and packing_list_delete (deleting whole lists) even without naming 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?

The description gives clear operational context: use this tool to remove a single already-packed line and to prevent the slip from printing an unpicked item. It does not explicitly name alternatives or give when-not-to-use guidance, so it stops short of a 5.

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