SuperCatch

Execute an approved dated stock receipt

supercatch_execute_stock_receipt

DestructiveIdempotent

Execute one natively approved receipt once and recover its durable local and follow-up outcome with the original key. 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. Commits one approved receipt, native stock movement and quantity history, then dispatches only reviewed destinations. Queueing is not provider acceptance; a receipt is never replayed to retry uncertain follow-up. 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": {
      "plan_id": "owned-stock-receipt-plan-id",
      "idempotency_key": "stable-receipt-key"
    },
    "name": "supercatch_execute_stock_receipt"
  }
}

Input Schema

Name	Required	Description
`plan_id`	Yes	Persisted exact plan ID returned by the prepare tool; targets and amounts cannot be replaced during execution.
`approval_ref`	No	Optional trusted approval reference for this exact actor, plan and payload. A supplied value is verified; conversational confirmation is not an approval.
`idempotency_key`	Yes	Stable client-generated key for this exact intent. Reuse it after a lost response; a different intent must use a new key.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 8, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already flag destructive/openWorld/idempotent, and the description goes well beyond them: it discloses the commit payload ('native stock movement and quantity history'), that only reviewed destinations are dispatched, that 'Queueing is not provider acceptance', that a receipt 'is never replayed to retry uncertain follow-up', the auth scopes required, a rate limit ('One listing per nine-minute plan'), and an enumerated failure set (foreign targets, revoked consent, changed versions, holds, expired approval, conflicting keys). This is the full behavioral burden for a destructive mutation.

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 governing sentence is correctly front-loaded, but the remainder is a run of terse fragments that mixes intent, auth, failure modes and recovery without grouping. There is redundancy ('Requires OAuth store:inventory:receive consent. Requires fresh store:inventory:receive consent plus current EDIT_LISTINGS') and at least one opaque phrase ('One listing per nine-minute plan') that is not clarified anywhere.

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 destructive, idempotent, open-world mutation this covers everything an agent needs: the upstream prepare/approve dependency, auth scopes, side effects committed, non-retry semantics on uncertain follow-up, and the specific conditions that fail. An output schema exists, so the description is not obliged to explain return values, and it doesn't waste space doing so.

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 baseline is 3. The description reinforces intent binding for idempotency_key ('original key', 'conflicting keys fail', recovery from a lost response) and mentions that 'Private approval references and destination delivery identifiers are omitted', but both points are already carried by the schema's own parameter descriptions, so added meaning is marginal.

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 first sentence names a specific verb ('Execute'), a specific resource ('one natively approved receipt'), and the scope ('once ... with the original key'). It then fences the tool off from adjacent siblings with an explicit negative list ('Not a stock correction, acquisition-cost record, verified physical possession, checkout, label purchase or provider stock verification'), which separates it from supercatch_execute_inventory_adjustment and the prepare_* counterparts.

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?

The description states the prerequisite workflow ('Review and approve its exact native plan before execution'), the execution precondition ('Execute only with the original plan, stable key and native bound approval'), the recovery path ('After a lost response, recover the original operation before starting new receipt intent'), and an explicit exclusion ('Existing stock-correction consent does not authorize receipt entry'). When-to-use, when-not-to-use and the sibling alternative are all present.

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?