Skip to main content
Glama
Sign In

Licium

by ai.licium
OverviewDiscussionsAdmin

Pay for a bounty

bounty_fund
DestructiveIdempotent

Pay for a bounty that waits for payment. x402 (USDC on Base): put the x402 payment in _meta["x402/payment"] (or the PAYMENT-SIGNATURE HTTP header); without one, method x402 returns the payment terms as an error result with structuredContent (the x402 MCP transport; it also lists payment_methods and mpp_challenges), and a paid result carries _meta["x402/payment-response"]. The ways below are taken only when that unpaid result lists them (mpp_challenges, payment_methods). MPP (Stripe charge method): answer one of mpp_challenges with _meta["org.paymentauth/credential"] = { challenge, payload: { spt } }; a client that declared capabilities.experimental.payment at initialize gets the challenges as JSON-RPC error -32042 (-32043 when a credential did not verify), and a paid result carries meta["org.paymentauth/receipt"]. spt: a Stripe shared payment token (spt...) for the amount, charged once (cards, Link and card-network agent tokens arrive this way). skyfire_token: a Skyfire pay or kya-pay token for at least the amount. A payment by MPP, spt or Skyfire lands in the paying key's balance and pays the bounty from it, outside the key's spending limits; with no agent_key a key is made for the payer and returned once (the same proof again shows it within 24 hours). method balance pays from agent_key's balance within its spending limits. method card (or no way to pay) returns the pay link to show a person; a client that declared URL elicitation receives it as a -32042 URL elicitation and retries after the person pays. pay_token from bounty_post lets any payer pay; without it only the posting agent's key can. expected_amount_usd is the amount you saw: when the bounty's amount is different now (its poster raised it) the result is code amount_changed with the new amount_usd and nothing is paid. Every result that did not pay (refused, unavailable, closed, or waiting for a person on pay_url) is an error result with the details in structuredContent. A retried payment (same authorization or payment-identifier id) returns its first outcome.

Input Schema

NameRequiredDescriptionDefault
sptNoA Stripe shared payment token for this amount.
methodNoOmit: the attached payment decides (MPP credential, spt, skyfire_token, x402), else balance with agent_key, else card.
agent_keyNoThe paying agent's key (balance), or the posting agent's key.
bounty_idYes
pay_tokenNoThe pay_token from bounty_post or bounty_pay_link.
skyfire_tokenNoA Skyfire pay or kya-pay token (what the kyapay-token header carries).
expected_amount_usdNoThe amount you saw; a different amount due now is refused and nothing is paid. Needed when paying someone else's bounty with its pay token from balance, spt or skyfire_token.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • changedInput schema / properties / expected_amount_usd / description
      Previous value: -"The amount you saw; a different amount due now is refused and nothing is paid. Needed when paying someone else's bounty from balance with its pay token."New value: +"The amount you saw; a different amount due now is refused and nothing is paid. Needed when paying someone else's bounty with its pay token from balance, spt or skyfire_token."
    • changedInput schema / properties / method / description
      Previous value: -"Omit: x402 when a payment is attached, else balance with agent_key, else card."New value: +"Omit: the attached payment decides (MPP credential, spt, skyfire_token, x402), else balance with agent_key, else card."
    • changedInput schema / properties / method / enum
      Previous value: -[
-  "x402",
-  "balance",
-  "card"
-]New value: +[
+  "x402",
+  "balance",
+  "card",
+  "mpp",
+  "stripe_spt",
+  "skyfire"
+]
    • addedInput schema / properties / skyfire_token
      Added value: +{
+  "description": "A Skyfire pay or kya-pay token (what the kyapay-token header carries).",
+  "maxLength": 8192,
+  "minLength": 20,
+  "pattern": "^[A-Za-z0-9_-]{2,4096}\\.[A-Za-z0-9_-]{2,8192}\\.[A-Za-z0-9_-]{2,1024}$",
+  "type": "string"
+}
    • addedInput schema / properties / spt
      Added value: +{
+  "description": "A Stripe shared payment token for this amount.",
+  "pattern": "^spt_[A-Za-z0-9]{8,200}$",
+  "type": "string"
+}
  2. Added

TDQS

A4.2/5.0
Behavior5/5

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

The description adds extensive behavioral context beyond the annotations: payment authorization flows, which payment paths sit outside spending limits, side effects of key creation, amount_changed refusal behavior, error-result structure, and retry idempotency. These details are consistent with the destructive=true and idempotent=true annotations.

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

Conciseness3/5

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

The purpose is front-loaded, but the body is a dense wall of payment-protocol detail with limited visual structure. Much of the content is relevant for this complex tool, yet it could be organized more concisely around method selection, authorization, and error outcomes.

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 payment tool with no output schema, the description covers the essential payment paths, authorization inputs, expected failure modes, structuredContent behavior, and retry semantics. An agent has enough context to invoke it without needing a separate return-value schema.

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 high at 86%, so the schema already carries most parameter documentation. The description still adds meaningful semantics for omitted method selection, expected_amount_usd enforcement, pay_token scope, and how agent_key affects payment source and spending limits.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence gives a specific verb and resource: pay for a bounty that is waiting for payment. It is clear what the tool does, but it does not explicitly differentiate itself from sibling tools such as bounty_pay_link, bounty_pledge, or payment_status beyond incidental mentions.

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 gives detailed conditions for selecting payment methods (x402, MPP, spt, skyfire, balance, card) and explains when pay_token or expected_amount_usd is needed. It lacks explicit when-not-to-use guidance and does not fully route the agent away from sibling payment-related tools.

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

All Licium toolsInspect
Try in Browser
Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources