Skip to main content
Glama

swap_execute

Accepts a winning sealed bid for a swap and creates the trade. Provide limit_price or quote_id to confirm; returns trade_id for on-chain settlement via HTLC.

Instructions

Accept the winning sealed bid for a swap and create the trade. Real funds. Provide EITHER limit_price (auto-takes the best bid only if it meets your bound) OR quote_id (the exact bid you saw via swap_status). With neither, this refuses (CONFIRMATION_REQUIRED) rather than guess — restate the price to the user first.

USE WHEN: a swap has an acceptable bid and the user confirmed. DO NOT USE WHEN: you have not surfaced the price to the user, or you want maker-side quoting (use respond_rfq).

PARAM NOTES: limit_price is the sealed reservation (SELL=floor, BUY=ceiling) and must be re-supplied here — it is deliberately never stored. WARNING: accepted_amount may EXCEED your requested amount if a maker quoted a larger size (full-fill v1 accepts a bid whose amount covers the request) — always reconcile accepted_amount against what you asked before settling on-chain. On success returns trade_id; settle on-chain next via create_htlc. This does NOT lock funds itself (non-custodial).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
swap_handleYesThe swap_handle (RFQ id) from swap_quote.
limit_priceNoSealed reservation. SELL=floor, BUY=ceiling. Re-supply it here; never persisted.
quote_idNoExact bid id from swap_status best_bid.quote_id (explicit-confirm path).
client_request_idNoIdempotency key. Same id within this session returns the first result instead of accepting twice. Best-effort.
Behavior5/5

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

With no annotations, the description fully discloses behavioral traits: real funds, non-custodial (doesn't lock funds), acceptance behavior with missing parameters (CONFIRMATION_REQUIRED), warning about accepted_amount exceeding requested amount, and fact that limit_price is re-supplied and not stored.

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?

Description is well-structured with sections (description, use when, param notes, warnings) and front-loaded with the core action. Though slightly long, each sentence adds necessary value for a real-funds tool.

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?

Despite no output schema, the description covers return value (trade_id) and next step (create_htlc). It also addresses edge cases (missing parameters, size exceeding request) and constraints (non-custodial). Fully sufficient for an agent to use correctly.

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

Parameters5/5

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

Schema has 100% coverage with descriptions. The description adds significant meaning: limit_price is sealed reservation and must be re-supplied, quote_id is exact bid from swap_status, client_request_id is idempotency key. This goes beyond the schema's basic descriptions.

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?

Clearly states it accepts the winning sealed bid and creates a trade, differentiating from sibling tools like respond_rfq. The verb 'accept' and resource 'swap' are specific, and the description distinguishes from maker-side quoting.

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?

Explicitly provides USE WHEN (swap has acceptable bid and user confirmed) and DO NOT USE WHEN (price not surfaced or want maker-side quoting), with alternative tool named (respond_rfq). This gives clear decision criteria.

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

Install Server

Other Tools

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/Hashlock-Tech/hashlock-mcp'

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