starshipit-mcp

Print Shipping Label

starshipit_print_label

Print or reprint a shipping label for one StarShipIt order, with optional carrier, service, and package overrides; returns label data and tracking details.

Instructions

Print (or reprint) a shipping label for a single order in StarShipIt.

When to use: Use this tool when you need to generate a carrier label for one specific order. If you are printing labels for multiple orders at once, prefer starshipit_print_labels for efficiency.

Parameters:

order_id (required): The numeric StarShipIt order ID to print a label for.
carrier (optional): Carrier code to override the order's default carrier (e.g. "AUSPOST", "DHL").
carrier_service_code (optional): Carrier service code to override the order's default service (e.g. "EXPRESS", "PARCEL_POST").
packages (optional): Array of package dimensions/weights to use for the label. Each package has weight (kg, required), and optional height, width, length (all in metres).
reprint (optional): Set to true to reprint a previously generated label. Defaults to false.

Returns: An object containing label URLs or base64-encoded label data for the order, along with the assigned tracking number, carrier, and service. On error, returns a descriptive error message.

Example success response:

{
  "success": true,
  "labels": [
    {
      "order_id": 12345,
      "tracking_number": "1Z999AA10123456784",
      "label_url": "https://cdn.starshipit.com/labels/label-12345.pdf",
      "carrier": "UPS",
      "carrier_service": "EXPRESS"
    }
  ]
}

Error cases: 400 if the order ID is invalid or required order data is missing; 404 if the order does not exist; 409 if a label has already been printed and reprint is not set to true.

Input Schema

Name	Required	Description
`carrier`	No	Carrier code to override the order default (e.g. "AUSPOST", "DHL", "UPS")
`reprint`	No	Set to true to reprint a previously generated label (default: false)
`order_id`	Yes	The StarShipIt order ID to print a label for
`packages`	No	Package dimensions for the label. weight in kg; height/width/length in metres
`carrier_service_code`	No	Carrier service code to override the order default (e.g. "EXPRESS", "PARCEL_POST")

Output Schema

Name	Required	Description
`errors`	No	Validation or processing errors returned by StarShipIt
`object`	No	The response payload when StarShipIt returns a non-object value
`success`	No	StarShipIt success flag (a boolean on most endpoints)

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 3, 2026

TDQS

A4.4/5.0

Behavior4/5

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

The annotations already declare this is a non-read-only, open-world, non-idempotent, non-destructive operation. The description adds useful behavioral context beyond those annotations: reprint defaults to false, a 409 occurs when a label already exists and reprint is not true, and the return includes label data plus tracking/carrier/service. It does not discuss permissions or rate limits, but the important operational behavior for this mutation is well covered.

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?

The description is front-loaded and clearly organized with When to use, Parameters, Returns, and Error cases. It is somewhat longer than necessary because it repeats parameter details and includes a full success-response example even though an output schema exists, but the structure remains easy to scan.

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?

For a single-order label-printing mutation with rich annotations and an output schema, the description supplies the use case, all parameter meanings, reprint semantics, return shape, and the key error cases including 400/404/409. An agent has enough information to call the tool correctly and interpret likely failures.

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%, and the input schema already documents all five parameters, including the package weight and dimension fields. The description restates those meanings and adds carrier/service examples, but it does not add substantial semantics beyond the schema, so the baseline 3 is appropriate.

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 gives a specific verb and resource: print or reprint a shipping label for a single StarShipIt order. It explicitly distinguishes the single-order case from the bulk sibling `starshipit_print_labels`, so an agent can choose between them without opening either schema.

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?

It states exactly when to use this tool and when to use an alternative: one specific order versus multiple orders, where the bulk tool is preferred. That covers both the primary use case and the routing condition to the sibling tool.

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

Deploy Server