Packrift MCP

Search Packrift packaging

search_products

Read-onlyIdempotent

Search Packrift's in-stock packaging catalog: corrugated shipping boxes, mailer boxes, poly and bubble mailers, poly bags, labels, packing tape, stretch film and void fill. The query can be a product type, an exact size or spec ("12x12x12 ECT-32 box", "10x13 poly mailer", "3 inch packing tape"), or a Packrift SKU. Returns up to 10 matches with live price, pack size, price per unit, stock and a product link. A different size is never labeled exact; when nothing matches exactly it returns the closest sizes marked as not exact and a quote link. If the buyer describes the item they are shipping rather than the packaging they want, use find_packaging_for_item instead.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "query": "<query>"
    },
    "name": "search_products"
  }
}

Input Schema

Name	Required	Description	Default
`limit`	No	Maximum results to return.
`query`	Yes	What the buyer wants, e.g. "12x12x12 boxes", "white poly mailers 14.5x19", "SKU 1066".
`response_format`	No	concise (default) returns the essentials. detailed returns the full catalog record; use it only when a field you need is missing.	concise

Output Schema

Name	Required	Description	Default
`query`	No
`results`	No
`quote_url`	No
`closest_sizes`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 27, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "closest_sizes": {
+      "type": "array"
+    },
+    "query": {
+      "type": "string"
+    },
+    "quote_url": {
+      "type": "string"
+    },
+    "results": {
+      "type": "array"
+    }
+  },
+  "type": "object"
+}

Changed6 schema fields changedSep 27, 2026

addedInput schema / additionalProperties
```
Added value: +false
```
changedInput schema / properties / limit / default
```
Previous value: -10New value: +5
```
addedInput schema / properties / limit / description
```
Added value: +"Maximum results to return."
```
changedInput schema / properties / limit / maximum
```
Previous value: -50New value: +10
```

changedInput schema / properties / query / description

Previous value: -"Free-text search; matches title, vendor, type, tags."New value: +"What the buyer wants, e.g. \"12x12x12 boxes\", \"white poly mailers 14.5x19\", \"SKU 1066\"."

addedInput schema / properties / response_format

Added value: +{
+  "default": "concise",
+  "description": "concise (default) returns the essentials. detailed returns the full catalog record; use it only when a field you need is missing.",
+  "enum": [
+    "concise",
+    "detailed"
+  ],
+  "type": "string"
+}

First observedApr 30, 2026

TDQS

A4.6/5.0

Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

All Packrift MCP tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.