Skip to main content
Glama
Sign In

Nuira

by ai.nuira
OverviewDiscussionsAdmin

Stock value and dead stock

get_stock_overview
Read-onlyIdempotent

Stock and fulfilment figures for the current period: units shipped, inventory value at cost (inventoryValue), average days of stock cover, dead stock value (stock that sold nothing in the period) and the share of SKUs whose stock is tracked, each with previous; the dead-stock list (deadStock.rows: SKU, units on hand and their value at cost, largest first; totalCount and totalValue over all of it; unpricedCount = dead SKUs with no cost to value them by); stock value per category (valueByCategory); and data gaps (coverage: untracked variants, variants missing a cost, feed issues blocking listings). Use for inventory value, dead or slow stock, overstock, what to clear out, or stock by category. For what runs out soonest use get_inventory_health; for the 30-day restock forecast use get_restock_forecast. 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.

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?

Beyond the read-only/idempotent annotations, the description explains the default 30-day period, the inclusive date-span rules, what 'dead stock' means, the ordering and totals behavior of deadStock.rows, and data-gap coverage issues. This is substantive behavioral context an agent needs in order to interpret the results correctly.

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?

The description is dense but front-loaded, first naming the metrics and then giving usage routing and date-window rules. It is appropriately sized for a rich reporting tool, though the single long paragraph and repeated use-case phrasing make it slightly heavier than necessary.

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, but the description explains the returned concepts and key nested fields well enough for an agent to know what the tool provides. It also covers the critical default-period behavior and the sibling alternatives, leaving no major ambiguity for invocation.

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 the schema already documents from/to syntax and the both-or-neither default behavior. The description adds operational meaning by stressing that a named month, week, or operator-supplied date pair MUST be sent as from/to, otherwise the tool reads the last 30 days and will not match that period.

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?

The description states a specific resource and scope: stock and fulfilment figures for the current period, with named metrics such as inventory value, stock cover, dead stock, value by category, and coverage gaps. It also distinguishes this tool from get_inventory_health and get_restock_forecast by naming what each sibling is for.

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?

It gives explicit use cases (inventory value, dead or slow stock, overstock, what to clear out, stock by category) and routes adjacent needs to named alternatives: get_inventory_health for what runs out soonest and get_restock_forecast for the 30-day restock forecast. It also gives a crucial when-to-use rule for named months or date ranges.

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