Skip to main content
Glama
Sign In

SuperCatch

by com.supercatch
OverviewDiscussionsAdmin

Save an exact draft update

supercatch_execute_listing_draft
DestructiveIdempotent

Save the exact prepared catalog link, draft seller notes and optional photo permutation or rotation to the same DRAFT once per durable intent. Reuse the original key after a lost response; replays only inspect receipts and never repeat uploads or native saves. Rotation requires verified output bytes, a consumed artifact receipt and the exact committed photo state before reporting success. Save front and back photos through SuperCatch's authenticated /store/listings/new flow, inspect that owned DRAFT and select an exact existing catalog card. Prepare and execute a single frozen update to that same draft. No arbitrary photo URLs, chat-attachment ingestion, new catalog rows, grading or authenticity verification, price, inventory or publication changes. A strict canonical plan or durable operation envelope with exact listing, catalog and version references. Private photo and card-data snapshots stay server-side. Requires OAuth store:listings:drafts:write consent. Requires separate store:listings:drafts:write consent and current EDIT_LISTINGS permission on an approved owned store. Optional photo order additionally requires store:listings:drafts:images:write; existing catalog/copy grants never acquire photo-write authority. Existing read and price grants do not authorize drafts. One draft per plan; nine-minute expiry; execute accepts only the plan and stable idempotency key. Preparation adds an expiring plan. Execution replaces the existing draft's catalog association and persisted card-data snapshot, with model edits limited to seller notes; an optional frozen photo permutation or explicit photo rotation also replaces draft display state. Photo changes require additional photo-write consent. Rotation retains its stable base and original archives and creates a complete verified artifact set with a durable receipt. Existing price is preserved, the listing remains DRAFT, and there are no marketplace writes. Missing or foreign drafts, unowned preserved originals, incomplete photo pairs, stale versions, changed catalogs and revoked authority fail. After a lost response, inspect the same operation or find it by its original key; unknown outcomes must not be retried as new intent.

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": "draft-plan-id",
      "idempotency_key": "draft-update-00000001"
    },
    "name": "supercatch_execute_listing_draft"
  }
}

Input Schema

NameRequiredDescriptionDefault
plan_idYesPersisted exact plan ID returned by the prepare tool; targets and amounts cannot be replaced during execution.
idempotency_keyYesStable client-generated key for this exact intent. Reuse it after a lost response; a different intent must use a new key.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4/5.0
Behavior5/5

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

Beyond the annotations (destructiveHint=true, idempotentHint=true), the description discloses material behavior: nine-minute plan expiry, required OAuth scope and EDIT_LISTINGS permission, the additional photo-write scope, exactly what gets replaced (catalog association, persisted card-data snapshot, draft display state), what is preserved (price, DRAFT status, originals/archives), and that there are no marketplace writes. It also enumerates concrete failure modes (foreign drafts, incomplete photo pairs, stale versions, changed catalogs, revoked authority), which is precisely the context annotations cannot carry.

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 instruction is front-loaded, but the text is bloated and self-repeating: the store:listings:drafts:write consent requirement is stated twice in consecutive sentences, photo-write scope is reiterated three times, and the 'no price/inventory/publication changes' constraint is restated later as 'existing price is preserved... no marketplace writes'. Several sentences are near-duplicates that could be merged without losing 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?

For a destructive, idempotent execution tool with only two inputs, the description covers authorization, idempotency/replay semantics, expiry, mutation scope, preserved state and failure modes, and an output schema already handles return values. An agent has everything needed to call it safely and to handle a lost response, despite the redundancy.

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 both parameters already document their constraints, including the reuse-the-key-after-lost-response rule. The description mostly restates those semantics ('execute accepts only the plan and stable idempotency key', 'one draft per plan') and adds no new format or validation detail, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence gives a specific verb and resource: save the prepared catalog link, seller notes and optional photo permutation/rotation to the same DRAFT. It is distinguishable from the family of prepare_* siblings via the 'prepare and execute a single frozen update' framing, but the goal is buried in dense qualification rather than stated cleanly up front.

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 states when to use it (execute a frozen plan produced by the prepare tool), the key-reuse rule after a lost response ('reuse the original key... replays only inspect receipts'), and a clear when-not list: no arbitrary photo URLs, chat attachments, new catalog rows, price/inventory/publication changes. It does not explicitly name a competing sibling such as supercatch_prepare_listing_draft or the submission/publication execute tools, so routing between them still requires inference from the sibling names.

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

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