LiveAuth MCP Server provides authentication, metering, and monetization for AI agents and MCP tools using proof-of-work, Lightning payments, or L402 bundles.
Start sessions with liveauth_mcp_start (PoW, Lightning, or L402)
Confirm authentication with liveauth_mcp_confirm (solve PoW, check Lightning payment, or present macaroon) to get a JWT
Check session/payment status with liveauth_mcp_status
Retrieve Lightning invoice (BOLT11) with liveauth_mcp_lnurl
Meter/charge API calls with liveauth_mcp_charge (per-call sats, optional toolName for revenue attribution)
Query usage/budget with liveauth_mcp_usage
Refresh JWT without re-authenticating using liveauth_mcp_refresh
Support per-tool pricing and revenue events with signed receipts (via SDK createMcpGate)
Enable paid access to MCP tools via PoW/Lightning/L402 without user accounts
Integrates with Bitcoin/Lightning Network to enable pay-per-call authentication and metering for AI agents and MCP tools.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@LiveAuth MCP Server start a new session with Lightning payment"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Authentication, pay-per-call metering, and signed receipts for AI agents and MCP tools: Bitcoin-native, Lightning-backed, and L402 compatible.
This MCP server lets any AI agent authenticate against your API using proof-of-work (free, no account) or Lightning Network micropayments (sats), then meter and monetize subsequent tool calls with per-call pricing, idempotent revenue events, and HMAC-signed receipts that auditors can verify offline.
Use it when you want to:
Gate an API or MCP tool behind real cost-of-compute or real sats (anti-spam by design, not by CAPTCHA).
Charge AI agents per call without signing them up for an account.
Issue a tamper-evident audit trail (signed mcp-call-receipt-v1) for every paid tool invocation.
Offer Lightning-backed L402 bundle access for prepaid MCP sessions.
Try it in 5 seconds — no account, no API key:
npx @liveauth-labs/mcp-serverWithout configuration, the server uses LiveAuth's anonymous demo project and the real PoW flow. Add LIVEAUTH_API_KEY only when you need a specific project's policy, pricing, or attribution.
Tool | Purpose |
| Begin a session. Returns a PoW challenge, a Lightning invoice, or an L402 bundle hint. |
| Submit a solved PoW challenge, a paid Lightning invoice, or an L402 macaroon → receive a JWT. |
| Meter usage after a call. With |
| Exchange a refresh token for a new JWT — no re-auth required. |
| Poll session/payment status (Lightning confirmation, expiry). |
| Fetch the BOLT11 invoice for a session (lnget-compatible). |
| Query remaining budget, calls used, and rate-limit windows. |
Full parameter and response schemas are in the Tool Reference below.
Related MCP server: Agent Receipts
npx @liveauth-labs/mcp-serverIn an MCP client, call liveauth_mcp_start, then call liveauth_mcp_confirm with only the returned quoteId. The package reuses its existing PoW solver locally and the LiveAuth API verifies the signed challenge before issuing a short-lived session JWT.
Grab an API key at liveauth.app.
Add to Claude Desktop's claude_desktop_config.json:
{
"mcpServers": {
"liveauth": {
"command": "npx",
"args": ["-y", "@liveauth-labs/mcp-server"],
"env": {
"LIVEAUTH_API_BASE": "https://api.liveauth.app",
"LIVEAUTH_API_KEY": "la_pk_your_public_key"
}
}
}
}Restart Claude. Done.
export LIVEAUTH_API_KEY=la_pk_xxx
npx @liveauth-labs/mcp-serverThe package is also a TypeScript SDK — see SDK Usage below. The CLI bin is liveauth-mcp.
For API providers / tool developers:
Stop bots at the protocol layer. PoW and Lightning sats are non-replayable, non-phishable, and don't require user accounts.
Charge per call in sats. We sign a receipt you can show auditors, your customers, or your accountant.
Wrap any MCP tool with one line (createMcpGate) and you get per-tool revenue, per-tool min/max pricing, and idempotent retries.
For AI agents / agent builders:
Permissionless access to paid APIs — solve a PoW or pay sats, get a JWT. No signup, no email, no OAuth dance.
Use PoW, Lightning invoices, or L402 bundle macaroons for agent access.
Projects can settle through a custom Lightning node when configured; otherwise payments use the LiveAuthCore-configured node.
The math that matters: if your tool is being scraped by a bot, charging 1 sat per call is enough to make the scraper unprofitable. We call this cost-of-attack economics, and it's the whole reason we exist.
npm install -g @liveauth-labs/mcp-serverOr use directly with npx:
npx @liveauth-labs/mcp-serverLiveAuth for Goose uses the same standards-based stdio MCP server as every other client—there is no Goose wrapper, daemon, or duplicate authentication runtime.
Or print the official deep link and current fallbacks:
npx @liveauth-labs/mcp-server setup gooseFor a one-off Goose CLI session:
goose session --with-extension "liveauth:npx -y @liveauth-labs/mcp-server"Manual Goose stdio configuration, when the deep link is unavailable:
extensions:
liveauth:
type: stdio
name: LiveAuth
enabled: true
cmd: npx
args: ["-y", "@liveauth-labs/mcp-server"]
env_keys: []
envs: {}
timeout: 300Do not edit an existing Goose config destructively. Prefer the deep link or goose configure; if you add project configuration later, enter it through Goose's extension secret settings rather than shared plaintext YAML.
Ask Goose:
Use LiveAuth to start the default authentication flow. Confirm the returned quote, then show my LiveAuth usage.
The initial flow uses the anonymous demo project's PoW challenge and does not require a wallet. A project public key is optional:
Variable | When to set it |
| Project-specific policy, pricing, and attribution. |
| A self-hosted LiveAuth API instead of |
| Explicitly opt into the older locally simulated Lightning demo. |
When a paid flow is requested, tool results retain the existing invoice fields and also include portable structured data:
{
"lightning": {
"invoice": "lnbc...",
"lightningUri": "lightning:lnbc...",
"amountSats": 21,
"expiresAt": "2030-03-17T17:46:40.000Z",
"status": "pending"
}
}Clients with MCP Apps support can render the included QR, Open Wallet action, expiration, and live paid/pending/expired state. Other clients receive the JSON and QR image content as ordinary MCP results.
If the link does not open, run npx @liveauth-labs/mcp-server setup goose and use its one-session or manual fallback.
If npx is unavailable, install a current Node.js release (Node 18 or newer).
If a supplied project key is rejected, remove it to verify the anonymous PoW flow; invalid and revoked keys intentionally do not fall back to demo.
If a Lightning invoice expires, call liveauth_mcp_start again to obtain a fresh quote.
Keep refresh tokens and any non-public credentials out of logs and plaintext configuration.
LiveAuth lets agents acquire authorization at runtime instead of requiring every tool to be provisioned with permanent credentials in advance.
The package can also be imported as a TypeScript/JavaScript SDK. Importing the package does not start the stdio MCP server; the CLI lives at the liveauth-mcp bin.
import { createMcpClient } from '@liveauth-labs/mcp-server';
const liveauth = createMcpClient({
publicKey: 'la_pk_xxx',
baseUrl: 'https://api.liveauth.app',
onInvoice(invoice) {
// Render invoice.bolt11 as a QR code for a paid Lightning test.
console.log(invoice.bolt11);
},
});
const session = await liveauth.start();
const token = await liveauth.confirm(session);
console.log(token.jwt);The client stores confirmed JWTs, refreshes them before expiry when a refresh token is returned, and exposes the current token through liveauth.token. Call liveauth.destroy() when your app is shutting down to clear token state and refresh timers.
To require a real paid invoice:
const session = await liveauth.start({ forceLightning: true });
console.log(session.invoice?.bolt11);
// Poll this after the invoice is paid.
const token = await liveauth.confirmLightning(session);import { createMcpGate } from '@liveauth-labs/mcp-server';
const gate = createMcpGate({
publicKey: 'la_pk_xxx',
baseUrl: 'https://api.liveauth.app',
});
const result = await gate.invoke(
jwtFromYourTransport,
{ message: 'hello' },
async (input, context) => ({
content: [{ type: 'text', text: input.message }],
charge: context.liveAuth.charge,
}),
{}
);gate.invoke(...) validates the JWT, charges the configured sats cost or the backend project default, and passes context.liveAuth into your handler. The older gate.gateTool(...) name is still supported.
If your MCP server has a registered LiveAuth tool ID, pass toolId when creating the gate. Charges then go to:
POST /api/mcp/tools/{toolId}/chargeinstead of the legacy generic endpoint:
POST /api/mcp/chargeYou can also pass a registered tool slug/name as toolName. In that mode charges go to the generic endpoint with tool identity in the body:
POST /api/mcp/chargeTool charges preserve the same session budget checks, but also record an immutable revenue event with gross sats, LiveAuth platform fee, developer net sats, tool method name, paying project/session/token, metadata, and idempotency key. When costSats is omitted, LiveAuthCore uses the registered tool's default price; without toolId or toolName, it falls back to the project's global MCP price.
Registered tools can also have a paid-call webhook URL. On every successful new paid call, LiveAuthCore queues a liveauth.mcp.tool.paid_call webhook with the tool identity, gross/platform/net sats, revenue event ID, metadata, and the signed receipt. If the tool webhook URL is blank, LiveAuthCore falls back to the project's webhook URL; idempotent retries do not enqueue duplicates.
import { createMcpGate } from '@liveauth-labs/mcp-server';
const gate = createMcpGate({
publicKey: process.env.LIVEAUTH_PUBLIC_KEY!,
baseUrl: process.env.LIVEAUTH_API_URL ?? 'https://api.liveauth.app',
toolName: 'paid-research-tool',
});
const result = await gate.invoke(
jwtFromYourTransport,
{ url: 'https://example.com' },
async (input, context) => {
const page = await fetch(input.url).then(r => r.text());
return {
text: page,
revenueEventId: context.liveAuth.charge.revenueEventId,
receipt: context.liveAuth.charge.receipt,
netSats: context.liveAuth.charge.netSats,
};
},
{ requestId: 'req_123' },
{
toolMethodName: 'web_fetch',
idempotencyKey: 'req_123',
agentId: 'agent_abc',
metadata: {
urlHost: new URL('https://example.com').hostname,
},
}
);When toolId or toolName is set, GateToolOptions supports:
Option | Purpose |
| Optional sats to charge for this call. Omit to use registered tool pricing or the project global price. |
| Optional per-call tool slug/name override when using the generic endpoint. |
| Method within the tool, such as |
| Retry-safe key. Reusing it for the same tool returns the original revenue event and signed receipt instead of double charging. |
| Optional caller/agent identifier for reporting. |
| Small JSON object for audit context. Do not store private tool output here. |
Tool charge responses include the normal budget counters plus revenue accounting:
{
"status": "ok",
"callsUsed": 3,
"satsUsed": 15,
"grossSats": 5,
"platformFeeSats": 1,
"netSats": 4,
"feeBasisPoints": 500,
"revenueEventId": "event-guid",
"toolId": "tool-guid",
"toolName": "Paid Research Tool",
"toolSlug": "paid-research-tool",
"receipt": {
"version": "mcp-call-receipt-v1",
"payload": "base64url-canonical-json",
"signature": "base64url-hmac-sha256",
"signatureAlgorithm": "HMAC-SHA256",
"keyId": "liveauth-mcp-receipt-v1",
"body": {
"receiptId": "mcp_receipt_eventguid",
"revenueEventId": "event-guid",
"mcpToolId": "tool-guid",
"toolName": "Paid Research Tool",
"toolSlug": "paid-research-tool",
"toolMethodName": "web_fetch",
"grossSats": 5,
"platformFeeSats": 1,
"netSats": 4,
"idempotencyKey": "req_123"
}
}
}The receipt is a signed per-call audit artifact returned by LiveAuthCore for paid tool charges. Store it with your tool result when you need proof of charge or later reconciliation.
If no toolId or toolName is configured, the SDK keeps using /api/mcp/charge for backward-compatible usage metering.
Add to your claude_desktop_config.json:
{
"mcpServers": {
"liveauth": {
"command": "npx",
"args": ["-y", "@liveauth-labs/mcp-server"],
"env": {
"LIVEAUTH_API_BASE": "https://api.liveauth.app",
"LIVEAUTH_API_KEY": "la_pk_your_public_key"
}
}
}
}Credential-free mode: If you omit LIVEAUTH_API_KEY, the server calls the normal MCP endpoints without a project header. LiveAuth binds its configured anonymous demo project, returns a signed PoW challenge, and preserves normal verification, JWT, rate-limit, and metering boundaries. LIVEAUTH_DEMO=true remains an explicit opt-in to the older locally simulated Lightning preview.
Other env vars:
Variable | Default | Purpose |
| (unset) | Your LiveAuth project public key ( |
|
| Override for self-hosted LiveAuth. |
|
| Explicitly use the legacy locally simulated Lightning demo. |
The server speaks stdio (JSON-RPC 2.0). Start it with:
liveauth-mcpIt also works with any MCP-compatible client: Cursor, VS Code, ChatGPT, Windsurf, Continue, Cline.
Full schemas for each MCP tool. Each tool is JSON-RPC 2.0 compatible and tested under src/index.test.ts and src/cli.test.ts.
liveauth_mcp_startStart a new LiveAuth MCP session. Returns a PoW challenge by default, or a Lightning invoice if forceLightning=true.
Parameters:
forceLightning (boolean, optional): If true, request Lightning invoice instead of PoW challenge
forceL402 (boolean, optional): If true, start a session that should be confirmed with an L402 bundle macaroon
Returns (PoW):
{
"quoteId": "uuid-of-session",
"powChallenge": {
"projectId": "guid",
"projectPublicKey": "la_pk_...",
"challengeHex": "a1b2c3...",
"targetHex": "0000ffff...",
"difficultyBits": 18,
"expiresAtUnix": 1234567890,
"signature": "sig..."
},
"invoice": null
}Returns (Lightning):
{
"quoteId": "uuid-of-session",
"powChallenge": null,
"invoice": {
"bolt11": "lnbc...",
"amountSats": 50,
"expiresAtUnix": 1234567890,
"paymentHash": "abc123..."
},
"lightning": {
"invoice": "lnbc...",
"lightningUri": "lightning:lnbc...",
"amountSats": 50,
"expiresAt": "2009-02-13T23:31:30.000Z",
"expiresAtUnix": 1234567890,
"status": "pending"
}
}Returns (L402 bundle):
{
"quoteId": "uuid-of-session",
"powChallenge": null,
"invoice": null,
"authHint": "l402_bundle"
}liveauth_mcp_confirmSubmit a solved proof-of-work challenge, let the package solve its cached challenge, poll a Lightning payment, or present an L402 macaroon to receive a JWT authentication token.
Parameters:
quoteId (string): The quoteId from the start response
challengeHex (string, optional, PoW only): The challenge hex from the start response
nonce (number, optional, PoW only): The nonce that solves the PoW challenge
hashHex (string, optional, PoW only): The resulting hash (sha256 of projectPublicKey:challengeHex:nonce)
expiresAtUnix (number, optional, PoW only): Expiration timestamp from the challenge
difficultyBits (number, optional, PoW only): Difficulty bits from the challenge
signature (string, optional, PoW only): Signature from the challenge
macaroon (string, L402 only): Bundle macaroon returned from the L402 bundle claim flow
When the challenge came from this MCP server, calling confirm with quoteId alone reuses the package's existing PoW solver. Explicit solution fields remain supported for compatibility.
Returns:
{
"jwt": "eyJhbGc...",
"expiresIn": 600,
"remainingBudgetSats": 10000,
"refreshToken": "abc123def456..."
}Note: Store the refreshToken securely. It is returned in MCP tool data but never written to stderr or application logs. Use liveauth_mcp_refresh to get a new JWT without re-authenticating.
liveauth_mcp_chargeMeter API usage after making an authenticated call. The bundled MCP server calls the generic /api/mcp/charge endpoint. Supplying toolName lets LiveAuth resolve a registered tool, apply its configured price, and create a paid-tool revenue event; omitting toolName keeps backward-compatible generic metering.
Parameters:
callCostSats (number, optional): Cost of the API call in sats. Omit to use backend pricing.
toolName (string, optional): Registered MCP tool slug/name for per-tool pricing and attribution.
Returns:
{
"status": "ok",
"callsUsed": 5,
"satsUsed": 15
}If budget is exceeded:
{
"status": "deny",
"callsUsed": 100,
"satsUsed": 1000,
"reason": "budget_exceeded"
}liveauth_mcp_statusCheck the status of an MCP session. Use to poll for Lightning payment confirmation.
Parameters:
quoteId (string): The quoteId from the start response
Returns:
{
"quoteId": "uuid-of-session",
"status": "pending",
"paymentStatus": "pending",
"expiresAt": "2026-02-17T12:00:00Z"
}When paymentStatus is "paid", the session is confirmed. Call liveauth_mcp_confirm again to get the JWT.
liveauth_mcp_lnurlGet the Lightning invoice for a session (lnget-compatible). Use this to retrieve the BOLT11 invoice for payment with any Lightning wallet.
Parameters:
quoteId (string): The quoteId from the start response
Returns:
{
"pr": "lnbc2100n1...",
"routes": []
}Note: This is compatible with lnget and other Lightning payment tools. Use this to poll for the invoice when liveauth_mcp_confirm returns "payment pending".
liveauth_mcp_usageQuery current usage and remaining budget without making a charge. Use this to check status before making API calls.
Parameters: (none required)
Returns:
{
"status": "active",
"callsUsed": 5,
"satsUsed": 15,
"maxSatsPerDay": 10000,
"remainingBudgetSats": 9985,
"maxCallsPerMinute": 60,
"expiresAt": "2026-02-17T12:00:00Z",
"dayWindowStart": "2026-02-17T00:00:00Z"
}liveauth_mcp_refreshRefresh the JWT token without re-authenticating. Use the refreshToken returned from confirm to get a new JWT when the current one expires.
Parameters:
refreshToken (string): The refreshToken from the confirm response
Returns:
{
"jwt": "eyJhbGc...",
"expiresIn": 600,
"remainingBudgetSats": 9985
}Note: Save the refreshToken securely. You'll need it to extend the session without solving a new PoW or making another Lightning payment.
Call liveauth_mcp_start to get a PoW challenge and quoteId
Call liveauth_mcp_confirm with the quoteId; the MCP server solves its cached challenge with the existing package solver
Advanced clients may still submit an explicit solution (hash = sha256(projectPublicKey:challengeHex:nonce) where hash < targetHex)
Use the JWT in Authorization: Bearer <token> header for API requests
After each generic API call, call liveauth_mcp_charge with a call cost, or omit it to use the project global MCP price
For monetized MCP tools, wrap handlers with createMcpGate({ toolId }) or createMcpGate({ toolName }) so each call creates a revenue event and signed receipt
Call liveauth_mcp_start with forceLightning: true to get a Lightning invoice
Use liveauth_mcp_lnurl (or poll liveauth_mcp_status) to get the BOLT11 invoice
Pay the invoice using your Lightning node/wallet
Poll liveauth_mcp_status with the quoteId until paymentStatus is "paid"
Call liveauth_mcp_confirm with just the quoteId to receive the JWT
Use the JWT with either generic liveauth_mcp_charge metering or SDK paid-tool attribution
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ AI Agent │────▶│ MCP Server │────▶│ LiveAuth API │
│ │ │ │ │ │
│ 1. Start │ │ /api/mcp/start │ │ Returns PoW │
│ 2. Solve PoW │ │ │ │ challenge │
│ 3. Confirm │ │ /api/mcp/confirm│ │ Returns JWT │
│ 4. API calls │ │ │ │ │
│ 5. Charge │ │ /api/mcp/charge │ │ Meter usage │
└─────────────────┘ └─────────────────┘ └─────────────────┘Paid tool servers use the same JWT but charge through an attributed endpoint:
Agent calls MCP tool
→ Tool server calls POST /api/mcp/tools/{toolId}/charge
or POST /api/mcp/charge with toolName
→ LiveAuth validates JWT and budget
→ LiveAuth records gross / platform fee / net revenue and returns a signed receipt
→ Tool handler runs and returns the resultLiveAuthCore supports Lightning-backed L402 bundles for prepaid MCP access. Buy a bundle, claim the macaroon after payment, then start an MCP session in L402 mode and confirm it with that macaroon.
# 1. Create a bundle invoice.
curl -X POST https://api.liveauth.app/api/public/l402/bundle/invoice \
-H "Content-Type: application/json" \
-d '{"publicKey":"la_pk_xxx","tier":"starter","agentId":"agent_abc"}'
# 2. After the invoice is paid, claim a macaroon.
curl -X POST https://api.liveauth.app/api/public/l402/bundle/claim \
-H "Content-Type: application/json" \
-d '{"publicKey":"la_pk_xxx","paymentHash":"payment_hash_from_step_1"}'
# 3. Start and confirm an MCP session with the macaroon.
curl -X POST https://api.liveauth.app/api/mcp/start \
-H "X-LW-Public: la_pk_xxx" \
-H "Content-Type: application/json" \
-d '{"forceL402":true}'
curl -X POST https://api.liveauth.app/api/mcp/confirm \
-H "X-LW-Public: la_pk_xxx" \
-H "Content-Type: application/json" \
-d '{"quoteId":"quote_id_from_step_3","macaroon":"macaroon_from_step_2"}'# Install dependencies
npm install
# Build
npm run build
# Run locally
node dist/cli.jsMIT
Categories: authentication · payments · lightning · l402 · bitcoin · pay-per-call · metering · agent-tools · anti-abuse · mcp-server · typescript
Meter API usage after making an authenticated call. Call this with the cost in sats for each API request made using the JWT.
| Name | Required | Description | Default |
|---|---|---|---|
| toolName | No | Optional registered MCP tool slug or name for per-tool pricing and revenue attribution. | |
| callCostSats | No | Optional cost of the API call in sats. Omit to use LiveAuth project or tool pricing. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits on its own. It mentions the action 'Meter API usage' but does not explain side effects like deducting sats, idempotency (e.g., calling twice), prerequisites beyond JWT authentication, or error behavior. As a monetary/charge operation, the lack of these details is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two short sentences that front-load the core action ('Meter API usage') and then provide the invocation details. There is no redundant or filler content; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two optional parameters, the description gives a decent overview of purpose and usage. However, with no annotations or output schema, it omits important context such as the expected response, idempotency, and failure modes. It is minimally sufficient but not fully complete for a financial metering operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full documentation for both parameters (100% coverage). The description adds minor context (e.g., 'cost in sats for each API request') but does not meaningfully enrich the understanding of toolName or callCostSats beyond their schema descriptions. The high schema coverage justifies the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Meter API usage after making an authenticated call.' It identifies a specific verb (meter/charge) and resource (API usage), and the context (after an authenticated call) distinguishes it from sibling tools like liveauth_mcp_usage, which likely queries usage rather than recording it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs when to call the tool: 'Call this with the cost in sats for each API request made using the JWT.' This clearly conveys per-request usage after authentication. However, it doesn't explicitly mention alternatives or conditions when not to use it, preventing a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit the solved proof-of-work challenge (or poll for Lightning payment) to receive a JWT. For Lightning, call with just quoteId to check/poll payment status.
| Name | Required | Description | Default |
|---|---|---|---|
| nonce | No | The nonce that solves the PoW challenge (PoW only) | |
| hashHex | No | The resulting hash hex (PoW only) | |
| quoteId | Yes | The quoteId from the start response | |
| macaroon | No | L402 bundle macaroon (L402 only) | |
| signature | No | Signature from the challenge (PoW only) | |
| challengeHex | No | The challenge hex from the start response (PoW only) | |
| expiresAtUnix | No | Expiration timestamp from the challenge (PoW only) | |
| difficultyBits | No | Difficulty bits from the challenge (PoW only) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the dual-mode behavior (PoW vs Lightning), that polling is possible, and the outcome (JWT). However, it does not disclose failure modes, side effects like challenge invalidation, or retry semantics, leaving important behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main action, and the second provides a specific usage tip. No waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 8 parameters and two distinct flows, with no annotations and no output schema. The description covers the core purpose and outcome but lacks details on error conditions, success/failure responses, and safety of repeated calls. It is adequate but not comprehensive for the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 adds mode-specific guidance: 'call with just quoteId' for Lightning, implying PoW uses the other fields. This clarifies how to select parameters by mode, going beyond the schema's individual descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: submitting a solved proof-of-work challenge or polling for Lightning payment to receive a JWT. This clearly distinguishes it from siblings like start (which likely initiates) and status (which likely checks overall status).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance: for Lightning, call with just quoteId to check/poll payment status, and PoW requires the challenge-solution fields. It does not explicitly name alternatives or when-not-to-use, but the sibling names and context make it inferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the Lightning invoice for a session (lnget-compatible). Use this to retrieve the BOLT11 invoice for payment.
| Name | Required | Description | Default |
|---|---|---|---|
| quoteId | Yes | The quoteId from the start response |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that the tool retrieves an invoice, but does not clarify side effects, return format, expiration, or whether it is a read-only operation. The mention of 'lnget-compatible' is vague and adds little transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but the two sentences are somewhat redundant: 'Get the Lightning invoice' is repeated as 'retrieve the BOLT11 invoice.' It could be condensed into a single sentence without losing information, so it is not maximally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only one parameter with good schema coverage, but no output schema and no annotations. The description does not explain what the response looks like, potential errors, or any behavioral context like payment flow or invoice validity. Given the lack of structured metadata, this is insufficient for an agent to fully understand the tool's role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage by describing quoteId as 'The quoteId from the start response.' The description adds no additional meaning about the parameter, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get the Lightning invoice for a session' and also mentions 'retrieve the BOLT11 invoice for payment.' This provides a specific verb and resource, but it does not explicitly differentiate from sibling tools like start, status, or charge, so it does not reach a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Use this to retrieve the BOLT11 invoice for payment,' which implies the tool is for obtaining an invoice after starting a session. However, it does not explicitly state when to use it versus alternatives, nor does it mention any prerequisites or exclusions. This falls under implied usage rather than clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Refresh the JWT token without re-authenticating. Use the refreshToken returned from confirm to get a new JWT.
| Name | Required | Description | Default |
|---|---|---|---|
| refreshToken | Yes | The refreshToken from the confirm response |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses a key behavior (no re-authentication required) and the outcome (new JWT). However, it does not mention token rotation, single-use semantics, error handling, or response format, leaving gaps for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, no filler. The main purpose is front-loaded, and the parameter guidance is integrated naturally. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description is nearly complete: it explains the purpose, the input source, and the expected result (new JWT). It lacks only minor details like potential errors or whether the refresh token is reusable, but these are not critical for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description for refreshToken already provides full coverage (100%), and the tool description essentially restates the same source. Since the schema does the heavy lifting, the description adds minimal extra meaning, hence the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource ('refresh the JWT token') and explicitly states what it achieves ('get a new JWT'). It also distinguishes itself from siblings by referencing the confirm response, making its role in the auth flow clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states when to use this tool: after confirm, using the refreshToken from confirm. It implies it is the alternative to re-authenticating, providing a clear context. It does not explicitly list exclusions or alternatives, but the sibling set makes the intended use obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a new LiveAuth MCP session. Returns a PoW challenge (default), Lightning invoice, or L402 bundle auth hint.
| Name | Required | Description | Default |
|---|---|---|---|
| forceL402 | No | If true, request an L402 bundle auth session | |
| forceLightning | No | If true, request Lightning invoice instead of PoW challenge |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It does state the return types and the default PoW challenge, but it omits potential side effects, such as whether starting a new session invalidates existing ones or requires prior authentication. This leaves important behavioral context undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the action and the possible outcomes. It contains no redundant or filler phrases, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two optional parameters and no output schema, the description covers the core return types and default behavior. While it could provide more detail about the response structure or next steps, the information given is sufficient to understand the tool's basic operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptive definitions for both boolean parameters. The description adds no additional parameter-level meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Start' and resource 'LiveAuth MCP session', making the purpose unambiguous. It distinguishes itself from sibling tools by clearly indicating this is the initialization action, and it enumerates the distinct return types (PoW challenge, Lightning invoice, L402 bundle).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is the entry point for starting a session, but it does not explicitly state when to use it versus sibling tools like liveauth_mcp_status or liveauth_mcp_charge. No prerequisites or alternative usage scenarios are provided, so the guidance remains at an implied level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the status of an MCP session. Use to poll for Lightning payment confirmation. Also returns the invoice via lnurl compatibility.
| Name | Required | Description | Default |
|---|---|---|---|
| quoteId | Yes | The quoteId from the start response |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It reveals that the tool returns an invoice via lnurl compatibility and implies a read-only polling nature, but it doesn't explicitly state read-only behavior, side effects, or what constitutes a 'status.' This is adequate but lacks rich safety or state-change disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose, and includes a specific usage example. Every sentence adds value with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, no output schema), the description covers the essential context: what it does, when to use it, and a hint about the returned invoice. However, it doesn't describe the full status response structure or possible statuses, which might be useful for a polling tool, but overall it's sufficient for the low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with the only parameter 'quoteId' described as 'The quoteId from the start response.' The description adds no additional parameter-level meaning, but the schema already covers it fully, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Check the status of an MCP session' with a specific use case ('poll for Lightning payment confirmation'). It also distinguishes itself from siblings by focusing on status and polling, and the added detail about lnurl compatibility further clarifies the tool's unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use to poll for Lightning payment confirmation,' which provides clear guidance for when to invoke this tool. It doesn't mention alternatives or exclusions, but the polling context is sufficient for a status tool in a payment flow, making it clear this is the follow-up to start/confirm actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query current usage and remaining budget for the MCP session. Use this to check how many sats and calls have been used without making a charge.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It does disclose a key behavioral trait: 'without making a charge' indicates the call is non-destructive and free. However, it doesn't clarify whether the usage query itself counts as a call or affect the budget, nor does it explain any side effects or limit conditions. This is a minor gap for a read-only usage tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core purpose, and contains no filler. Every word contributes to understanding the tool's function and when to use it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and no output schema, the description is complete. It clearly states what it queries (usage and remaining budget), the metrics (sats and calls), and the key safety aspect (no charge). No additional context is necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds no parameter details, but none are needed. It correctly focuses on the tool's purpose and usage rather than param syntax.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Query' and identifies a clear resource: 'current usage and remaining budget for the MCP session.' It also distinguishes itself from siblings like 'status' and 'charge' by focusing on budget/calls usage, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'Use this to check how many sats and calls have been used without making a charge.' This provides clear context and implies it's a non-charging alternative to 'liveauth_mcp_charge'. It doesn't explicitly name alternatives or exclusions, but the guidance is practical and sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.8liveauth_mcp_chargeliveauth_mcp_confirmliveauth_mcp_lnurlliveauth_mcp_refreshliveauth_mcp_startliveauth_mcp_statusliveauth_mcp_usageEach tool maps to a distinct auth lifecycle step: start initiates, lnurl fetches invoice, confirm resolves auth, refresh renews token, charge/usage handle metering, and status reports state. Slight overlap exists between status and confirm when polling payment, but descriptions clarify their primary roles.
All tools share the consistent liveauth_mcp_ prefix and snake_case format. Most use verbs (start, confirm, refresh, charge), but status, usage, and lnurl are noun-based, creating minor deviations from a strict verb pattern.
With 7 tools, the set is well-scoped for the server's purpose. Each tool covers a specific function without redundancy, fitting comfortably in the ideal 3-15 tool range.
The toolset provides full lifecycle coverage: starting a session, retrieving invoices, confirming authentication, refreshing tokens, and tracking/metering usage. No significant operational gaps are apparent for the stated authentication and payment domain.
Pay-per-action access to APIs and MCP tools over Lightning L402 and Base USDC x402.
Pay-per-call APIs and MCP services for agents, no accounts or keys, with verifiable receipts.
External counterparty-risk checks and signed receipts for autonomous agents and machine payments.
Bitcoin-anchored, tamper-evident audit-permanence layer for AI agents, FRE 902(13)/(14)-shaped.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/dulzuradev/liveauth-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server