Project Tango

Analyze Sales Metrics

analyze_sales_metrics

Calculate gross revenue, average order value, top-selling products, and order fulfillment status breakdown from order history, optionally scoped to one product category.

Instructions

Calculates gross revenue, average order value (AOV), the top-selling products by units sold, and a breakdown of orders by fulfillment status (pending / shipped / delivered), based on current order history. Figures cover all recorded orders; the 'period' field reports the actual date span so a stale dataset is visible. An optional category scopes every figure to products in that category: revenue, units and the trend count only lines of those products, an order counts toward the breakdown and AOV when it contains at least one such line, and the echoed 'filters' block reports the category actually applied.

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": "analyze_sales_metrics"
  }
}

Input Schema

Name	Required	Description	Default
`category`	No	Restrict to a single category, e.g. 'tech', 'apparel', or 'home'. Case-insensitive. Omit to cover the whole catalog.

Output Schema

Name	Required	Description	Default
`trend`	Yes
`period`	Yes
`filters`	Yes
`orderCount`	Yes
`grossRevenue`	Yes
`averageOrderValue`	Yes
`topSellingProducts`	Yes
`orderFulfillmentBreakdown`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv3.2.0Nov 10, 2026

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses that figures span all recorded orders, that the 'period' field exposes a stale dataset, and that an echoed 'filters' block reports the category actually applied. It omits any authorization, cost, or performance caveats, but the data-scope semantics are unusually well spelled out.

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?

It is dense but front-loads the computed metrics before the scoping caveats, and the second paragraph is reserved for the optional category semantics. Every sentence carries information, though the scoping clause is long enough to require re-reading.

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?

An output schema exists, so return values needn't be explained, and the description covers the behavioral scope thoroughly for a single-optional-param read tool. Only the missing when-to-use guidance against sibling tools keeps it from being fully complete.

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 single category param is already documented there, so the baseline would be 3. The description goes beyond the schema by defining exactly how the category scopes each metric (orders count toward AOV/breakdown only when they contain a matching line), which is genuine added meaning.

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 precise verb (calculates) plus the exact outputs: gross revenue, AOV, top-selling products by units, and an orders-by-fulfillment-status breakdown. This is clearly distinguishable from siblings that deal with products, orders, or stock levels rather than aggregate analytics.

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?

The description implies an analytics/reporting use case and notes figures cover all recorded orders, but it never says when to reach for this over find_orders or the restock tools. Usage is inferable from the content but not stated as guidance.

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

Deploy Server