Skip to main content
Glama
Sign In
CommerceWeave MCP

CommerceWeave MCP

by mysterekkk
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Sales summary without double counting

commerce_sales_summary
Read-onlyIdempotent

Summarize gross revenue and order counts per currency and connection for a chosen period, excluding cancelled, refunded, unpaid, and confirmed duplicate orders by default.

Instructions

Gross revenue and order counts per currency and connection for a period. Confirmed imported duplicates (e.g. Base orders imported from Allegro) are excluded; potential duplicates are included but reported separately. Cancelled, refunded and (by default) unpaid orders are excluded. This is revenue, not profit; currencies are never converted.

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_sales_summary"
  }
}

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.
includeUnpaidNo
maxPerConnectionNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare a safe, idempotent read, so the description rightly focuses on semantics: deduplication policy, status exclusions, the unpaid default, and the no-currency-conversion rule. These are non-obvious behaviors an agent could not derive from the schema. It misses two behavioral traits: whether results can be truncated by maxPerConnection (default 1000), and, since no output schema exists, any description of the response shape beyond 'per currency and connection'.

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?

Four tight sentences, each carrying a distinct decision-relevant fact, with the core output definition front-loaded. No filler, no restatement of the tool name, and the caveats clustered after the main purpose.

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 an 8-parameter aggregation tool with no output schema, the definition covers the hard parts: what is counted, what is excluded, grouping dimensions, and duplicate treatment. The remaining gap is silent truncation at maxPerConnection and the absence of any stated response structure beyond the grouping keys.

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 coverage is 75%, so most parameters are already documented, and a 3 is the appropriate baseline. The description only implicitly explains includeUnpaid via 'by default unpaid orders are excluded' and says nothing about timezone handling, range precedence (from overrides date/days), or the maxPerConnection truncation risk.

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 first sentence states a precise verb+resource+grouping: gross revenue and order counts, split per currency and connection, over a period. 'This is revenue, not profit' further disambiguates intent. No sibling tool is named or explicitly contrasted, so an agent must infer on its own that this replaces per-order listing when an aggregate is wanted.

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?

Inclusion/exclusion rules (cancelled, refunded, and by-default unpaid orders excluded; confirmed duplicates dropped; potential duplicates flagged separately) effectively tell the agent what the result will cover. However, there is no explicit when-to-use guidance such as 'use this for revenue rollups; use commerce_list_orders for per-order detail', and no stated caveats about when the tool is the wrong choice.

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