Skip to main content
Glama

Returns analysis

get_returns_analysis
Read-onlyIdempotent

Why returns moved, from the refunds themselves (exact, not an estimate per product). gap splits the change in returns: total = fromEarlierOrders (refunds of orders placed before the period) + fromOrdersInSpan (orders placed in it); reading is the conclusion to state: customers_return_more (more finished months have a higher return rate than a year earlier than a lower one: name monthsWithHigherRate and any monthsWithLowerRate), earlier_sales_landing (most of the rise is refunds of earlier orders and rates are flat), both, mixed (as many months fell as rose: say it is not a clear rise), or unclear (say the data does not settle it). timing says where the refunds of each period came from: returns and refunds (their number), fromOrdersInSpan, fromEarlierOrders, earlierShare, avgDaysToRefund and byOrderMonth (the month each refunded order was placed). cohorts covers the 4 order months ending at the span's last month, each beside the same month a year earlier: sold (gross less discounts) with soldChange, returnedWithin30Days, and returnRate (returnedWithin30Days ÷ sold in both years, with changePoints). A cohort's rate going up means customers really return more; a flat rate with higher returns means refunds of bigger earlier sales landed in this period. mature false = that month's 30 days have not passed, so its rate can still rise: say so and do not conclude from it. Use whenever returns are part of the answer. Optional from and to (inclusive YYYY-MM-DD, both or neither, never after today) read another span instead of the default period. A named month, a week or two dates the operator gave MUST be sent here: without them this reads the last 30 days, which is not that month.

Input Schema

NameRequiredDescriptionDefault
toNoLast day of the span, inclusive, as YYYY-MM-DD; not after today. Send together with `from`, or omit both to read the default 30-day period.
fromNoFirst day of the span, inclusive, as YYYY-MM-DD. Send together with `to`, or omit both to read the default 30-day period.
compareNoWhat to compare the span with: previous (default, the same number of days just before), yoy (the same dates last year) or yoyWeekday (52 weeks back, the same weekdays — use it for natural Monday–Sunday weeks or whenever the operator says 'last year' over weeks).
salesChannelNoOnly online orders (the web shop) or only point-of-sale orders; omit for every channel. When the operator says 'solo web', 'online only' or 'sin POS', send online — and keep sending it for the rest of the conversation.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial context beyond them: the default 30-day window, the inclusive-date and never-after-today constraint, and the `mature: false` caveat that a month's 30 days have not elapsed so its rate can still rise and must not be concluded from. It also prescribes what conclusion to state from `reading`, which is behaviorally important interpretation guidance.

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?

Front-loaded with purpose and trigger, and almost every clause carries information an agent needs, especially since there is no output schema. The cost is a single dense run-on paragraph enumerating many response fields (timing, cohorts, byOrderMonth) that is harder to parse than a structured list.

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

Completeness5/5

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

No output schema exists, yet the description documents the return shape thoroughly — the `gap` decomposition, `reading` enum meanings, `timing` sub-fields, cohort semantics across two years, and the `mature` flag — so an agent can both call the tool and interpret its result without further sources.

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% and the enum descriptions already explain `compare` and `salesChannel`, so the schema does most of the work. The description still adds value by tying parameters to operator language and stating the all-or-neither rule for `from`/`to` and the default-period consequence of omitting them.

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?

Opens with a specific verb+resource framing: "Why returns moved, from the refunds themselves (exact, not an estimate per product)." This distinguishes it from the sibling get_refunds_by_month by claiming causal decomposition (gap splits, cohorts) rather than a plain refund count.

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 trigger ("Use whenever returns are part of the answer") and a hard routing rule for alternatives: without `from`/`to` it reads the last 30 days, so a named month, week, or operator-supplied date range MUST be sent here. It also maps operator phrasing to parameter choices (e.g. 'last year' over weeks → yoyWeekday, 'solo web' → online).

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources