Skip to main content
Glama

cpu_cancel_order

Cancel one exact NFT market order—a Cell listing or offer—by passing its orderHash. The call verifies the transaction against the protocol contract and returns proof of cancellation, or indicates it was already completed.

Instructions

Cancel ONE exact Market order you made on the NFT marketplace, in a single call. One action covers both sides: a Cell listing you published with cpu_list_cell and a Cell offer you published with cpu_make_cell_offer are cancelled by the same input, because the side is a fact of the order rather than something you select. This is the land market — Cells traded as NFTs — and a Market order is not a resource Lot: ending one of those is cpu_return_lot, and this call never touches it. YOU PICK THE ORDER. Read cpu_get_my_listings or cpu_get_my_offers first and pass that order's exact orderHash. Only the wallet that made the order can cancel it: another wallet's order fails before anything is broadcast. The call performs the whole action itself: it prepares the cancellation, checks that the prepared transaction goes to the pinned marketplace protocol contract on this chain and that its bytes cancel exactly the order you named, then sends that one transaction and waits for its receipt. Success is proven, not assumed: the receipt must carry the protocol's own cancellation event for that exact order, naming your wallet as the maker, and the transaction must have been sent by your wallet. An order that merely stopped being active is NEVER reported as cancelled — it may have been filled or expired instead, so an order that is gone without that proof fails with staleListing or staleOffer and no other order is touched. Retrying is safe: a repeated call re-checks the transaction it already sent instead of cancelling again, and can never bind another order. At worst a retry spends gas on a transaction the protocol rejects. The result reports status (completed, or already_completed when the cancellation proved to be done already), the orderHash cancelled, whether it was a listing or an offer, and the cancellationTxHash.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
orderHashYesThe exact 32-byte 0x-prefixed `orderHash` of YOUR OWN Market order, copied from `cpu_get_my_listings` or `cpu_get_my_offers`. The same input cancels a listing and an offer alike — the side is a fact of the order, not something you choose here.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
stageYes
statusYes
walletYes
tokenIdYes
txHashesYes
eventTypeYes
orderHashYes
orderKindYes
cancellationTxHashYes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Addedv0.13.0

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden, and it discloses a great deal: single transaction, contract-pin check, byte-level cancellation verification, receipt and event-based proof, stale-order failures, safe retry semantics, and worst-case gas cost. This is exceptional transparency for a state-changing tool, especially around idempotency and failure modes.

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 description is long but appropriately front-loaded with the core purpose, and nearly every sentence contributes operational or safety-critical information. A few rhetorical rewordings, such as 'Success is proven, not assumed' and 'YOU PICK THE ORDER,' add emphasis rather than new facts, and some result details overlap with the output schema. Still, the density is justified for a destructive-looking action with retry and proof semantics.

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 high-stakes cancellation tool with one parameter and no annotations, the description is remarkably complete: prerequisites, ownership restriction, transaction flow, proof criteria, stale-order behavior, retry safety, and result fields are all covered. An agent has enough context to know whether it should call this tool and what to expect before, during, and after invocation.

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%, and the schema already describes orderHash as the exact 32-byte 0x-prefixed hash of your own Market order. The description adds context beyond the schema by instructing where to source the hash (cpu_get_my_listings or cpu_get_my_offers), emphasizing it must be YOUR OWN order, and clarifying the side is inherent to the order rather than a selectable parameter. This is meaningful added guidance, though partly reinforcing the schema.

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, resource, and scope: cancel exactly one Market order on the NFT marketplace in a single call. It clearly distinguishes this from cpu_return_lot, which ends a resource Lot, and explains the same input cancels both listings and offers. An agent can confidently identify what this tool does and how it differs from its siblings.

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?

The description explicitly tells the agent to read cpu_get_my_listings or cpu_get_my_offers first and pass the exact orderHash, names cpu_return_lot as the alternative for a different resource type, and states the wallet-ownership requirement. It also gives clear failure expectations, such as staleListing/staleOffer, so an agent knows when the call is appropriate and what happens otherwise.

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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/projectcpu/project-cpu-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server