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

The description states the core behavior (adding to a packing list) and the return value, and it hints at the consequence of supplying dimensions. However, with no annotations present, it does not disclose side effects such as updates to packing-list totals, errors, 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 sentences, no fluff, and the main action is front-loaded. The sentence 'return its C01-style id: a label, the empty weight..., and optionally length, width and height...' is slightly awkward because it mixes id format with content fields, but it remains compact and readable.

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

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

Given there are seven parameters and no output schema, the description covers the operation, return shape, and the dimension rationale. However, it omits prerequisites (e.g., whether the packing list must exist) and any side effects or error conditions, leaving some ambiguity for unexpected cases.

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 applies. The description adds modest value by noting the 'C01-style' returned id and the purpose of dimensions for chargeable weight, but it largely reiterates what the schema already documents.

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 ('Add a carton to a packing list') and the object being acted on, plus what will be returned (a C01-style identifier with label, weight, and optional dimensions). It is specific enough to select the tool, though it does not explicitly distinguish it from sibling carton 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?

The final sentence ('Dimensions are what make a chargeable weight possible') is the only usage hint, and it only explains why dimensions matter rather than when to invoke carton_add versus alternatives. No prerequisites, exclusions, or alternative tool guidance is 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 must carry the fullness of behavioral disclosure. It clearly describes the output fields and an explicit edge-case behavior ('chargeable weight goes null, not guessed'). It stops short of stating it is read-only or requires any permissions, but the report-like wording makes side effects unlikely.

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 report contents, followed by a one-line edge-case rule. No fluff, no repeated schema details, no redundancy with the title.

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

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

The description tells an agent what the report includes and one important null behaviorhol does not cover what happens for missing carton dimensions beyond 'null', whether an empty packing list is valid, or what units/output format is returned. Since there is no output schema, a bit more operational guidance 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?

Schema covers both parameters (packing_list, divisor) descriptively. The tool description adds general output context but does not deepen understanding of how each parameter affects the result; it only implies that the packing list identifies the shipment and that the divisor factor influences volumetric weight.

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 resource ('per carton and for the shipment') and enumerates the specific metrics it reports (net, gross, chargeable weight, volume, etc.). It lacks an explicit verb like 'calculates' or 'lists,' and does not contrast with sibling reporting tools, but the intent is unmistakable.

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 explains what the report contains but gives no guidance on when to use this tool over siblings like packing_slip or packing_list_show. There are no prerequisites, no mention of whether a packing list must exist, and no direction to alternative tools for other use cases.

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. It discloses that verification happens offline against a built-in public key, that the key is persisted to the config file, and that invalid keys are refused and left unsaved. This is substantial transparency for an activation tool, though it could mention overwriting an existing key or the exact return 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?

The description is two sentences with no filler. The first sentence front-loads the main action, source, verification method, and persistence. The second sentence efficiently covers error handling and points to the related read-back tool. Every clause adds value.

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 single-parameter tool with no output schema and no annotations, the description covers activation behavior, verification mechanism, persistence, error outcomes, and how to read the result later. The only minor gap is an explicit statement of what the function returns upon success or failure, but the phrase 'refused, unsaved' implies a feedback mechanism. Overall, it is sufficiently complete 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 at 100% coverage, so the baseline is 3. The description adds meaningful semantics by giving the concrete key format ('MCPL1.xxx.yyy'), confirming the key comes from the checkout page, and explaining that malformed or expired keys will be rejected. This goes beyond the schema's one-line 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 action ('Activate a Pro key'), the exact key format ('MCPL1.xxx.yyy'), the source ('from checkout'), and the core mechanism ('verified offline against a built-in public key'). It also differentiates itself from the sibling license_status by noting that license_status reads the activation back, so there is no ambiguity about which tool does what.

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

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

The description gives clear context: use this when you have a Pro key from checkout that needs to be activated. It also points to license_status as the read-back tool, which implies when to use a related sibling. It does not explicitly spell out 'do not use for checking status' or list other alternatives, but the context is strong enough to avoid misuse.

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 are absent, so the description carries the full burden of behavioral disclosure. It discloses that the call is local ('no network') and argument-free, and it mentions a specific explanatory behavior. The word 'Report' implies read-only, though it does not explicitly state non-destructive or permission requirements; this is adequate for a status command.

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 sentence lists the output fields; the second adds constraints and the sibling pointer. Every clause contributes meaningful 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-parameter status tool with no output schema, the description lists the expected output fields, behavioral constraints, and the relevant alternative tool. Nothing an agent needs to call it correctly is missing.

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

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

