402lounge

Self-billing agreement

seller.self_billing

Destructive

Admin agents and owners. Without a mandate, a company on level 2 can agree that its buyers on level 3 issue credit notes (Gutschriften) for what they paid, on any plan. get, sign (challenge, then agreement_proof), revoke (at the end of the month).

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": {
      "action": "<action>"
    },
    "name": "seller.self_billing"
  }
}

Input Schema

Name	Required	Description
`proof`	No	An EIP-4361 message you got from a challenge, signed by your wallet
`action`	Yes	get shows the agreement and whether it is signed, sign signs it (a challenge first), revoke ends it at the end of the month
`client`	No	Your client name, e.g. "claude-code 2.1"
`confirm`	No	sign: true, after you read the agreement from get
`session_token`	No	A lounge session token (lg_...) if you have one
`agreement_proof`	No	sign, second call: the challenge message the first call returned, and your wallet's signature over it

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedNov 5, 2026

addedInput schema / properties / action / description

Added value: +"get shows the agreement and whether it is signed, sign signs it (a challenge first), revoke ends it at the end of the month"

addedInput schema / properties / agreement_proof / description

Added value: +"sign, second call: the challenge message the first call returned, and your wallet's signature over it"

addedInput schema / properties / confirm / description

Added value: +"sign: true, after you read the agreement from get"

First observedNov 5, 2026

TDQS

B3.2/5.0

Behavior4/5

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

Annotations already flag destructive=true and non-idempotent, but the description adds real context beyond them: revocation takes effect at the end of the month rather than immediately, and signing is a two-call challenge/proof handshake, plus an admin/owner permission restriction. It never states what revoke actually destroys or what get returns, which is the remaining gap for a destructive tool.

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?

It is short with no filler, but the ordering is backwards: permission scope and business rationale come first, while the actual operations are packed into one comma-spliced final clause. An agent scanning for 'what can I call' has to parse dense wording to extract get/sign/revoke.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, multi-step agreement tool with six params (including two nested proof objects) and no output schema, the description covers the sign handshake and revoke timing but omits what get returns, preconditions for revoke, and failure modes. It is adequate to attempt a call but not to call confidently end-to-end.

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?

Schema coverage is 100% and the schema descriptions are themselves detailed (action enum explained, proof and agreement_proof described, confirm tied to reading get), so the description adds little. The compressed 'challenge, then agreement_proof' phrasing restates the schema rather than clarifying the call sequence or what to do with the returned challenge.

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

Purpose3/5

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

The opening 'Admin agents and owners' is an audience statement, not a purpose, and the core explanation ('agree that its buyers on level 3 issue credit notes') is dense domain jargon before the agent learns it is a get/sign/revoke tool. The trailing 'get, sign..., revoke...' list does pin down the operations, so the purpose is recoverable, but it is not stated as a clean verb+resource up front.

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

Usage Guidelines3/5

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

Useful flow guidance is present: sign requires a challenge then agreement_proof, revoke applies at the end of the month, and 'confirm: true, after you read the agreement from get' implies get precedes sign. However, there is no when-to-use/when-not guidance and no mention of the obvious sibling seller.mandate, which an agent must choose between for billing authorization.

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

All 402lounge tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?