Argo Hub Coste de Devoluciones

Ecommerce return rate and returns cost calculator

calculate_return_costs

Read-only

Calculate return rate and operational returns costs for the same order cohort. Separate return freight, handling, reconditioning and actual product losses. Amounts exclude VAT. This is not store profit accounting: it does not automatically add sales refunds, lost margin or customer acquisition costs. With no returns, variable costs are zero and cost per return is undefined. Fixed costs still require a value. The tool does not determine contractual returns eligibility. Input fields: fulfilledOrders: Use the same group and observation window as the returns. returnedOrders: Count returned orders, not units or repeated requests. returnFreight: Average return freight borne by your business; 0 if none. processing: Receipt, inspection and administration. Avoid double counting. reconditioning: Include new packaging where applicable. Enter 0 if absent. productLoss: Only truly unrecoverable cost, averaged across all returns. Resellable stock is not a loss. fixedPeriodCosts: Total for the same scope. Blank does not mean zero.

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": {
      "fulfilledOrders": "<fulfilledOrders>",
      "returnedOrders": "<returnedOrders>"
    },
    "name": "calculate_return_costs"
  }
}

Input Schema

Name	Required	Description	Default
`processing`	No
`productLoss`	No
`returnFreight`	No
`reconditioning`	No
`returnedOrders`	Yes
`fulfilledOrders`	Yes
`fixedPeriodCosts`	No

Output Schema

Name	Required	Description	Default
`tool`	Yes
`method`	Yes
`status`	Yes
`metrics`	Yes
`sources`	Yes
`currency`	No
`limitations`	Yes
`vatIncluded`	No
`pendingFields`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 12, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare a safe read-only, closed-world operation, and the description adds substantial context on top: amounts exclude VAT, variable costs collapse to zero with no returns while cost per return becomes undefined, fixed costs still require a value, and blank does not mean zero. These are exactly the edge behaviors an agent cannot infer from the annotations or schema.

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-loads the core purpose, then moves through exclusions, edge cases, and a parameter glossary in a logical order with almost no filler. Some sentences are dense and run together (the exclusions and zero-return behavior could be separated more sharply), but nothing is redundant.

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?

For a seven-parameter calculator with an output schema present, the description supplies everything needed: what is computed, what is excluded, how degenerate inputs behave, and how each input should be measured. Return-value description is correctly omitted since an output schema exists.

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 description coverage is 0%, so the description carries the full burden and does so for every one of the seven fields, defining each cost bucket and warning against double counting and counting units instead of orders. The one shortfall is that units, averaging basis and acceptable ranges are left implicit, but meaning is substantially clarified beyond the bare numeric schema.

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 ('Calculate return rate and operational returns costs') scoped to a single order cohort, then immediately bounds the purpose against adjacent concepts such as store profit accounting and contractual returns eligibility. An agent knows exactly what computation it is invoking.

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

Usage Guidelines4/5

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

Gives strong context for correct use: fulfilled and returned orders must share the same group and observation window, and it explicitly rules out use as profit accounting or eligibility determination. No sibling tools exist to route between, so the absence of alternative-naming is not a gap, though the guidance is stated as constraints rather than a when-to-use narrative.

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

All Argo Hub Coste de Devoluciones tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?