rent.dev

Probe a node now

rent_supply_probe_node

Makes the node's next probe due now, and takes a suspended node back to probing. The probe starts within about a minute. Read the outcome with rent_supply_node. A probe already running is refused with probe_in_progress. 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": {
      "node_id": "<node_id>"
    },
    "name": "rent_supply_probe_node"
  }
}

Input Schema

Name	Required	Description	Default
`node_id`	Yes	Node id (`n` and 15 characters) from rent_supply_nodes, or from the node kit once a node is claimed.

Output Schema

Name	Required	Description	Default
`id`	Yes
`ask`	Yes
`kit`	No
`next`	Yes
`wire`	Yes
`state`	Yes
`checks`	Yes
`payout`	Yes
`region`	Yes
`reasons`	Yes
`capacity`	Yes
`phase_ms`	Yes
`placement`	Yes
`reachable`	Yes
`templates`	Yes
`endpoint_id`	Yes
`time_to_first_payable_ms`	Yes
`time_to_first_customer_lease_ms`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 12, 2026

addedOutput schema / properties / payout

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": false,
+      "properties": {
+        "address": {
+          "pattern": "^0x[0-9a-f]{40}$",
+          "type": "string"
+        },
+        "network": {
+          "anyOf": [
+            {
+              "pattern": "^eip155:[1-9][0-9]*$",
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        }
+      },
+      "required": [
+        "address",
+        "network"
+      ],
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}

changedOutput schema / required

Previous value: -[
-  "id",
-  "endpoint_id",
-  "state",
-  "wire",
-  "region",
-  "ask",
-  "capacity",
-  "templates",
-  "checks",
-  "reasons",
-  "reachable",
-  "next",
-  "phase_ms",
-  "placement",
-  "time_to_first_payable_ms",
-  "time_to_first_customer_lease_ms"
-]New value: +[
+  "id",
+  "endpoint_id",
+  "state",
+  "wire",
+  "region",
+  "ask",
+  "capacity",
+  "templates",
+  "checks",
+  "reasons",
+  "reachable",
+  "next",
+  "phase_ms",
+  "placement",
+  "time_to_first_payable_ms",
+  "time_to_first_customer_lease_ms",
+  "payout"
+]

First observedNov 12, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Adds substantial context beyond the annotations: the probe starts within about a minute, a suspended node is resumed, and a concurrent probe is refused with the `probe_in_progress` code. It further explains the refusal payload (`retryable`, `owner_action_required`, `next`) and how to act on it, which is exactly the kind of operational detail annotations cannot carry.

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?

Three short sentences, front-loaded with the action, then the read path, then the failure handling. No redundant or filler wording; every sentence carries distinct information.

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?

Covers the action, the timing expectation, the state transition, the alternative for reading results, and the refusal contract with remediation. With an output schema already present and full parameter coverage, an agent has everything needed to call it and handle the common failure mode.

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 schema fully documents the single `node_id` parameter, including its format and where to obtain it, so the description does not need to compensate. It adds no additional meaning about the parameter, which is the expected baseline when coverage is 100%.

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?

States a specific verb and resource: makes the node's next probe due immediately and returns a suspended node to probing. This is clearly distinct from rent_supply_node, which the description names as the way to read the outcome, so an agent can separate the trigger from the read.

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?

Gives clear context: use this to force a probe now, use rent_supply_node to read the result. It also documents the refusal path (probe_in_progress) and the follow-up (`next.command` after `next.after_s`). It does not explicitly say when not to call it beyond the running-probe refusal, but the operating condition is clear.

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

All rent.dev 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?