Skip to main content
Glama

Inspect my listing's stock age evidence

supercatch_get_listing_stock_aging
Read-onlyIdempotent

Read one exact owned listing's native stock snapshot under live VIEW_ANALYTICS permission. Separate received-date and acquisition-date FIFO attribution describes the same on-hand units, never physical age; do not add the two bases. Current reservations and available quantity are separate, with holds unallocated to dated stock. Undated historical stock stays unknown. More than 500 captured movements returns explicit history_limit with unknown age attribution. Listing creation time never supplies a receipt date. No stock, prices, dates or provider state are changed; this is not a store-wide report. Use supercatch_get_listing_stock_aging for this read in the connected account. Supply only the fields in its strict input schema. No prices, inventory, orders, automation, marketplace publication or provider configuration are changed. Returns a Shared MCP Baseline 1.0.0 envelope with explicit scope, provenance, unknown values, omissions and typed errors. Requires OAuth store:read consent. Requires store:read consent, a currently approved owned store and live VIEW_ANALYTICS permission. Native dated movement evidence is FIFO attribution, not verified physical unit age. Unknown history and dates remain explicit. Read-only and unmetered; no persistent plans or provider submissions. Invalid fields, unavailable stores and foreign or deleted targets fail without private records. Expired cursors require a fresh search. Provider failures are explicit errors.

Example tool call

This call uses example arguments supplied in the tool’s input schema.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "listing_id": "owned-listing-id"
    },
    "name": "supercatch_get_listing_stock_aging"
  }
}

Input Schema

NameRequiredDescriptionDefault
listing_idYesExact owned listing ID resolved by supercatch_search_listings; no catalog, actor or store override.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.2/5.0
Behavior5/5

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

Annotations already cover read-only, idempotent, non-destructive and closed-world, and the description still adds substantive behavior: FIFO attribution is not physical age, the two date bases must not be summed, reservations/holds are unallocated to dated stock, undated history stays unknown, and >500 movements returns history_limit. It also discloses cursor-expiry and error behavior that annotations cannot express.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core meaning is front-loaded, but the text is padded with near-verbatim repetition: consent is stated twice, and 'no stock, prices, dates or provider state are changed' is repeated as 'no prices, inventory, orders... are changed'. The self-referential sentence 'Use supercatch_get_listing_stock_aging for this read' and the 'Requires OAuth store:read consent. Requires store:read consent...' duplication cost real space without adding information.

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?

An output schema exists, yet the description still sketches the Shared MCP Baseline envelope, explicit unknowns, provenance and typed errors. Combined with the permission prerequisites, the 500-movement limit and the FIFO caveat, an agent has everything needed to call this correctly and interpret gaps in the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single listing_id parameter is fully documented in the schema, including that it comes from supercatch_search_listings. The description adds only the constraint 'supply only the fields in its strict input schema', which restates the schema rather than extending it, so the baseline 3 applies.

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 and resource: 'Read one exact owned listing's native stock snapshot', and adds the scope qualifier 'this is not a store-wide report'. That distinguishes it from siblings like supercatch_get_listing, supercatch_get_store_inventory and supercatch_list_store_listings for an agent scanning the tool list.

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 clear operating context: requires OAuth store:read consent, a currently approved owned store, and live VIEW_ANALYTICS permission, plus the instruction to supply only strict-schema fields. It also excludes store-wide use. The gap is that it never names the sibling to use instead for store-wide or physical-age questions, so routing away is left implicit.

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