SuperCatch

Prepare an exact dated stock receipt

supercatch_prepare_stock_receipt

Freeze one listing version, positive units, received date, reason and exact follow-up destinations for native approval. Record newly received units on one exact owned listing with an explicit UTC received date and seller reason. Review and approve its exact native plan before execution. Not a stock correction, acquisition-cost record, verified physical possession, checkout, label purchase or provider stock verification. Existing stock-correction consent does not authorize receipt entry. A strict inventory.receive plan or durable operation. The received date is seller testimony. Private approval references and destination delivery identifiers are omitted. Requires OAuth store:inventory:receive consent. Requires fresh store:inventory:receive consent plus current EDIT_LISTINGS on an approved owned store. One listing per nine-minute plan. Execute only with the original plan, stable key and native bound approval. Saves an expiring receipt plan for exact native review. No stock changes. Foreign targets, revoked consent, changed versions, holds or destinations, expired approval and conflicting keys fail. After a lost response, recover the original operation before starting new receipt intent. Local commit and unresolved follow-up remain distinct.

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": {
      "reason": "Received two restock units",
      "quantity": 2,
      "listing_id": "owned-listing-id",
      "received_date": "2026-11-03",
      "expected_version": "2026-11-04T16:00:00Z"
    },
    "name": "supercatch_prepare_stock_receipt"
  }
}

Input Schema

Name	Required	Description
`reason`	Yes	Required seller explanation, frozen for review and native inventory history.
`quantity`	Yes	Positive number of newly received units; native stock and single-copy rules still apply.
`listing_id`	Yes	Exact owned listing ID, never a catalog ID or slug.
`received_date`	Yes	Seller-recorded date of receipt, YYYY-MM-DD in UTC; future dates are refused. This does not verify physical possession or an acquisition date.
`expected_version`	Yes	Exact current listing version returned by SuperCatch.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 8, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Beyond the annotations it discloses the OAuth scope (store:inventory:receive), the paired EDIT_LISTINGS requirement on an approved owned store, a concrete rate constraint ('One listing per nine-minute plan'), the non-mutating nature of the prepare step ('No stock changes'), and an enumerated failure set (foreign targets, revoked consent, changed versions, holds, expired approval, conflicting keys). It also explains the 'lost response' recovery protocol and that private approval references and destination identifiers are withheld, none of which is recoverable from the annotations.

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

Conciseness3/5

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

The first two sentences front-load the action well, but the remainder degenerates into a long run of subjectless fragments ('A strict inventory.receive plan or durable operation.', 'Local commit and unresolved follow-up remain distinct.') that are dense with jargon and repeat concepts already stated. It is information-rich but poorly structured, and the requirement sentence covering OAuth scopes appears twice in nearly identical form.

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 five-parameter, non-read-only prepare tool with an existing output schema, the description covers preconditions, permissions, rate limits, failure modes, and post-failure recovery, so nothing essential to correct invocation is missing. Only the closing clause about local commit versus unresolved follow-up stays obscure, which is a minor blemish against otherwise thorough coverage.

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 description coverage is 100%, so the schema already defines every parameter, and the description mostly restates those semantics in prose ('The received date is seller testimony', 'Freeze one listing version'). It adds a small amount of framing around the coupled version/quantity/date freeze, but no format, range, or edge-case detail beyond what the schema documents.

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 opening sentence names a specific verb and a full tuple of resources: freeze a listing version, units, received date, reason, and destinations, for native approval. The follow-up sentence clarifies the action is recording newly received units on one owned listing, and 'Review and approve its exact native plan before execution' plus 'Saves an expiring receipt plan' distinguishes it from the sibling execute_stock_receipt step.

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?

It gives a strong negative scope: 'Not a stock correction, acquisition-cost record, verified physical possession, checkout, label purchase or provider stock verification', and warns 'Existing stock-correction consent does not authorize receipt entry', steering agents away from adjustment flows. It also states the when-not condition for proceeding to execution and the recovery path after a lost response, but it never names the sibling tools (execute_stock_receipt, prepare_inventory_adjustment) by name, leaving the routing inference to the agent.

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

All SuperCatch 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?