Skip to main content
Glama
ODATANO

@odatano/nightgate-mcp

Official
by ODATANO
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

take_swap_offer

Take a shielded token swap offer by building the mirrored half and optionally submitting both halves to a sponsor; verify agreed terms to reject mismatches.

Instructions

A swap settles two shielded tokens between two wallets without a contract: each side builds one half (it spends the coin it gives and creates the coin it wants), the two mirrored halves merge into one transaction, and a sponsor pays the fee. This takes an offer: it reads the offer's terms from the transaction, refuses when they differ from expect, builds and proves the mirror half from this server's wallet (it spends what the offer wants and creates what the offer gives). With submit: true the two halves go to the sponsor at once and the tool waits until the swap landed ({ status, txHash, transactionHash, result.swap, id, terms }). Without it the answer carries both halves for sponsor_swap. ALWAYS pass expect with the terms you agreed to: an offer is text from someone else. With offerId the board entry is read first and the call refuses, before proving, when it is not open or carries another offer than offer. A sponsor that refuses the swap leaves the proven half held under halfId: send it again with sponsor_swap({ halfId, offerId? }) or release its coins with revert_swap_offer. If the offer was taken by somebody else first, the job fails: revert_swap_offer.

Input Schema

NameRequiredDescriptionDefault
offerYesThe offer to take: offer file text (swapoffer1...) or base64 of the serialized, proven transaction
expectNoThe terms you agreed to, from the MAKER's side: what the offer gives and what it wants
submitNotrue: hand both halves to the sponsor at once and answer with the job
offerIdNoThe board entry the offer came from (list_swap_offers), so the fill is recorded against it
takerSecretNoFor a directed offer (directed: true on the board): the secret its poster handed you; the sponsor refuses the swap without it
idempotencyKeyNoDedupes retries of the same submission

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.20.3
    • addedInput schema / properties / takerSecret
      Added value: +{
+  "description": "For a directed offer (directed: true on the board): the secret its poster handed you; the sponsor refuses the swap without it",
+  "maxLength": 256,
+  "minLength": 1,
+  "type": "string"
+}
  2. Addedv0.18.3

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description carries the whole burden and does well: it discloses that the sponsor pays the fee, that terms are validated against `expect` and refused before proving, that the offerId board entry is re-read and can refuse, that a refusing sponsor leaves the proven half held under `halfId`, and the returned fields ({ status, txHash, transactionHash, result.swap, id, terms }). It stops short of stating auth/wallet requirements or whether a settled swap is reversible, which is why it is not a 5.

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?

Dense and largely front-loaded, with the alternative paths and failure modes ordered sensibly. The opening protocol explanation (one half each, mirrored merge, sponsor pays) is background rather than this tool's action and delays the operative sentence slightly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 6-parameter, no-output-schema, no-annotation mutation tool it covers what the agent needs: the return shape is spelled out inline, both success and refusal paths are described, and the recovery tool is named. Missing only wallet/auth expectations and idempotency behavior, which the schema names but does not explain.

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 baseline is 3. The description still adds behavior the schema cannot: `expect` is mandatory in practice because 'an offer is text from someone else', `submit` changes the response shape entirely, and `offerId` triggers a pre-proof board re-read. That is meaningful meaning beyond the field 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?

It names a specific verb and resource ('takes an offer', 'builds and proves the mirror half from this server's wallet') and situates it against siblings: post_swap_offer/build_swap_offer produce offers, sponsor_swap consumes the produced halves. An agent can tell exactly which half of the swap lifecycle this tool performs 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?

Explicit when-to-use branches: with submit:true the halves go straight to the sponsor, without it the answer carries both halves 'for sponsor_swap'. It also gives preconditions (ALWAYS pass expect), the offerId board-check path, the held-half recovery path via sponsor_swap({ halfId, offerId? }) or revert_swap_offer, and the race case where revert_swap_offer is required.

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

Deploy Server

Other Tools