SuperCatch

Submit frozen drafts for internal review

supercatch_execute_listing_submission

Idempotent

Submit up to five still-queued frozen drafts to PENDING through the native owner. Reuse the same plan and original idempotency key to continue remaining items or recover lost responses. No marketplace publication occurs. Submit an explicit frozen set of existing owned DRAFT listings that already pass SuperCatch's native readiness checks to its internal moderation queue. Does not approve or activate listings, publish to marketplaces, bypass moderation, repair blockers, change prices or stock, or select by a live search filter. A strict listing.draft.submit plan or durable per-item operation receipt. Public pages contain at most five items with whole-selection totals and a bound continuation cursor; private policy fingerprints stay on the server. Requires OAuth store:listings:drafts:submit consent. Requires separate store:listings:drafts:submit consent, an approved owned store and current EDIT_LISTINGS permission. Draft-edit, price and inventory consent do not imply submission authority. Frozen membership is limited to 100 targets; plans expire after nine minutes. Native activity provides inspection and continuation without bypassing the original grant. Preparation persists an expiring frozen manifest. Execution attempts up to five queued items through the native bulk-submit owner. Each DRAFT-to-PENDING commit and item receipt share one transaction; marketplace publication is not requested. Missing drafts, stale versions or readiness changes fail without substituting other targets. After a lost response, recover the original key or operation. A repeated execution continues only queued items; completed items are never submitted again. Unknown outcomes require reconciliation before 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": "submission-plan-id",
      "idempotency_key": "draft-submission-00000001"
    },
    "name": "supercatch_execute_listing_submission"
  }
}

Input Schema

Name	Required	Description	Default
`plan_id`	Yes	Persisted exact plan ID returned by the prepare tool; targets and amounts cannot be replaced during execution.
`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 5, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Beyond the annotations (which already mark this as a non-destructive, idempotent, closed-world write), the description discloses authorization (store:listings:drafts:submit plus EDIT_LISTINGS, and that draft-edit/price/inventory consent does not confer submission authority), limits (100 targets, nine-minute plan expiry, up to five items per execution), and transactional semantics (each DRAFT-to-PENDING commit shares one transaction with its item receipt). Failure modes are spelled out: missing drafts, stale versions or readiness changes fail without substituting targets, and unknown outcomes require reconciliation before new intent.

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 first sentence is well front-loaded, but the body wanders and repeats itself: 'No marketplace publication occurs' is restated later as 'marketplace publication is not requested,' and the consent requirement is stated twice in consecutive sentences, the second oddly calling it 'separate.' For a two-parameter tool this runs roughly 200 words with several restatements of the frozen/idempotent contract that do not add new 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 mutation tool with an output schema already present, the description covers everything needed: authorization prerequisites, plan expiry and target caps, per-item transactionality, the continuation-cursor envelope, and explicit failure and reconciliation paths. Nothing material for correct invocation or safe recovery is missing.

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 parameter descriptions already explain both the persisted plan ID and the stable idempotency key reuse rule, so the schema does the heavy lifting. The description adds continuation semantics (reuse the key to continue remaining queued items) and confirms targets and amounts cannot be substituted, but much of this restates the schema. Baseline 3 is appropriate.

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 resource: submit up to five still-queued frozen drafts to PENDING through the native owner, with no marketplace publication. It is clearly distinguishable from the prepare step and from preview_marketplace_publish in the sibling list, so an agent can select it without opening the schema.

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 clear when-to-use context (a persisted frozen manifest already exists, readiness checks already pass) and explicit when-not exclusions: does not approve, activate, publish, bypass moderation, repair blockers, change prices or stock, or select by a live search filter. It also prescribes recovery behavior after a lost response. It never names the sibling prepare tool directly in the description text, so the routing to the prior step is only implied.

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?