Skip to main content
Glama

Enrol nodes

rent_supply_enroll

Makes claim tokens for new nodes, one per node, each valid for 10 minutes and shown only in this answer. lines holds the exact shell line for each token: run it on the machine and the node kit sets the machine up, claims the node, links it and reports each step. The token reaches the kit on stdin, never as a process argument. On a host the claim comes after the install, and a first install can outlast the token: when the line ends with claim_invalid, call this tool again and run the same line with the new token. That run is quick, because the host is already set up. payout registers the USDC address every node of this enrolment is paid to; without it the nodes are not paid until one is set with rent_supply_update_node. Ask the user for the address; never make one up. Each node is paid once a day, in USDC, to the address registered on that node; a node without an address is not paid and its releasable earnings wait until one is registered. A payout cannot be reversed, and a payout made is never sent again to another address. A refusal carries retryable, owner_action_required and next; run next.command after next.after_s seconds.

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": {
      "wire": "<wire>",
      "region": "<region>",
      "ask": "<ask>",
      "capacity": "<capacity>"
    },
    "name": "rent_supply_enroll"
  }
}

Input Schema

NameRequiredDescriptionDefault
askYesWhat you ask per hour. Customers pay this plus rent.dev's take.
wireYes`e2b`: a Linux host where the node kit installs the sandbox stack. `rent`: a driver file you write for your own platform.
countNoNodes to enrol: one claim token each. Default 1.
payoutNoWhere this node's payouts go. Each node is paid once a day, in USDC, to the address registered on that node; a node without an address is not paid and its releasable earnings wait until one is registered. A payout cannot be reversed, and a payout made is never sent again to another address.
regionYesA generic region label such as `us-central` or `eu-central`, never a vendor's.
capacityYesWhat each node offers.

Output Schema

NameRequiredDescriptionDefault
idYes
linesYesOne entry per claim token: the exact shell line with that token in it.
installYes
guide_urlYes
expires_atYes
claim_tokensYesShown once: one per node.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • removedInput schema / properties / payout / additionalProperties
      Removed value: -{
      -  "type": "string"
      -}
    • changedInput schema / properties / payout / description
      Previous value: -"Payout details, stored as given. Nothing pays out yet."New value: +"Where this node's payouts go. Each node is paid once a day, in USDC, to the address registered on that node; a node without an address is not paid and its releasable earnings wait until one is registered. A payout cannot be reversed, and a payout made is never sent again to another address."
    • addedInput schema / properties / payout / properties
      Added value: +{
      +  "address": {
      +    "description": "The USDC address payouts go to: 0x and 40 hex digits, lowercase or with a correct EIP-55 checksum, never the zero address.",
      +    "type": "string"
      +  },
      +  "network": {
      +    "description": "CAIP-2 network of the address, e.g. `eip155:8453`. Leave it out for the payout network; any other is refused.",
      +    "type": "string"
      +  }
      +}
    • removedInput schema / properties / payout / propertyNames
      Removed value: -{
      -  "type": "string"
      -}
    • addedInput schema / properties / payout / required
      Added value: +[
      +  "address"
      +]
  2. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already identify this as a non-read-only, non-idempotent mutation. The description adds important behavior beyond them: token lifetime and secrecy, stdin-only token delivery, install/claim ordering, recovery from `claim_invalid`, irreversible daily USDC payouts, and refusal response fields.

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 core action is front-loaded and most sentences carry operationally relevant detail. However, the paragraph is long and repeats the payout rules almost verbatim from the schema, and some explanatory sentences could be compressed without losing meaning.

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 enrolment mutation with a rich schema and output schema, the description covers prerequisites, returned shell lines, first-install edge cases, financial consequences, and refusal handling. An agent has enough information to invoke and recover 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 coverage is 100%, so most parameter semantics are already supplied by the schema. The description adds useful meaning for `payout` by saying it applies to every node in the enrolment, instructing the agent to ask the user and never invent an address, and naming `rent_supply_update_node` for later registration.

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 sentence states a specific verb and resource: making claim tokens for new nodes. It also specifies one token per node, a 10-minute validity, and answer-only visibility, making it distinguishable from list/update siblings.

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 clear enrolment context, explains the `claim_invalid` retry workflow, and points to `rent_supply_update_node` when payout is omitted. It does not explicitly compare against all sibling tools such as probe or revoke, but the when-to-use context is clear.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources