Skip to main content
Glama
Sign In
com.macaroonnetwork/mcp-server

com.macaroonnetwork/mcp-server

by kevmoz
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

macaroons_execute

Pay for and execute a paid marketplace capability by ID via Lightning L402. It returns a payable invoice when no wallet is configured, and refunds on failed acceptance checks or bridge errors.

Instructions

Execute a paid marketplace capability by capability_id. Pays via Lightning L402 against a hold invoice — payment only settles if the acceptance predicate passes against the bridge response; bridge errors and predicate failures refund. If no wallet is configured (the default), returns payment_required with a real invoice for you to pay yourself.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "capability_id": "<capability_id>",
      "input": "<input>"
    },
    "name": "macaroons_execute"
  }
}

Input Schema

NameRequiredDescriptionDefault
inputYesCapability input payload matching the listing input_schema.
predicateNoOptional acceptance predicate. Defaults to the listing's sample_predicate when omitted.
capability_idYesRegistry capability_id, e.g. 'polymathica-heated-channel-v1'.
max_spend_satsNoHard per-call spend cap in satoshis.
resume_macaroonNoOnly set this after a prior call returned payment_required and you've since paid that invoice with your own wallet — set it to the macaroon that call returned. Omit on a first attempt.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.6/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 it delivers: it explains the hold-invoice settlement condition, refund on bridge errors or predicate failures, and the no-wallet default that returns payment_required with a real invoice. This is unusually concrete about payment behavior and error paths.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three dense sentences with the main action first, followed by payment mechanics and the default no-wallet behavior. Every sentence adds information and none repeats schema content.

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?

The complex payment flow, refund behavior, and no-wallet fallback are well covered. However, since there is no output schema, the description could be more explicit about the success return shape and how refund/error responses are surfaced; it only details the payment_required return path.

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%, but the description adds workflow-level meaning around predicate (settlement condition) and resume_macaroon (usable only after a prior payment_required) beyond the parameter descriptions. It still leaves max_spend_sats to the schema, which is acceptable because the schema already documents it.

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 names a specific verb ('Execute') and resource ('paid marketplace capability by capability_id'), and the payment mechanism makes it distinct from sibling search/metadata/purchase tools. It is immediately clear what operation the tool performs.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description makes the tool's role clear—executing a paid capability and paying via L402—but does not explicitly state when to prefer it over macaroons_purchase or search. Context implies it, but no direct exclusions or alternatives are named.

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