Skip to main content
Glama

Packrift Packaging

by com.packrift.mcp

Create cart handoff URL

create_cart_url
Read-onlyIdempotent

Build the checkout handoff URL once the buyer has confirmed an exact product, quantity, live price, and stock. Preferred input is sku plus quantity; use items only when you already hold variant IDs as strings. Returns a tracked packrift.com cart URL plus a Shopify cart permalink; it never places an order.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
skuNoShortcut for exact Packrift SKUs such as 1066, MFL1295, or LL251WR. When provided without items, the approved variant is resolved automatically.
itemsNoAdvanced path for agents that already have approved variant IDs. Most buyers should use sku plus quantity instead.
quantityNoBuyer-confirmed quantity to use with sku shortcut. Ignored when items is provided.
journey_idNoOptional continuity ID echoed from an earlier search or pricing result in this conversation.
match_typeNoOptional continuity label describing how the product was matched, echoed from earlier results.
selected_skuNoBuyer-confirmed SKU. When provided, it must resolve to the same catalog item as the cart variant.
discount_codeNoOptional discount code to apply to the cart.
result_set_idNoOptional continuity ID echoed from the result set the buyer chose from.
source_contextNoOptional short context label for the handoff, such as exact_match, reorder, or quote_followup.
selected_handleNoBuyer-confirmed product handle. When provided, it must resolve to the same catalog item as the cart variant.

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and idempotentHint. The description adds that the tool 'never places an order' and returns 'a tracked packrift.com cart URL plus a Shopify cart permalink', which gives concrete behavioral context beyond 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.

Conciseness5/5

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

Three sentences, each with a distinct purpose: purpose/precondition, input guidance, and output/side-effect. No filler. Front-loaded with the action.

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

Completeness4/5

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

With 10 parameters fully described in the schema and annotations covering safety, the description supplies the missing context about when to invoke and what to expect. It doesn't describe return format details, but output schema is absent anyway; the mention of the two URLs suffices.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3. The description adds value by recommending 'sku plus quantity' over 'items' and clarifying that items are for when variant IDs are known. This guidance is not in the schema.

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

Purpose4/5

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

The description clearly states the tool's verb and resource: 'Build the checkout handoff URL' and gives the precondition 'once the buyer has confirmed an exact product, quantity, live price, and stock.' It distinguishes the operation from sibling tools like get_bulk_quote_link and get_reorder_link by focusing on the checkout handoff context, though it does not explicitly name alternatives.

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

Usage Guidelines4/5

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

Provides clear guidance: 'Preferred input is sku plus quantity; use items only when you already hold variant IDs as strings.' Also conditions usage on buyer confirmation. It does not explicitly enumerate when-not-to-use relative to sibling tools, but the context is clear.

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

All Packrift Packaging toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0
Disambiguation4/5

Most tools have clearly distinct purposes, but there is potential confusion between inventory-checking tools (check_inventory vs. inventory_status) and cart-handoff tools (create_cart_url vs. prepare_purchase_handoff). Descriptions help differentiate, but an agent might occasionally select the wrong tool.

Naming Consistency4/5

The naming convention is generally consistent with verb_noun in snake_case (e.g., find_packaging_for_item, get_pricing). However, google_retail_ai_finder breaks the pattern with a company prefix, and some verbs vary (check vs. inventory_status). Overall clear and predictable.

Tool Count4/5

16 tools is slightly above the ideal 3-15 range, but still reasonable for a packaging e-commerce domain covering search, fit, inventory, pricing, shipping, and cart creation. Each tool serves a specific need, so the count feels appropriate.

Completeness4/5

The tool surface covers the core customer journey: product discovery, fit calculation, inventory/pricing checks, shipping estimation, cart handoff, reordering, and bulk quotes. Minor gaps exist (e.g., no order tracking or cancellation), but these are likely out of scope.

Resources