Skip to main content
Glama
ODATANO

@odatano/nightgate-mcp

Official
by ODATANO
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

post_swap_offer

Publish a signed maker offer half to the server offer board so takers can discover it through listing, with terms validated and optional directed access via a one-time taker secret.

Instructions

Post a maker half on the server's offer board, so takers find it with list_swap_offers instead of receiving the offer file out of band. The server checks it like a half it would sponsor (one token type given, one wanted, both on its list, never NIGHT) and records its terms; the half itself stays signed by the maker. The offer closes when a swap that spends one of its inputs lands, on expiry, or by retire_swap_offer. Needs postSwapOffer in an agent grant's allowedActions. Returns { offerId, status, terms }. With directed: true only a taker who knows the returned takerSecret can have the swap sponsored: hand that secret to your counterparty, it is shown once (needs NIGHTGATE 0.39.0).

Input Schema

NameRequiredDescriptionDefault
tagsNoUp to 8 tags for list_swap_offers
offerYesThe maker half, as offer file text or base64: offer file text (swapoffer1...) or base64 of the serialized, proven transaction
directedNotrue: the offer can only be taken with the takerSecret this call returns; for an invoice or an agreed OTC deal
expiresAtNoISO timestamp; at most 90 days ahead

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.20.3
    • addedInput schema / properties / directed
      Added value: +{
+  "description": "true: the offer can only be taken with the takerSecret this call returns; for an invoice or an agreed OTC deal",
+  "type": "boolean"
+}
  2. Addedv0.18.3

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: it discloses validation rules (one token given, one wanted, both on the server's list, never NIGHT), closure conditions (spending an input, expiry, retire_swap_offer), the auth requirement (postSwapOffer in allowedActions), the return shape, and that takerSecret is shown once. This is unusually rich behavioral context.

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 but front-loaded: the primary action and board-visibility rationale lead, followed by validation, lifecycle, auth, and return value. The directed clause is a long trailing sentence, but each sentence carries distinct information and nothing is padding.

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?

No output schema exists, yet the description states the return object ({ offerId, status, terms }). Auth, validation, closure, and version prerequisites are all present, so an agent has everything needed to invoke it correctly.

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, and the description adds real meaning beyond the schema for 'directed' (secret gate, hand to counterparty, shown once, NIGHTGATE 0.39.0 requirement) and confirms where tags surface (list_swap_offers). It does not add syntax detail for offer or expiresAt, but the schema covers those well.

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?

States a specific verb+resource ('Post a maker half on the server's offer board') and immediately distinguishes it from out-of-band delivery and from list_swap_offers. An agent can tell it apart from build_swap_offer, take_swap_offer, and retire_swap_offer without opening a 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?

Explicitly frames the when ('so takers find it with list_swap_offers instead of receiving the offer file out of band') and names the lifecycle alternative (retire_swap_offer closes it). The directed parameter is scoped to invoice/agreed OTC use, giving concrete selection criteria.

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