Skip to main content
Glama
Sign In

Nuira

by ai.nuira
OverviewDiscussionsAdmin

Top products

get_top_products
Read-onlyIdempotent

The products that earned the most in the current period (ten unless limit asks for up to 50), largest net sales first, with netSales (after returns: the figure to quote as what it sold), revenueBeforeReturns, returns, units, cost (what those units cost), grossProfit, marginPct, and changePct against previousRevenue (revenue before returns). Each row also carries revenueShare — its fraction of the listed products' revenue — and rankedRevenue is their combined total, so a breakdown by product needs no arithmetic of your own. mostProfitable lists them by grossProfit and highestMargin by marginPct (with enough units to mean something), each already ranked: use those lists, in their order, instead of ranking the rows yourself. Use when asked which products sell best, which are growing or slowing, which are most profitable, or for a breakdown of revenue by product. A null cost, grossProfit or margin means costs are missing for that product, not that it earns nothing — never treat a null as zero and never fill one in by subtracting. If truncated is true some orders had more line items than Shopify returns at once, so the split is partial — say so. 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.
limitNoHow many products, 1 to 50; omit for 10. Ask for more when the product in question is not in the top ten.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / limit
      Added value: +{
+  "description": "How many products, 1 to 50; omit for 10. Ask for more when the product in question is not in the top ten.",
+  "maximum": 50,
+  "minimum": 1,
+  "type": "integer"
+}
  2. Changed2 schema fields changed
    • addedInput schema / properties / from / description
      Added value: +"First day of the span, inclusive, as YYYY-MM-DD. Send together with `to`, or omit both to read the default 30-day period."
    • addedInput schema / properties / to / description
      Added value: +"Last 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."
  3. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds behavior those annotations cannot convey: the default 30-day window, the sort order, what `truncated` means and that partial splits should be disclosed, and that null cost/grossProfit/margin signal missing cost data that must never be treated as zero or back-filled. That is precisely the extra context the annotations leave open.

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 resource and ranking, then the return fields, then the usage triggers and date caveats — a sensible order. It is dense and long, but with no output schema the field glossary (revenueShare, rankedRevenue, mostProfitable, highestMargin) is load-bearing rather than padding; only the date-format restatement duplicates the schema.

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?

There is no output schema, so the description carries the full burden of explaining return values, and it does: the metric set, the pre-ranked `mostProfitable`/`highestMargin` lists, how revenueShare and rankedRevenue work together, and the null/truncation caveats. An agent can answer the question and qualify the result correctly from the definition alone.

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%, so all three params are already documented, but the description still adds operative meaning: from/to must be sent together, never after today, and must be supplied whenever the operator named a period; `limit` defaults to 10 and should be raised on a miss. The remaining schema-covered ground (date format) is restated rather than extended, so not quite a 5.

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 and scope: products earning the most in the current period, sorted by net sales, default 10 / max 50. The enumerated use cases ('which products sell best, which are growing or slowing, which are most profitable, or for a breakdown of revenue by product') let an agent place it against siblings like get_product_performance or get_product_trends without opening a schema.

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 explicit when-to-use triggers and a hard routing rule: a named month, a week, or two operator-supplied dates MUST be passed as from/to, because the default read is the last 30 days and 'is not that month'. It also tells the agent when to raise `limit` (when the product in question is not in the top ten), which is a real invocation decision.

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

All Nuira toolsInspect
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