Skip to main content
Glama

shopify_orders

Retrieve orders from a Shopify store using API credentials, with optional status and limit filters to support order management and automation workflows.

Instructions

Get orders from a Shopify store.

Input Schema

NameRequiredDescriptionDefault
limitNo
statusNo
api_keyNo
shop_domainNo
access_tokenNo
financial_statusNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.1.11
    • changedInput schema / required
      Previous value: -[
      -  "shop_domain"
      -]New value: +[]
  2. Addedv0.1.5

TDQS

C2.1/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden. It implies a read operation ('Get'), which is some information, but it says nothing about authentication requirements (api_key/access_token/shop_domain), pagination via limit, rate limits, or what the result set contains. That is a large gap for a mutation-free but credential-gated integration tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no padding, which is structurally fine. The brevity is not the problem; the problem is that almost nothing useful is packed into it.

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

Completeness1/5

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

Six parameters with no required fields, zero schema descriptions, no annotations, and no output schema. For an integration tool that needs credentials and filter semantics, a four-word description leaves the agent without enough to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across six parameters, and the description mentions none of them. The meanings of status vs financial_status, how limit behaves, and the role of the three credential parameters are entirely undocumented in both structured and natural-language fields.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The verb and resource are stated ('Get orders'), so the domain is clear, and the plural hints at a list operation. But it never distinguishes listing orders from fetching a single order, nor does it differentiate from the many other order/Shopify siblings (shopify_products, shipify_fulfillments, woocommerce orders). It sits at minimum viable rather than distinguishing.

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?

There is no when-to-use guidance, no exclusions, and no mention of alternatives like filtered searches. An agent has no signal about whether this is the right tool for a specific order versus a general listing.

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