Packrift MCP

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

Annotations already declare readOnlyHint/idempotent/non-destructive, and the description adds real context beyond them: the 25-line cap, that volume discounts are applied automatically, that the buyer supplies address and pays on the site, and what is returned (subtotal after discounts). This is exactly the extra behavioral detail annotations cannot carry.

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 tightly packed sentences with zero filler, and the core action plus item format are front-loaded ahead of the safety caveat and precondition. Nothing can be removed without losing information an agent needs.

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

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

An output schema exists, so return values need not be explained, yet the description still names the returned subtotal. Preconditions, hard limits, side-effect boundaries, and the buyer-side flow are all covered for a single-required-parameter tool.

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

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

Schema coverage is 67%, a middling level. The description usefully re-frames items as SKU + quantity in packs and repeats the 25-line limit, but says nothing about the optional discount_code or the response_format enum's concise/detailed tradeoff beyond 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?

States a specific verb and resource ("Create a checkout link on packrift.com for items the buyer has chosen") and immediately scopes it as a link-generation step, not an order. An agent can tell this apart from siblings like get_bulk_quote_link or get_shipping_estimate without opening 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?

Gives an explicit precondition: "Call it only after the buyer confirms the items and quantities," plus a clear non-goal ("never places an order or charges anyone"). It does not name alternative tools for the quote/estimate paths, so it falls short of a full when/when-not/alternatives treatment.

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 this as a read-only, idempotent, non-destructive, non-open-world operation, and the description adds substantial behavioral context beyond that: cushioning logic by item type (2 in/side for fragile), strength-vs-weight checks, dimensional billable weight comparison, and an 'up to 5 in-stock options' cap. This goes well past what the annotations convey.

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

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

Four sentences, all front-loaded: purpose, required inputs, internal behavior, then the sibling exclusion and return shape. No filler; each sentence adds decision-relevant information.

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

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

An output schema exists, yet the description still summarizes the return shape (inside size, fit, strength, live price, product link) and the option cap. Combined with the rich schema and annotations, nothing an agent needs to call this 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 coverage is 100%, so baseline is 3, but the description adds meaning: units for dimensions and weight (inches, pounds), that weight defaults to an estimate, and examples of plain-language use_case values like 'ceramic mug' and 'laptop'. It supports rather than duplicates the schema.

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

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

States a specific verb and resource ('find the right Packrift box or mailer for an item') and scopes it to the buyer's shipping use case. It is clearly distinguishable from generic siblings like search_products or get_product.

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

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

Explicitly names the alternative and the condition that selects it: 'Use search_products instead when the buyer already knows the packaging size they want.' It also states the required inputs, so the agent knows what must be gathered before calling.

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 (readOnly, idempotent, non-destructive). The description adds real behavioral context beyond that: the link is pre-filled from the supplied fields, the buyer adds email and submits on packrift.com, and Packrift replies by email with pricing. It still doesn't state link lifetime or rate limits, but the workflow disclosure is substantial.

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 tight sentences, front-loaded with the purpose before the field-completion instruction and the return explanation. No filler, though the closing return-value sentence is partly redundant given the output 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 read-only link builder with full schema coverage and an output schema, the description covers purpose, trigger conditions, how inputs are consumed, and the human handoff that follows. An agent has everything needed to call it correctly and explain the outcome to the user.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by explaining that the supplied values are carried into the form ('the spec, quantity, delivery ZIP and need-by date travel with the request'), telling the agent these fields pre-fill the buyer's request rather than merely filtering a response.

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 ('Get a pre-filled quote request link') and enumerates the exact scenarios it covers (pallet/recurring quantities, custom sizes, printed/branded packaging, freight, non-stocked specs), which clearly separates it from siblings like create_cart_url or get_shipping_estimate.

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 when-to-use conditions ('any spec Packrift does not stock exactly'), so an agent knows to route here instead of product lookup tools. It does not name the sibling tools as alternatives, leaving that inference to the agent, which keeps it 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds useful behavioral context: it returns live price, live stock, ship-now feasibility for a given quantity, and volume pricing. It does not cover failure behavior (e.g., unknown SKU, or neither identifier supplied).

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 identifier and the payoff, with the routing guidance second. The long field enumeration in sentence one is dense but all of it is informative rather than 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?

