Skip to main content
Glama

cpu_accept_cell_offer

Sell one Cell you own by accepting one exact NFT marketplace offer. Pass the offer's orderHash (and tokenId for trait/collection offers); the sale is executed and verified in one call.

Instructions

Sell ONE Cell you own by accepting ONE exact offer on the NFT marketplace, in a single call. This is the land market — Cells traded as NFTs for a configured currency — and it is entirely separate from cpu_create_lot, which sells RESOURCES for $CPU inside the game. YOU PICK THE OFFER AND THE CELL. Read cpu_get_my_offers_received first and pass that offer's exact orderHash. An offer for one exact Cell already names the Cell; a trait or collection offer bids for a SET of Cells, so you must also pass the tokenId you are willing to sell — the call fails before sending anything when a criteria offer is not given one. If the pinned offer has been filled, cancelled, expired, or cannot be fulfilled as it stands, the call fails with staleOffer or unfulfillable and sells NOTHING — it never substitutes a different offer or a different Cell for you. The call performs the whole action itself: it prepares the acceptance, checks that the prepared work is still that exact offer and that exact Cell of yours, sends any collection approval the wallet still owes and waits for its receipt, then sends the one fulfilment transaction. There is nothing to confirm afterwards. Success is proven, not assumed: the receipt must carry the protocol's own fulfilment event for that exact order, the transaction must have been sent by your wallet, and the Cell must no longer be owned by you. A trait or collection offer may stay ACTIVE afterwards — it can still buy other Cells — and that is not a failure and never a second sale of the same Cell. Retrying is safe for your Cells: once ownership has moved, a repeat refuses before sending anything, and a repeat of a transaction already broadcast re-checks that transaction instead of selling again. At worst a retry spends gas on a transaction the protocol rejects. The result reports status (completed, or already_completed when the sale proved to be done already), the orderHash accepted, the Cell sold, the buyer, the offer amount and currency before the marketplace's mandatory fee split, and every transaction hash in txHashes in the order it was broadcast.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tokenIdNoThe one Cell of yours to sell, as a decimal token id with no leading zeroes (e.g. "0" or "1234", never "01234"). REQUIRED for a trait or collection offer, because such an offer names a set of Cells and never picks one for you. For an item offer you may omit it (or pass null) and the Cell the offer bids for is used; if you do pass it, it must be that same Cell.
orderHashYesThe exact 32-byte 0x-prefixed `orderHash` of the offer you decided to accept, copied from `cpu_get_my_offers_received` or `cpu_get_cell_market`. This tool accepts that offer or nothing: it never falls back to a higher, newer or otherwise different offer.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
buyerYes
offerYes
stageYes
amountYes
statusYes
walletYes
tokenIdYes
currencyYes
txHashesYes
eventTypeYes
orderHashYes
approvalTxHashesYes
fulfilmentTxHashYes

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 zero annotations, the description carries the full behavioral burden, and it delivers: atomic multi-step execution (prepares, re-checks exact offer/Cell, sends owed collection approval, waits for receipt), failure modes (staleOffer/unfulfillable sell NOTHING), proven-success criteria (protocol fulfilment event, sender wallet, ownership transfer), post-sale active criteria offers, and detailed retry semantics. This exceeds what any annotation set would typically provide.

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 front-loaded with the core purpose and logically organized (purpose → market distinction → usage → execution → failure → retry → result). It is long, but for a high-stakes mutation tool with no annotations the detail is mostly earned. Some redundancy, such as the no-substitution guarantee and retry safety being restated, keeps it from a perfect score.

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 marketplace mutation with zero annotations, the description is remarkably complete: prerequisites, parameter requirements per offer type, failure modes, approval handling, retry safety, and result semantics (status, orderHash, Cell, buyer, pre-fee amount/currency, txHashes in order) are all covered. The existence of an output schema is a bonus since return values are already explained in prose.

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. The description adds real value on top: it explains why tokenId is REQUIRED for criteria offers and the exact consequence of omitting it (call fails before sending anything), ties orderHash to its sourcing tool, and clarifies the no-substitution guarantee. This pushes it above baseline.

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 precise verb+resource statement: "Sell ONE Cell you own by accepting ONE exact offer on the NFT marketplace, in a single call." It explicitly distinguishes itself from cpu_create_lot (sells RESOURCES, not Cells) and from sibling offer-making/buying tools, so an agent can tell it apart without inspecting schemas.

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 gives explicit when-to-use guidance: read cpu_get_my_offers_received first, copy the exact orderHash, and pass tokenId only for trait/collection offers. It also names the alternative (cpu_create_lot) and the condition that selects it, plus failure conditions that terminate the call safely.

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