Skip to main content
Glama
Sign In
shopify-multi-mcp

shopify-multi-mcp

by fledgeling-co
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

List orders

list_orders
Read-only

Lists orders from a specified Shopify store newest first, filters with Shopify order search syntax such as financial_status:paid, and supports pagination to retrieve more results.

Instructions

List orders in one store, newest first. "query" uses Shopify order search syntax, for example financial_status:paid, fulfillment_status:unfulfilled, created_at:>=2026-10-01, name:#1001. Without the read_all_orders scope Shopify only returns the last 60 days. For customer names, line items or addresses use graphql_query.

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": {
      "store": "<store>"
    },
    "name": "list_orders"
  }
}

Input Schema

NameRequiredDescriptionDefault
afterNoPass pageInfo.endCursor from the previous result to get the next page.
firstNoHow many results to return (1-100).
queryNoShopify order search query.
storeYesNo stores are connected yet. Call connect_store first.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.1

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint and openWorldHint=false; the description adds real behavioral context beyond them — the newest-first default ordering and, critically, that without the read_all_orders scope Shopify caps results at 60 days. That auth/scope constraint is exactly the kind of non-obvious behavior an agent must know before interpreting an empty or short result.

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?

Three sentences, each earning its place: what it does, how to filter, what it cannot return. The core purpose and ordering are front-loaded and nothing is padded.

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 4-parameter read tool with no output schema, the description covers scope, filtering syntax, ordering, and the sibling escape hatch. It stops short of describing the 60-day cutoff's effect on pagination or the fields an order record carries, but an agent has enough to call it correctly.

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?

Schema coverage is 100%, so the baseline is 3; the description exceeds it by supplying concrete query-syntax examples (`financial_status:paid`, `created_at:>=2026-10-01`) that make the free-form `query` parameter usable without external docs. It does not touch `after`/`first`, but the schema already documents those fully.

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 orders in one store") plus ordering semantics ("newest first") in the first clause. It also differentiates itself from the sibling graphql_query by naming the exact data types this tool cannot return.

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?

Gives an explicit exclusion: for customer names, line items or addresses, use graphql_query instead. It also names the concrete query filter forms (financial_status, fulfillment_status, created_at, name) an agent should reach for, so selection and invocation are unambiguous.

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