Skip to main content
Glama

Prepare an exact eBay publication

supercatch_prepare_publication

Freeze one approved owned listing, its exact version and one eBay destination for native staging review. Preparation does not create a provider offer. Publish one exact eligible owned listing to one explicitly selected eBay export connection using native staging and fee approvals. No bulk search execution, other marketplaces, moderation bypass, repricing, stock correction, refund, shipping purchase or automatic category repair. A strict frozen publication plan or durable receipt. Provider acceptance, live readback and local export-link completion remain separate. Credentials, private payloads and approval secrets are never returned. Requires OAuth store:listings:publish store:listings:publish:fees consent. Preparation and execution require separate store:listings:publish and store:listings:publish:fees consent, current EDIT_LISTINGS and an approved owned store. Historical reads require publication consent. Exact fee approval never authorizes other financial actions. Persists an exact expiring plan. Provider staging and publication each require separate native web approval. Foreign, stale, unapproved or changed targets and destinations fail closed. After a timeout or lost response, inspect the original operation with its original key; never create a replacement intent to bypass uncertainty.

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",
      "integration_id": "owned-ebay-connection-id",
      "expected_version": "2026-11-06T12:00:00Z"
    },
    "name": "supercatch_prepare_publication"
  }
}

Input Schema

NameRequiredDescriptionDefault
listing_idYesExact owned ACTIVE listing ID, never a catalog ID, slug, search or bulk selection.
integration_idYesExact enabled eBay export connection owned by the selected store. Its account, environment and configuration are bound to the plan.
expected_versionYesExact current listing version; changed listings, reservations or destination settings require a new review.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.1/5.0
Behavior5/5

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

Beyond the annotations, the description discloses that preparation does not create a provider offer, that a strict expiring plan or durable receipt is persisted, that credentials and approval secrets are never returned, and that native web approval is required for staging and publication separately. It also gives timeout recovery guidance and fail-closed behavior for stale or changed targets.

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 core action is front-loaded, but the description is dense and contains redundancy around OAuth scopes and separate approval requirements. The 'Publish one exact eligible owned listing' sentence is also confusing in a preparation tool and weakens the otherwise clear structure.

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 complex, non-read-only preparation tool with an output schema and full parameter documentation, the description covers the essential safety, consent, approval, persistence, failure, and recovery behavior. An agent has enough context to call it correctly and knows that execution and readback are separate.

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 all three parameters are already well described in the schema. The description reinforces exact owned listing, version, and destination semantics but does not add substantial parameter-level meaning beyond the structured schema.

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 states a specific verb and resource: freezing one approved owned listing, its exact version, and one eBay destination for native staging review. The later sentence beginning 'Publish one exact eligible owned listing...' muddies whether this tool prepares or executes publication, even though 'Preparation does not create a provider offer' and the title clarify the intent.

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?

The description gives clear preconditions and exclusions: separate consent for preparation and execution, current EDIT_LISTINGS, an approved owned store, and no bulk search or other marketplaces. It does not explicitly name execute_publication as the next step or get_publication_plan as the inspection tool, but the operating context is otherwise clear.

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