compute.wick.pics

rent_x402

Rent a prepaid block of GPU time with a wallet and NO account, NO API key and no human, over x402 (HTTP 402 micropayments, USDC on Base).

Call it with no arguments and you get the payment challenge: an x402
PaymentRequirementsResponse whose accepts[0].extra.x402_fee states the block
price, the platform fee IN DOLLARS, that there are no refunds, and that you
are charged only after the lease is live. Sign the EIP-3009
transferWithAuthorization it describes, then call again with x_payment set to
the base64 PaymentPayload (the same value the HTTP rail sends as X-PAYMENT).

`ssh_pubkey` is HOW YOU GET IN, and is required on the paying call: pass the
public half of your ssh key (one line, the contents of id_ed25519.pub). It is
written into the rented container's authorized_keys and nowhere else, and the
receipt comes back with the host and port to connect to. A block nobody can
enter is not sold.

`lease_id` is minted by the challenge — send back the one you were given; it
is the accrual key for the daily fee cap and this station refuses ids it did
not mint or that belong to another payer.

`originator` is an OPTIONAL opaque attribution label (<=64 chars, e.g. a
handle or a reverse-DNS name) naming the client implementation that produced
the fill. It is carried unmodified onto the receipt and onto the public
ledger row, and it never affects the price, the fee, verification or
settlement — the same block costs the same either way.

Returns the receipt on success. Every fill is published at /api/receipts.
Wire contract: docs/X402-FEE-0.1.md, frozen as x402-fee/0.1.

Note for x402 MCP-transport clients: this tool takes the payment as an
ARGUMENT rather than in _meta["x402/payment"]. The payload is byte-identical;
only the channel differs, because a tool argument is the one place every MCP
client can portably put it. The HTTP rail is fully transport-conformant.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`blocks`	No
`lease_id`	No
`x_payment`	No
`originator`	No
`ssh_pubkey`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedAug 28, 2026

addedInput schema / properties / ssh_pubkey

Added value: +{
+  "default": "",
+  "title": "Ssh Pubkey",
+  "type": "string"
+}

AddedAug 28, 2026

TDQS

A4.5/5.0

Behavior5/5

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

With no annotations provided, the description carries full responsibility for disclosing behavior, and it does so thoroughly. It reveals the two-call payment flow, that refunds do not exist, that the payer is charged only after the lease is live, that ssh_pubkey is written into the container's authorized_keys and nowhere else, and that originator never affects price or settlement. It also discloses MCP-specific transport differences without misleading the caller.

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

Conciseness4/5

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

The description is long but densely packed with necessary operational detail. It is well-structured with paragraphs for each key parameter and a clear MCP note at the end. No sentence is purely filler, though some redundancy around 'same value' and 'byte-identical' could be tightened. The front-loading of the core concept helps an agent quickly grasp the tool's purpose.

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?

For a complex paid tool with no output schema and no annotations, the description covers the payment challenge, required signing flow, ssh access, lease_id provenance, originator semantics, receipt publication, and a frozen wire-contract doc link. The main gap is incomplete documentation of the blocks parameter and no explicit error-handling or failure-mode guidance. Even so, the description is substantially complete for an agent to invoke the tool correctly.

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 description coverage is 0%, so the description must compensate for all parameters. It does: x_payment, ssh_pubkey, lease_id, and originator are each explained with format, purpose, and constraints. However, the blocks parameter is only implied via 'prepaid block' and the default behavior of calling with no arguments; its semantics, bounds, and effect on price are not explicitly stated. This leaves one parameter underdocumented.

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 opens with a specific verb-resource pair: 'Rent a prepaid block of GPU time' and clearly identifies the unique payment mechanism (x402 HTTP 402 micropayments, USDC on Base). It distinguishes this tool from its siblings by emphasizing no account, no API key, and no human, which no other rental tool appears to state. The two-phase payment challenge explanation further removes ambiguity.

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 explicit, step-by-step usage: call with no arguments to get the challenge, sign the EIP-3009 authorization, then call again with x_payment. It also states when each parameter is required and the role of lease_id. It does not explicitly compare against alternatives like rent_offer or rent_best, but the usage context is clear enough that an agent can determine when to invoke it.

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

All compute.wick.pics 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.

rent_x402

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources