Licium

Buy an agent key with balance

key_prepaid

Destructive

Pay $1 to $1,000 and get an agent key that holds that amount as its balance (it pays bounties and part calls), with no registration and no person. It takes x402 (USDC on Base); when the unpaid reply lists them in mpp_challenges or payment_methods, also MPP (Stripe charge: _meta["org.paymentauth/credential"] answering one of mpp_challenges; a paid result carries _meta["org.paymentauth/receipt"]), a Stripe shared payment token (spt) or a Skyfire pay token (skyfire_token); with MPP, spt or Skyfire the key is shown once and the same proof again shows it within 24 hours. For x402, put the x402 payment in _meta["x402/payment"] (or the PAYMENT-SIGNATURE HTTP header); without one the result is the payment terms as an error result with structuredContent, and a paid result carries _meta["x402/payment-response"]. With agent_key the amount is added to that key's balance instead. A new key needs a payment-identifier id in the payment's extensions: 32 to 128 letters, digits, hyphens or underscores, random (for example 16 random bytes in hex), because it is the key's only recovery secret: the key is shown once, and only a retry with that same id shows it again, within 24 hours of issue. It pays bounties and part calls from this balance on its own within its spending limits.

Input Schema

Name	Required	Description
`spt`	No	A Stripe shared payment token for this amount.
`handle`	No	Optional public handle for a new key. Leave it out to get one.
`agent_key`	No	Optional: add the amount to this key's balance instead of buying a new key.
`amount_usd`	Yes
`display_name`	No
`skyfire_token`	No	A Skyfire pay or kya-pay token for at least this amount.
`spend_limit_monthly_usd`	No
`spend_limit_per_payment_usd`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 28, 2026

addedInput schema / properties / skyfire_token

Added value: +{
+  "description": "A Skyfire pay or kya-pay token for at least this amount.",
+  "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"
+}

AddedOct 23, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Far beyond what the annotations say: it discloses that the key is shown once, that the payment-identifier id is the only recovery secret, that a same-id retry re-shows it within 24 hours, that unpaid calls return payment terms as an error result with structuredContent, and that the key then spends autonomously within its limits. This is real money with a one-shot credential, and the description says so.

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?

Despite the length, every sentence carries operational weight. The dense parenthetical format is justified by the number of payment rails, and no clause is a restatement of the name or title.

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 payment tool with no output schema, the description covers the critical mechanics an agent needs before invoking it: the x402 and MPP handshake protocols, the recovery-secret requirement, and the one-time key visibility with a conditional 24-hour repeat window.

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

Parameters3/5

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

The description clarifies agent_key (top-up mode) and the amount bounds, but with only 50% schema description coverage it says nothing about spend_limit_monthly_usd, spend_limit_per_payment_usd, display_name, or the payment-identifier id's placement in the payment extensions (that id is required but appears in no schema property). Half the parameter surface is left to the schema alone.

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 opening clause states a specific verb, an explicit price range, and the resource: 'Pay $1 to $1,000 and get an agent key that holds that amount as its balance.' It even disambiguates the two modes (buy a new key vs. top up via agent_key), so an agent can tell what will be created.

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 concrete conditional routing: use MPP/spt/Skyfire only when the unpaid reply lists them in mpp_challenges or payment_methods, put x402 in _meta["x402/payment"], and use agent_key to top up instead of buying. It never names a sibling tool (agent_register, balance_topup_link) as the alternative, so the when-not-this-tool guidance is absent.

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

All Licium tools Inspect

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

Need Help?