Skip to main content
Glama
Sign In

SuperCatch

by com.supercatch
OverviewDiscussionsAdmin

Execute an approved tracking correction

supercatch_execute_order_tracking
DestructiveIdempotent

Apply one exact tracking correction approved in SuperCatch and recover its original receipt. Correct a shipped website order's tracking number or carrier. Review the exact old and new values, buyer notification and no-send policy in SuperCatch before execution. No first shipment, marketplace order, label purchase, payment, refund, stock change, arbitrary message, bulk selection, or order with active order.updated webhook delivery targets. A strict plan or durable local receipt with independent buyer-notification status. Email acceptance does not prove delivery; tracking verification does not prove delivery. Private recipient and message content remain in the native review UI. Requires OAuth store:orders:tracking:write consent. Requires separate store:orders:tracking:write consent, current MANAGE_ORDERS permission and an approved owned store. Price, stock and import grants do not authorize this action. Native bound review cannot be replaced by conversational approval. Atomically corrects the native tracking identity and records the same-key operation, then attempts only its frozen reviewed buyer notification when native notification policy allows it. Existing delivery polling may later apply normal delivery and settlement rules; the correction does not initiate a payment or refund. Foreign, stale, unchanged, unapproved or expired plans and revoked grants fail closed. Unsupported marketplace/webhook targets are refused. Recover the original plan and key after uncertainty; do not resend or create a replacement 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": "tracking-plan-id",
      "idempotency_key": "tracking-correction-intent-0001"
    },
    "name": "supercatch_execute_order_tracking"
  }
}

Input Schema

NameRequiredDescriptionDefault
plan_idYesPersisted exact plan ID returned by the prepare tool; targets and amounts cannot be replaced during execution.
approval_refNoOptional trusted approval reference for this exact actor, plan and payload. A supplied value is verified; conversational confirmation is not an approval.
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.7/5.0
Behavior5/5

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

Far beyond what annotations declare, it discloses authentication and authorization requirements (store:orders:tracking:write consent, current MANAGE_ORDERS permission, approved owned store, price/stock/import grants insufficient), failure modes (foreign, stale, unchanged, unapproved, expired plans and revoked grants fail closed), and the atomicity plus frozen-notification semantics of the write. It also warns about misleading success signals: email acceptance and tracking verification do not prove delivery, and the correction initiates no payment or refund.

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 critical constraints are front-loaded, but the body is an unusually dense wall of sentences and contains a duplicated, almost self-contradictory pair: 'Requires OAuth store:orders:tracking:write consent. Requires separate store:orders:tracking:write consent...' That redundancy costs clarity on the most safety-critical requirement.

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?

The tool is a destructive, idempotent, open-world mutation, and the description covers prerequisites, exclusions, failure behavior, notification policy, and credit/idempotency recovery. An output schema exists, so return-value detail is correctly omitted.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: it clarifies that the plan is exact and cannot be replaced at execution time, and it reinforces idempotency-key discipline (reuse after uncertainty, use a new key for a different intent). It also supports the approval_ref semantics by stating conversational approval is not an approval, though it never names approval_ref explicitly.

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 states a specific verb ('Apply one exact tracking correction') plus the resource (a shipped website order's tracking number or carrier) and the precondition (approved in SuperCatch, with a frozen plan). It is immediately distinguishable from the adjacent prepare tool, which produces the plan this tool executes.

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?

It gives explicit when-to-use conditions (an approved plan exists, review old/new values, buyer notification and no-send policy first) and explicit when-not-to conditions (no first shipment, marketplace order, label purchase, payment, refund, stock change, bulk selection, orders with active order.updated webhook targets). It also prescribes recovery behavior after uncertainty: reuse the original plan and key, do not resend or create a replacement intent.

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