Skip to main content
Glama
Sign In
starshipit-mcp

starshipit-mcp

by devkindhq
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

List Unshipped Orders

starshipit_list_unshipped_orders
Read-onlyIdempotent

Retrieve unshipped orders from StarShipIt to review your pending fulfilment queue, with optional date filters and pagination. Use it to identify orders imported but not yet shipped.

Instructions

List unshipped orders from StarShipIt. Returns orders that have been imported but not yet shipped.

When to use: Call this to see your pending fulfilment queue. It is read-only and safe to call multiple times.

Parameters:

  • since_order_date (optional) — Only return orders placed after this ISO 8601 timestamp (e.g. "2024-01-01T00:00:00Z")

  • since_last_updated (optional) — Only return orders last updated after this ISO 8601 timestamp

  • limit (optional, default 50, max 250) — Number of results per page

  • page (optional, default 1) — Page number for pagination

  • response_format (optional) — "markdown" (default) or "json"

Returns: List of Order objects including destination, items, packages, and carrier assignment. The response includes a has_more flag when further pages exist.

Example response (JSON):

{
  "orders": [{ "order_id": 10001, "order_number": "#1001", "carrier": "AUSPOST", "destination": { "name": "Jane Smith", ... } }],
  "total": 120,
  "has_more": true,
  "page": 1
}

Errors: 401 if API keys are missing or invalid; 429 if rate-limited.

Input Schema

NameRequiredDescriptionDefault
pageNoPage number for pagination (default: 1)
limitNoMaximum number of results to return (default: 50, max: 250)
response_formatNoOutput format: 'markdown' for human-readable or 'json' for machine-readablemarkdown
since_order_dateNoOnly return orders placed after this ISO 8601 timestamp (e.g. 2024-01-01T00:00:00Z)
since_last_updatedNoOnly return orders last-updated after this ISO 8601 timestamp

Output Schema

NameRequiredDescriptionDefault
errorsNoValidation or processing errors returned by StarShipIt
objectNoThe response payload when StarShipIt returns a non-object value
successNoStarShipIt success flag (a boolean on most endpoints)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the description's "read-only and safe to call multiple times" mostly restates them. It does add genuinely new behavioral context: pagination semantics via the has_more flag, default limit and max cap, and concrete failure modes (401 for missing/invalid API keys, 429 for rate limiting) that annotations cannot express.

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?

Headers are front-loaded and scannable, with purpose and when-to-use before details. There is some redundancy: the full parameter list restates a 100%-covered schema, and the JSON example response duplicates ground already covered by the existing output schema, so a few lines do not earn their 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?

For a paginated read tool, the definition covers pagination, filtering, output format, and error codes, which is more than enough to invoke it confidently — and the output schema means return values need not be re-explained (making the JSON example optional rather than load-bearing). The only real gap is routing guidance among the many order-listing siblings.

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 every parameter is already documented in the schema, and the description's parameter block largely mirrors it. The one small addition is the worked ISO 8601 example, but the schema already carries an equivalent example string, so meaning added beyond structured data is minimal — baseline 3 applies.

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 ("List unshipped orders from StarShipIt") and immediately defines the resource boundary: "orders that have been imported but not yet shipped." That definition alone distinguishes it from siblings like starshipit_list_shipped_orders and starshipit_list_delivered_orders without needing to name them.

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?

The "When to use" block gives a clear trigger ("see your pending fulfilment queue") plus a safety/retry statement. It stops short of explicit exclusions or alternatives — it never says to use starshipit_search_orders when filtering by customer, or starshipit_list_shipped_orders for completed orders — so an agent must infer routing from the sibling names.

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

Deploy Server

Other Tools