Skip to main content
Glama

Packrift MCP

by io.github.Packrift

Prepare purchase handoff

prepare_purchase_handoff
Read-onlyIdempotent

Two-step exact-SKU purchase prep. Call first with sku, quantity, and buyer_confirmed=false to confirm the product, live price, and live stock in one call. After the buyer approves, call again with buyer_confirmed=true to receive the tracked checkout handoff URL. It never places an order.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
skuYesExact Packrift SKU such as 1066, MFL1295, or LL251WR.
quantityNoBuyer-selected quantity. Defaults to 1.
journey_idNoOptional continuity ID echoed from an earlier search or pricing result in this conversation.
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_sku_reorder or quote_followup.
buyer_confirmedNoSet true only after the buyer confirms the exact SKU and quantity. Without this, no cart URL is created.

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already indicate read-only, open-world, and idempotent behavior. The description adds the critical two-step workflow and the requirement for buyer confirmation, which is not inferable from annotations alone.

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?

Two sentences, front-loaded with the core purpose and flow. No superfluous content; every sentence earns its place.

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?

Despite no output schema, the description states the final output (tracked handoff URL). The two-step protocol is fully described, and with complete schema coverage and annotations, the tool is sufficiently specified.

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?

With 100% schema coverage, the baseline is 3. The description adds context around buyer_confirmed (set only after approval) and explains the overall flow, which helps parameter understanding beyond the schema.

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

Purpose5/5

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

The description clearly states a two-step exact-SKU purchase preparation tool, explaining both calls and that it never places an order. This distinguishes it from sibling tools like create_cart_url and get_cart_handoff_candidates.

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?

Explicit instructions: call first with buyer_confirmed=false to confirm details, then again with buyer_confirmed=true to get the handoff URL. It also clarifies it never places an order, providing a clear boundary. Alternatives are not explicitly named, 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 MCP 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.7/5.0
Disambiguation2/5

Several tools have overlapping purposes: check_inventory and inventory_status both focus on live stock, find_packaging_for_item and pack_calculator both handle dimension-based fitting, and create_cart_url, prepare_purchase_handoff, and get_cart_handoff_candidates all revolve around cart handoff. While descriptions add some clarity, an agent could easily select the wrong tool without careful reading.

Naming Consistency4/5

Most tools follow a verb_noun pattern (e.g., check_inventory, get_pricing, search_products), but inventory_status and pack_calculator are noun-based and break the convention. The naming is still predictable and readable overall.

Tool Count4/5

15 tools is at the upper edge of the ideal range, and the count feels slightly inflated due to overlapping inventory and cart-handoff tools. However, each tool has a defined purpose in the procurement workflow, so the count is not excessive.

Completeness5/5

The tool surface covers the full buyer journey: search, fit calculation, comparison, product detail, inventory check, pricing, cart creation, purchase handoff, shipping estimates, quotes, and reorder links. No critical dead ends were found.

Resources