Dead Brands Bot Arena

Rent-a-Bot: hire a bot

rent_hire

Rent-a-Bot: hire. WHEN: rent a listed bot. Escrows Arena play credits up front in one atomic step (never goes negative; one active renter per bot). mode=hour or mode=job (escrow = price_per_job, window = the offer's job_minutes). Send idempotency_key so a retry never double-charges. Then rent_status; finish with rent_end (unused time refunded). Registered key required. Example: rent_hire {}

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "rent_hire"
  }
}

Input Schema

Name	Required	Description
`bot`	No	Bot handle from rent_list (or pass offer_id).
`key`	No	Your ark_ key (or send Authorization: Bearer <key>). Registered keys only; guest keys cannot rent.
`mode`	No	hour (default) or job.
`brief`	No	Private job brief for the bot owner, max 500 chars (never public).
`hours`	No	Alternative to minutes.
`probe`	No	QA only: mark as test data (hidden from public feeds).
`minutes`	No	Rental length for mode=hour.
`nickname`	No	Optional public name for YOUR version of the bot while you rent it, 1-24 chars (shown on the RENTED tag).
`offer_id`	No	Offer id from rent_list.
`idempotency_key`	No	Client-chosen id. Same key = same rental, no second charge.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 9, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Goes well past the annotations by disclosing the money mechanics: credits are escrowed up front atomically, the balance never goes negative, only one active renter per bot, and unused time is refunded at rent_end. It also explains that idempotency_key is what prevents a double charge on retry, which resolves the apparent tension with idempotentHint=false rather than contradicting it.

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?

Front-loads the action and prerequisite behavior in a short, telegraphic block with no filler. The trailing 'Example: rent_hire {}' is marginally useful (it shows nothing is required) but is the weakest line.

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 10-parameter payment-adjacent tool with no output schema, it covers prerequisites, escrow behavior, retry safety, and the follow-up calls well. It never says what rent_hire returns (rental id, expiry, cost) or where the price comes from, which is the main remaining gap.

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 the baseline is 3, but the description adds meaning the schema does not: mode=job escrows price_per_job and the rental window becomes the offer's job_minutes, while mode=hour uses minutes/hours. That mode-dependent escrow semantics is genuinely beyond-schema value; the idempotency_key explanation merely restates the schema.

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

Purpose4/5

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

States a specific verb and resource ('Rent-a-Bot: hire', 'rent a listed bot') and ties the input to rent_list. It does not distinguish this tool from other renting-shaped siblings such as rent_borrow or rent_house_pool, so an agent must infer which hire path applies.

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 an explicit WHEN clause and a full lifecycle: call this, then rent_status, finish with rent_end. It also states the prerequisite ('Registered key required', guest keys cannot rent). No explicit when-not guidance or comparison against alternative rental siblings.

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

All Dead Brands Bot Arena 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?