Skip to main content
Glama
Sign In
CommerceWeave MCP

CommerceWeave MCP

by mysterekkk
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

List orders across stores

commerce_list_orders
Read-onlyIdempotent

List orders from all or selected connections across a local day, last N days, or a custom range, normalized and de-duplicated with duplicate flags and masked personal data by default.

Instructions

Lists orders from all (or selected) connections for a local day, last N days, or an explicit range, normalized and de-duplicated: orders imported from another platform are flagged with duplicate (status "confirmed" = same sale proven by ids, "potential" = unproven). Personal data is masked unless includePersonalData=true. complete is false if any connection failed or results were truncated.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "commerce_list_orders"
  }
}

Input Schema

NameRequiredDescriptionDefault
toNoISO 8601 end.
dateNoA single local calendar day, YYYY-MM-DD. Omit with no other range = today so far.
daysNoLast N local days including today so far.
fromNoISO 8601 start (overrides date/days).
timezoneNoIANA timezone for day boundaries, e.g. Europe/Warsaw. Defaults to the server timezone.
connectionIdsNoConnection ids to include (see commerce_list_connections). Omit for all connections.
maxPerConnectionNo
includePersonalDataNoReturn buyer names, e-mails and phone numbers. Off by default; only enable when the task truly needs personal data.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.9/5.0
Behavior5/5

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

Annotations already establish read-only, idempotent, non-destructive, open-world behavior, yet the description adds substantial context beyond them: results are normalized and de-duplicated, cross-platform imports carry a duplicate flag whose 'confirmed' vs 'potential' statuses are explained, personal data is masked by default, and `complete` signals partial failure or truncation. These are exactly the behavioral facts an agent needs to interpret results correctly and cannot get from the annotations.

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?

Three sentences, front-loaded with scope and range modes before the less common dedup and completeness caveats. It is dense with backticked field names but essentially waste-free; only the nested parenthetical on duplicate statuses could be tightened slightly.

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?

With no output schema, the description carries the return-value burden and does well by explaining the duplicate and complete fields and the masking behavior. It stops short of describing the shape of an order record or how maxPerConnection affects the total result size, which would matter for an 8-parameter cross-connection listing tool.

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 88%, so the schema already documents date, days, from, to, timezone, connectionIds, maxPerConnection and includePersonalData with precedence rules. The description echoes the three range modes and the masking default but adds no format, default, or constraint detail beyond the schema, so the baseline of 3 applies.

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?

The description opens with a specific verb and resource ('Lists orders from all (or selected) connections') and enumerates the three supported range modes, so the agent knows exactly what it retrieves. It does not explicitly contrast itself with siblings such as commerce_get_order or commerce_sales_summary, leaving that differentiation to inference.

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

Usage Guidelines3/5

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

Usage context is implied by the range modes and by the instruction to enable includePersonalData only when the task truly needs it, which is genuine guidance. However, there is no explicit 'use this instead of X' routing against commerce_get_order (single order) or commerce_sales_summary (aggregates), and no stated prerequisites.

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