Skip to main content
Glama
Sign In

SuperCatch

by com.supercatch
OverviewDiscussionsAdmin

Check native draft submission readiness

supercatch_get_listing_draft_readiness
Read-onlyIdempotent

Run the native submission precheck for one exact owned DRAFT and current version. Report blockers and missing fields without changing the listing or authorizing publication. Check whether an actor-owned DRAFT from SuperCatch's native photo workflow passes the current submission precheck. Drafts with zero or one saved photo can be assessed. Use the exact listing ID and version from the seller's draft surface. This does not authorize publication or change the draft. It does not grade cards, verify authenticity, inspect image storage by HEAD request, call paid services or submit the listing. Returns a bounded native blocker assessment, missing fields and a link to the existing DRAFT. Image content is not verified and publication is never authorized. Requires OAuth store:listings:drafts:write consent. Requires separate store:listings:drafts:write consent, current EDIT_LISTINGS permission and a DRAFT owned by this actor through SuperCatch's native photo workflow. Existing read and price grants do not authorize draft access. Read-only native submission precheck; no listing mutation, image-storage HEAD request, paid service call or publication request. Missing or foreign drafts, a changed version or unavailable native readiness checks return an error. The tool never changes the draft to clear a blocker.

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": {
      "source_draft_id": "owned-draft-id",
      "expected_version": "2026-11-04T16:00:00Z"
    },
    "name": "supercatch_get_listing_draft_readiness"
  }
}

Input Schema

NameRequiredDescriptionDefault
source_draft_idYesExact owned listing ID for the existing DRAFT listing.
expected_versionYesExact current updated_at version of the DRAFT; changed listings are refused.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.8/5.0
Behavior5/5

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

Beyond the annotations it discloses auth requirements ('Requires separate store:listings:drafts:write consent, current EDIT_LISTINGS permission'), notes that unrelated read/price grants do not suffice, and enumerates failure modes ('Missing or foreign drafts, a changed version or unavailable native readiness checks return an error'). It also rules out side effects and third-party calls, which is exactly the non-obvious behavioral context the read-only annotations do not convey.

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 purpose is front-loaded, but the text is heavily redundant: the no-mutation/no-publication guarantee appears at least four times ('without changing the listing or authorizing publication', 'does not authorize publication or change the draft', 'publication is never authorized', 'never changes the draft to clear a blocker'), and the OAuth scope requirement is stated twice in near-identical sentences. The image-storage HEAD-request exclusion is also repeated, so several sentences do not earn their place.

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 two-parameter read-only precheck with an output schema, the description covers what an agent needs: authorization scope, ownership requirement, version-mismatch behavior, error conditions, and a pointer to what is returned. The output schema carries the return shape, so nothing essential 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 description coverage is 100%, so both parameters are already documented in the schema, including maxLength and the date-time pattern. The description adds only the sourcing hint ('from the seller's draft surface') and reinforces that a changed version is refused, which is largely a restatement of the expected_version field description.

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 names a specific verb and resource ('Run the native submission precheck for one exact owned DRAFT and current version') and immediately states the output ('Report blockers and missing fields'). It fences itself off from adjacent capabilities ('does not grade cards, verify authenticity, inspect image storage... or submit the listing'), but it never names the sibling tool it should be preferred over (e.g. supercatch_get_listing_submission_plan), so an agent must infer differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives real preconditions for use ('Use the exact listing ID and version from the seller's draft surface', 'Drafts with zero or one saved photo can be assessed'), which implies the pre-submission context. However, there is no explicit when-to-use-this-vs-alternatives routing, and no statement of when an agent should skip this check entirely; usage must be reconstructed from the surrounding 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