ActionShip by Teapplix Demo

Purchase Label for Order

teapplix_purchase_label_for_order

Destructive

Purchase a shipping label for an existing Teapplix order. Requires TxnId, From (ship-from address or profile), and a Packages array (each package must include Method; Weight and Dimensions default to the order's stored values if omitted). [DEMO]

Input Schema

Name	Required	Description
`From`	Yes	Ship-from address OR a saved shipping profile — supply exactly one shape.
`TxnId`	Yes	Teapplix order ID to purchase label for.
`Options`	No	Advanced, rarely used. Omit unless the user explicitly requests features such as signature confirmation, insurance type, COD, etc.
`Packages`	Yes	One or more packages. The first entry is the main package; additional entries are extra packages. Each package must include Method; Weight and Dimensions default to the order's stored values if omitted. All packages must use the same carrier.
`Provider`	No	Force the label provider. MARKETPLACE = purchase through the marketplace's carrier accounts at marketplace-negotiated rates (e.g. Amazon Buy Shipping, Walmart shipping programs — same carriers like UPS/FedEx/USPS but at the marketplace's rates); NATIVE = purchase through the seller's own carrier account from the shipping profile. When omitted, the API uses whichever provider is configured on the profile. Works on RATESHOP methods too — forces the winning method to purchase through the specified provider.
`ShipDate`	No	Ship date (YYYY-MM-DD). Defaults to today. Interpreted as Pacific timezone.
`CustomsDeclaration`	No	International shipments only. Omit unless shipping outside the domestic country. Fields: ReasonForExport, IOssNumber, Items: [{Description, Quantity, Value, Weight, HSTariffNumber, CountryOfOrigin}].

Output Schema

Name	Required	Description
`Status`	No
`LabelData`	No	Label bytes; one entry per package. Content is base64-encoded.
`TrackingInfo`	No
`DocumentsData`	No	Additional documents (customs forms, return slips, etc.).
`PostageAmount`	No
`ClientRequestId`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 12, 2026

addedInput schema / properties / Provider

Added value: +{
+  "description": "Force the label provider. MARKETPLACE = purchase through the marketplace's carrier accounts at marketplace-negotiated rates (e.g. Amazon Buy Shipping, Walmart shipping programs — same carriers like UPS/FedEx/USPS but at the marketplace's rates); NATIVE = purchase through the seller's own carrier account from the shipping profile. When omitted, the API uses whichever provider is configured on the profile. Works on RATESHOP methods too — forces the winning method to purchase through the specified provider.",
+  "enum": [
+    "MARKETPLACE",
+    "NATIVE"
+  ],
+  "type": "string"
+}

First observedJul 27, 2026

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, openWorldHint=true, and idempotentHint=false, so the irreversible/real-world nature of a label purchase is partially covered. The description adds the useful defaulting rule for Weight/Dimensions but does not say that this spends money, that cancel_label is the reversal path, or what the unexplained '[DEMO]' tag implies. With annotations carrying the safety profile, a 3 is fair.

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?

Two tightly written sentences that front-load the action and required inputs; little waste. The bracketed '[DEMO]' tag is unexplained and slightly dilutes an otherwise clean structure.

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

Completeness3/5

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

With a rich input schema, an output schema, and annotations covering safety, the description need not explain return values. It is nonetheless thin for a destructive purchase tool: no routing versus teapplix_purchase_label / get_rates_for_order, no note on cost or reversal, and an unexplained demo marker.

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 all seven parameters including nested From/Packages shapes are already documented in the schema. The description restates the three required params and the Weight/Dimensions defaults, but that defaulting rule is also present verbatim in the schema, so added value is minimal. Baseline 3.

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?

States a specific verb and resource (purchase a shipping label) scoped to an existing Teapplix order, which an agent can act on directly. It does not, however, distinguish this from the near-identical sibling teapplix_purchase_label, leaving ambiguity about which of the two applies.

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

Usage Guidelines2/5

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

No when-to-use guidance, no prerequisites (e.g. rates should be fetched first), and no reference to alternatives. Most notably it never acknowledges the sibling teapplix_purchase_label, so an agent has no basis for choosing between the two.

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

All ActionShip by Teapplix Demo 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.

Resources

Need Help?