SMKlog Parcel Shipping Rates

Cancel a checkout session

cancel_checkout_link

DestructiveIdempotent

Cancels a create_checkout_link session the human has not opened yet: its handoff link stops binding a checkout, and get_checkout_status answers session_cancelled from then on. Nothing has been paid at that stage, so nothing is refunded and no human is needed. Once the human opens checkout the call is refused with session_in_checkout and the checkout stands: an unpaid one expires on its own, a paid one is refunded by SMKlog support and get_refund_status follows it. Idempotent: cancelling a cancelled session answers the same. No carrier call, no quote allowance.

Parameter rules:

session_id is the as_ plus UUID id from create_checkout_link.
An unknown, malformed or expired id answers session_not_found.
From checkout_started on: session_in_checkout, and nothing changes.
To try again, call create_checkout_link for a new session.
60 calls an hour per client, shared with get_checkout_status.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "session_id": "<session_id>"
    },
    "name": "cancel_checkout_link"
  }
}

Input Schema

Name	Required	Description	Default
`session_id`	Yes	The session_id from create_checkout_link.

Output Schema

Name	Required	Description
`next`	No	What, if anything, the agent should do now
`amount`	No	The amount the session was anchored to, USD
`status`	Yes
`service`	No	The service the session was anchored to
`checkout`	No	Always null: no checkout was opened
`currency`	No	ISO currency, USD
`created_at`	No	When create_checkout_link made the session, ISO 8601
`expires_at`	No	When the session would have stopped answering, ISO 8601
`session_id`	Yes	The session cancelled
`cancelled_at`	Yes	When it was cancelled, ISO 8601
`quote_reused`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 7, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Well beyond the annotations, it discloses the full state machine: the handoff link stops binding, get_checkout_status then answers session_cancelled, unpaid sessions simply expire while paid ones are refunded via SMKlog support tracked by get_refund_status. It also discloses the idempotency semantics and a concrete rate limit (60 calls an hour per client, shared with get_checkout_status). The destructiveHint=true annotation is not contradicted — the description explains that destruction is limited to the link binding, with no funds moved.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core behavior is front-loaded in the first two sentences and the parameter rules are cleanly separated into a bulleted block, so structure is strong. It runs long for a single-parameter tool, and the payment/refund clause pair takes a moment to resolve as describing two different states rather than one contradiction.

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?

An output schema exists, so return values need not be explained, and the annotations cover the safety profile. What remains — preconditions, refusal codes, retry procedure, refund follow-up, and throughput limits — is all present, leaving nothing an agent needs missing.

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: the id is "the as_ plus UUID id from create_checkout_link" and the error taxonomy for unknown, malformed, or expired ids is session_not_found. It stops short of explaining the pattern's 8-80 character length, but the error behavior is the more useful addition.

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 description opens with a specific verb and resource ("Cancels a create_checkout_link session the human has not opened yet") and immediately distinguishes the scope from its siblings by naming create_checkout_link and get_checkout_status. An agent can tell exactly what this does 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 Guidelines5/5

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

It states the precise precondition for success (session not yet opened), the refusal condition with the exact error code (session_in_checkout once checkout_started), and the explicit recovery path ("call create_checkout_link for a new session"). It also names the downstream diagnostic tool get_checkout_status as the observer of session_cancelled.

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

All SMKlog Parcel Shipping Rates 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.