The schema has zero parameters and the description reinforces this with 'No arguments'. It adds value by listing the reported fields, helping an agent understand what the empty input will yield. The baseline for zero-parameter tools is high, and the description meets it.

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 ('Report'), a clear resource ('this server's licence state'), and enumerates the exact fields returned. It also names the sibling 'license_activate' as the tool that does something different, so an agent can distinguish them immediately.

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 explicit usage constraints: no arguments, no network, and explains a free-tier refusal. It also directs the agent to license_activate when the task is to install a key, serving as an explicit pointer to the relevant 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?

No annotations are provided, so the description carries the full burden. It clearly discloses that the tool writes to a packing list ('Add an ordered line') and defines the source of truth ('what the order says is stated here'). But it does not mention whether the operation is reversible, how duplicates are handled/deduplication, effects on existing lines, or any status/lifecycle constraints. Some transparency is present, but much behavior is left undisclosed.

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 ('Add an ordered line to a packing list') and packs useful scope clarification into the second sentence. Every clause earns its place. A slight deduction for the poetic phrasing 'so the shortfall is real' which carries a bit of style over function, but it still communicates the outcome.

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 schema covers all parameters at 100%, and the description conveys the action and scope. However, the tool has no output schema and no annotations, so the description could be its own system for the return behavior, effects on existing lines, and error cases. It is functionally sufficient but leaves key contextual 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%, and each parameter already has explicit descriptions (e.g., matching on SKU vs description, packing list id examples). The description only adds the phrase 'a SKU, a description and a quantity' which reiterates the required parameters. It does not add meaningful semantics beyond the schema, so baseline 3 is appropriate.

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

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

The description states a specific verb and resource: 'Add an ordered line to a packing list'. It also defines the exact payload (SKU, description, quantity) and clearly distinguishes this from reading tools by saying 'Nothing is read from the quotes, work order or invoice store; what the order says is stated here.' The title 'Declare what the order says should ship' reinforces the distinct purpose among siblings.

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

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

The description conveys when to use this tool: to declare the expected shipment contents on a packing list. It explicitly contrasts with reads ('Nothing is read from...'), and the sibling names make it distinct from pack_item/unpack_item (actual packing operations). However, it does not explicitly name a sibling alternative or provide a when-not-to rule, so it relies on 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 behavioral burden. It does disclose the free-tier slot limit and the return value, but it does not explicitly say this is a creating/mutating operation, what happens when the limit is reached, or whether errors occur for duplicate open lists. The slot-freeing note is helpful but incomplete.

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 concise sentences with no filler. The core purpose is front-loaded, and the free-tier constraint is stated in one clear follow-up sentence.

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 purpose, return value, and a key operational limit, but for a create-like tool with 7 parameters and no output schema it lacks explicit guidance on when to use it versus siblings, how the duplicate_ok parameter interacts with the limit, and what the response includes beyond the PL number.

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 86%, so the schema already documents most parameters. The description adds context by tying 'where it ships to' to ship_to and 'the date' to date, but it adds no semantics for note, duplicate_ok, or reference_kind 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 verb and resource: 'Open a packing list against an order and return its PL-YYYY-NNNN number.' It also lists the key data involved (order reference, consignee, ship-to, date), which clearly distinguishes it from listing, showing, or deleting packing lists.

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: use this when you need to open a new packing list against an order. It also gives a practical constraint ('Free tier: 3 open at once; shipping or cancelling frees a slot'), but it never names alternatives or states when not to use this tool versus the sibling packing 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?

Even without annotations, the description discloses the destructive cascade ('for good', 'with its cartons and packed lines'), the irreversibility, and the shipped-list refusal. This is strong transparency for a delete 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 compact sentences front-load the destructive scope, state the critical exception, and offer the correct alternative. Every sentence earns its place; 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 simple destructive action with two fully documented parameters and no output schema, the description gives the agent everything it needs: scope, irreversibility, refusal condition, and the proper alternative. Nothing material is missing.

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

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

The input schema already documents both parameters thoroughly, including the confirm=true requirement and the accepted forms of packing_list. The description adds no new parameter-level meaning, so baseline 3 is appropriate; no compensation needed since coverage is complete.

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 ('Delete') plus the resource ('a packing list') and defines the exact scope: 'for good, with its cartons and packed lines.' It clearly distinguishes this destructive operation from listing/showing/creating tools and even states the refusal condition for shipped lists.

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 when-to-use and when-not-to-use guidance: shipped lists are refused, and users are told to cancel a list they no longer want instead of deleting a real shipment. This is concrete routing logic an agent can act on.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses ordering (newest first), the 500-row limit, the output fields, and the filtering dimensions. This is solid coverage, though it does not mention failure modes, authorization, or what happens when no matching lists exist.

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

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

Three short sentences: the first front-loads the main behavior and output, the second lists filters, and the third states the hard cap. Every sentence carries information and there is no filler.

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

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

Given five optional parameters, no output schema, and no annotations, the description adequately conveys the tool's purpose, filters, ordering, and row limit. It is complete enough for an agent to select and call the tool; small gaps like how the 500-row limit is enforced or how divisor interacts with results are left to the 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 input schema has 100% coverage, with each parameter already described, so the baseline is 3. The tool description names only three of the five filters (status, reference, consignee) and adds no new meaning for divisor or open_only, which are already well explained 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 clearly identifies the resource (packing lists) and the operation (list, newest first), and enumerates the returned fields: cartons, units, gross weight, and short ordered lines. This distinguishes it from siblings like packing_list_create, packing_list_show, and packing_list_delete without needing to inspect their schemas.

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

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

The description gives clear context for when to use the tool: to list packing lists with optional filters and a 500-row cap. It does not explicitly name sibling alternatives such as packing_list_show for a single list, nor state when not to use it, so it stops short of a 5.

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

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

No annotations are present, so the description carries the responsibility for behavioral disclosure. It adds a genuinely useful, non-obvious trait – 'nothing here is stored; it is computed' – which tells the agent the output is derived on the fly and that the call does not alter state. It also clarifies that readiness and shortfall are computed; it stops short of explicitly labeling the operation read-only or describing error behavior, but for a 'plain show' tool this is strong discretion provided.

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

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

The description is a tight two-sentence structure: the first sentence front-loads the exact contents of the result, and the second delivers the essential computed-storage distinction. Every clause adds new information and there is no redundancy with the title or 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?

With no output schema or annotations to fall back on, the description does all work of telling an agent what it will see. It does list major content areas, but it omits the output format, error conditions (e.g., unknown packing list id), and any explanation of denominators for the computed fields. Given the tool's moderate complexity and the lack of supplementary structured metadata, the description is passable but leaves notable 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 coverage is 100% and both distinct parameters have detailed descriptions, so the schema already explains divisor units and the packing_list id/order reference formats. The description adds little about parameters individually; the mention of 'derived weights' vaguely ties to divisor but is not enough to raise the score above the schema baseline. The schema is doing the heavy lifting, so a middle score is 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 clear action ('show') on a concrete resource ('one packing list') and enumerates exactly what is returned: cartons with contents and derived weights, ordered lines, shortfall, readiness with reasons, and status history. This differentiates it from siblings like packing_list_list (which covers multiple lists) and the individual tools (packing_shortfall, packing_list_status, carton_report) by presenting the full aggregate view.

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 no explicit guidance on when to choose this tool over siblings. It does not name alternatives, say what conditions warrant the full view, or give exclusions (e.g., 'for the list index use packing_list_list'). The only context hint is in the parameter schema about the order reference, but that concerns input format, not tool selection.

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 transparency burdenley and it does disclose the key side effect: shipping records carrier/tracking/date and freezes the list, and a shipped list cannot be reopened/edited. It does not fully explain cancel behavior or force implications, but the core irreversible action is exposed.

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 dense sentences, front-loaded with the action verb ('Move') and the state machine. Each sentence adds distinct information: transition targets, shipping side effects, and irreversibility. No filler or repetition of schema field names.

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 annotations and no output schema, the description carries a lot of weight. It conveys the transition model and irreversible effects, which is enough for an agent to use the tool without guessing. It could be more complete by spelling out that cancel only applies from open (non-shipped) statuses and that no backward moves are allowed.

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 covers 86% of parameters. The description adds meaningful context by tying carrier, tracking, and date to the shipping transition and emphasizing that shipping is a terminal state, which helps an agent understand when those parameters matter. The 'note' and 'force' parameters are not addressed, but schema covers 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 names a specific operation ('Move a packing list ... to packed to shipped, or cancel it') and spells out the exact state transitions, so an agent immediately knows what the tool does and can tell it apart from siblings like packing_list_create or packing_list_delete.

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 usage context clear: it is the tool for advancing a packing list's status or cancelling it. However, it does not explicitly describe when not to use it or how it relates to sibling tools such as packing_list_create/delete, so exclusion guidance is absent.

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

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

There are no annotations, so the description carries the full burden of explaining behavior. It explicitly discloses edge-case handling ('a packed line with no ordered line is reported, never dropped') and the three output categories. It stops short of stating whether it mutates anything, but the tool appears to be an analytical/reporting 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 short, front-loaded, and information-dense. It states the core comparison first and then clarifies the key edge-case behavior without any 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 single-parameter report tool, the description covers what the tool does, what it compares, and how unmatched packed lines are handled. It does not detail return formatting or explicitly say 'read-only,' but the purpose and inputs are sufficiently clear for correct invocation.

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

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

The single parameter is fully described in the schema with an example, so the description adds no new parameter-level guidance. This is acceptable because the schema already covers the needed context for the packing list identifier.

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 immediately states what the tool does: it compares ordered versus packed quantities and, line by line, surfaces shortfalls, over-packs, and packed-but-not-ordered items. This is specific and clearly distinguishes it from sibling tools like packing_slip 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 clearly implies when to use it: whenever you need to see what is missing, over-packed, or packed without an order line. It doesn't explicitly name alternative tools or exclusions, but the use case is unambiguous enough for an agent to select 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?

With no annotations provided, the description carries the full burden and largely delivers: it discloses two refusal behaviors ('Refuses a URL', 'refuses to overwrite unless told'), a tier-gated side effect (file write only for Pro), and a content guarantee ('no prices anywhere'). It does not cover authorization, rate limits, or invalid-ID handling, but the non-obvious safety-relevant behavior is made explicit.

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

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

Three sentences, each carrying a distinct, non-redundant fact: the output content, the Pro-specific file write, and the refusal/guard rules. The tool's core purpose is front-loaded and there is no filler.

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

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

For a four-parameter tool with a fully self-describing schema, the description supplies output format, tier behavior, and override guard. It does not describe the exact error text when a write is refused, or whether a successful write also returns the slip, but overall the schema-plus-description covers what an agent needs to invoke correctly.

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

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

Schema description coverage is 100% and every parameter — including overwrite's default-false refusal and out_path's Pro tiering — is already fully documented inside the schema. The description's 'refuses to overwrite' and 'Pro also writes it to out_path' largely restate the schema, adding little new parameter-level meaning, which keeps this at the baseline 3 despite it being a compact summary.

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 precise deliverable — a plain-text packing slip containing cartons, contents, weights, and a signature line — and explicitly excludes prices, which clearly scopes what the tool does. It distinguishes itself from list-oriented siblings like packing_list_show and carton_report by its content specification, though it never names a sibling 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 explicit when-to-use guidance or named alternatives; the closest selection signal is the tier constraint ('Pro also writes it to out_path'). An agent can infer the scenario from the plain-text slip format, but the description does not actively say when to choose packing_slip over packing_list_show or carton_report, leaving that to context and the sibling names.

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

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

With no annotations, the description carries the behavioral burden. It discloses one meaningful behavior—omitting unit_grams makes the returned carton gross a lower bound—but it does not explain the mutation's scope (e.g., whether items are added to an existing carton, whether the packing list must exist, or any reversibility), so it is only partially transparent.

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 action is front-loaded and the conditional unit_grams guidance is kept in a separate, clearly readable second sentence.

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 mutation tool with no annotations and no output schema, the description is too thin. It omits when to use it versus alternatives, side effects on the carton/packing list, prerequisites (e.g., carton existence), and an overall return value description beyond the lower-bound hint.

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 reinforces the whole-grams constraint and the omit-when-not-weighed rule, but those points are already in the schema; it adds little beyond it for sku, packing_list, note, or carton.

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—packing a quantity of one item into a named carton—and names the main fields involved. It is clear, but it does not explicitly contrast it with siblings such as unpack_item or packing_expect, so it earns 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?

There is no guidance on when to call pack_item versus the other packing-list tools, and no exclusions or prerequisites are mentioned. The only conditional sentence is about omitting unit_grams, which is parameter behavior rather than tool-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?

With no annotations supplied, the description carries the behavioral disclosure and covers it well: it explicitly states the line is deleted (not zeroed) and that the slip will not print an item nobody packed, which is the key disruptive trait. It stops short of addressing reversibility or required permissions, but the most safety-relevant behavior is exposed.

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 wasted words: the first states the action, target, identifier style, and return value; the second explains the crucial delete-vs-zero distinction and its downstream effect. The most identifying 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 two-parameter tool with full schema coverage and no output schema, the description is largely sufficient: it says what is operated on, what is returned, and the important consequence for the shipping slip. Minor gaps are the unspecified format of the returned carton and lack of any error/state conditions, but these are not required for correct invocation.

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

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

Schema coverage is 100%, and the parameter descriptions already give examples such as 'L03' and 'PL-2026-0001', so the baseline is 3. The description adds only the notion that the line corresponds to a carton from which it is removed, which is a minor enhancement over 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 opener uses a specific verb ('Remove') and a precise resource ('one packed line from a packing list by its L01-style id'), plus the return of the carton. This clearly distinguishes it from siblings such as packing_list_delete, pack_item, and carton_add, and from search/report 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?

No sibling tool is named and no explicit when-not-to-use guidance is provided. The 'deleted, not zeroed' sentence strongly implies the intended scenario (correcting a mistaken pack), but an agent is left to infer the alternative paths (e.g., repacking with pack_item) rather than being directed to them.

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