An output schema exists, so return values need not be explained, yet the description summarizes them helpfully and routes the agent correctly. The one remaining gap is that zero parameters are required, and the description never says what to do if neither sku nor handle is available.

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 meaning beyond the schema: it frames sku/handle as alternatives, explains that quantity exists to check whether that amount can ship now, and notes the product link is returned. It does not clarify the SKU-vs-handle precedence when both are passed.

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 ('Get one Packrift product by SKU (or product handle)') and enumerates the returned content area (specs, price, stock, volume pricing, link). It is clearly distinguishable from the sibling retrieval tools search_products and find_packaging_for_item, 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?

Explicitly says to use it 'after search_products or find_packaging_for_item when the buyer wants more detail before choosing,' naming both alternatives and the condition that selects this tool. The retrieval-then-detail sequencing is unambiguous.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and non-open-world, so the safety profile is largely covered. The description adds genuine behavioral context beyond that: discounts are applied automatically, shipping is free only when the order qualifies, and tax is excluded. Return shape is also summarized, though no rate limits or failure modes are mentioned.

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 core purpose is front-loaded in the first sentence, followed by input format, return fields, and limits. Every sentence carries information, though the enumeration of returned fields is slightly list-like. 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?

An output schema exists and the description still summarizes the key returned values (discounted subtotal, shipping charge, delivered total, per-unit cost). Combined with annotations covering safety and idempotency, and the schema covering inputs, an agent has everything needed to call this correctly and interpret 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 every parameter is already documented in the schema, and the description adds little syntax beyond restating that items are SKU + quantity (number of packs). The response_format tradeoff (concise vs detailed) is explained in the schema rather than the description. Baseline 3 is appropriate when the schema carries the parameter 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?

States a specific verb (Estimate) plus the exact resource (delivered cost of a Packrift order to a US ZIP), and immediately scopes it with 'using the same shipping rates and automatic volume discounts as Packrift checkout.' It also distinguishes itself from adjacent concerns by excluding carrier rate shopping and postage, so an agent can tell it apart from siblings like get_product or create_cart_url.

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 signals when to use it (pre-checkout delivered-cost estimation against real Packrift rates) and adds an explicit exclusion ('Not for carrier rate shopping or postage'). It also warns that tax is excluded and checkout shows the final amount. It stops short of naming a sibling alternative for the checkout/final-amount case, so it is clear context without full when-not routing.

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

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

Annotations already declare readOnlyHint/idempotentHint, so safety is covered. The description adds genuinely useful behavior beyond that: result cap behavior, the fields returned (live price, pack size, price per unit, stock, link), and the important guarantee that near-miss sizes are marked not exact with a quote link fallback.

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 scope and query forms before the sibling routing rule at the end, which is the right ordering. It is somewhat long, but each sentence carries distinct information (categories, query forms, return shape, non-exact behavior, alternative tool) rather than restating 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?

Even though an output schema exists (so return values need not be spelled out), the description summarizes output shape and the non-exact-match fallback, and it covers query, limits, and the alternative tool. An agent has everything needed to call this correctly and 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 description coverage is 100%, so the schema already documents query, limit, and response_format, and the baseline is 3. The description adds some query-shape guidance (type vs. exact spec vs. SKU) but does not clarify limit or response_format semantics beyond what the schema states, so it does not substantially exceed the baseline.

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 (search the in-stock packaging catalog) and enumerates the product categories covered, so the agent immediately understands the domain. It also names the sibling it is not (find_packaging_for_item) and the condition separating 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?

Explicitly describes acceptable query forms (product type, exact size/spec, Packrift SKU) with concrete examples, and gives a clear exclusion rule: if the buyer describes the item being shipped rather than the packaging, route to find_packaging_for_item. When-to-use and when-not-to-use are both present.

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