Rent GPUs at live prices and serve any Hugging Face model, with spend caps for AI agents.
Scored across 13 tools
Most tools have clearly distinct targets: search_gpus finds machines, rent_gpu rents one, deploy_model serves a model, and the get_/list_ family reads state without side effects. The main overlaps are rent_gpu vs deploy_model (both rent a money-costing machine) and search_gpus vs get_market_summary (both report live prices), but the descriptions draw the boundary clearly enough (per-machine rows vs per-family summary; plain machine vs model-serving endpoint).
Every tool is snake_case verb_noun: get_balance, get_events, get_instance, get_market_summary, get_partner_earnings, list_images, list_instances, rent_gpu, search_gpus, deploy_model, schedule_removal, terminate_instance, join_partner_program. The verbs are used consistently by intent (get = read one/aggregate, list = enumerate, search = query market, terminate/schedule = mutate lifecycle).
13 tools is well within the sweet spot and each maps to a real workflow step: market discovery, rental, lifecycle control, balance/events monitoring, model deployment, and the partner program. No filler tools and no obvious grouping that should have been collapsed.
The core rental lifecycle (search_gpus → rent_gpu → get_instance/list_instances → schedule_removal → terminate_instance) plus deploy_model, balance, events, and images is fully covered with no dead ends. Minor gaps: rent_gpu references ssh_key_id and 'the account's first SSH key' but there is no tool to list/create SSH keys, list_images mentions account-saved images with no tool to save one, and there is no way to inspect logs or adjust auto-recharge/spend caps.
Serve any model from Hugging Face on a machine of the person's, like a hosted inference API but on their own GPU: vLLM or SGLang for text models, vLLM-Omni or SGLang for image and video models (FLUX, Qwen-Image, Wan), vLLM-Omni for speech and music, llama.cpp for a GGUF file (owner/repo:Q4_K_M). extra_args takes the person's own engine options as they'd paste them. COSTS MONEY like rent_gpu: the machine's hourly price, paid an hour at a time from when it runs until terminate_instance or termination_hours; worst_case_usd is the most it can cost. The model's size is read from Hugging Face and, without node_id, the best-ranked clean machine that holds it is rented on as few GPUs as it allows. A gated or private model needs hf_token (read access is enough; it goes to the machine only and Arrakis keeps none). Returns the instance, the endpoint (an OpenAI-compatible base URL once RUNNING, and its api_key) and ssh_command: the person also gets root SSH. The engine downloads the model first, so it answers a few minutes after RUNNING: get_instance shows endpoint_ready. Same idempotency_key returns the same machine.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | A name you will recognise. | |
| model | Yes | A Hugging Face model id or link, for example Qwen/Qwen3-8B; for llama.cpp, owner/repo:QUANT picks one GGUF file. | |
| engine | No | Default vllm. omni = vLLM-Omni (image, video, speech, audio). | |
| node_id | No | A machine from search_gpus. Default: the one sized for the model. | |
| hf_token | No | A Hugging Face token, for a gated or private model. | |
| gpu_count | No | GPUs of it to rent. Default: the fewest that hold the model. | |
| extra_args | No | The person's own engine options, as they'd paste them: flags, the whole command, or a docker run line (--max-model-len 32768). Read without a shell; the address, key and model stay Arrakis's. | |
| ssh_public_key | No | Your SSH public key. Default: the account's first saved key. | |
| idempotency_key | No | Reuse when retrying. | |
| termination_hours | Yes | Hours until the machine is removed automatically. | |
| max_price_per_gpu_hour | No | The most to pay per GPU-hour (USD). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: it discloses that the call spends money hourly until terminate_instance or termination_hours, explains worst_case_usd, notes the engine downloads the model so the endpoint answers only minutes after RUNNING, points at get_instance/endpoint_ready, and states hf_token is never retained. The idempotency contract (same key returns the same machine) reinforces idempotentHint=true with concrete semantics. No contradiction with readOnlyHint=false/destructiveHint=false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core purpose and every clause carries information, but it is delivered as one dense run-on block with heavy punctuation, making the billing, token-handling and readiness facts hard to scan. Splitting the cost and return-value details into their own sentences would cost nothing and gain legibility.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Eleven parameters, no output schema — yet the description covers returns (instance, OpenAI-compatible endpoint plus api_key, ssh_command), the cost model, failure/readiness timing, and idempotency. An agent has everything needed to call it correctly and to know what it will be billed and given back.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3; the description still adds meaning the schema lacks — the engine-to-modality mapping across sglang/omni/llamacpp, the default node sizing logic when node_id is omitted, that gpu_count defaults to the fewest that hold the model, and how extra_args is parsed (flags, whole command, or docker run line, read without a shell, address/key/model withheld). Some items like the GGUF quant syntax merely repeat the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (serve a Hugging Face model on the person's own GPU) and immediately scopes the variants by modality (vLLM/SGLang for text, vLLM-Omni for image/video/speech, llama.cpp for GGUF). It also differentiates itself from the sibling rent_gpu by explicitly saying it costs money 'like rent_gpu', so the agent can tell the two apart without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear conditions: gated/private models need hf_token, GGUF needs the owner/repo:Q4_K_M form, without node_id the best-ranked clean machine is auto-picked. It references rent_gpu for the cost model and get_instance for readiness, but never states plainly when to choose this over plain rent_gpu (i.e. when you want a model served rather than a bare box).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The account balance (what it can pay now, what the running machines cost per hour, when the money runs out, whether rentals are paused and whether auto-recharge tops it up from a saved card) and this token's spend cap: the limit, what is committed, what is left, the longest rental allowed and when the token expires. Call it before long jobs and whenever an alert mentions the balance. Free; changes nothing.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, idempotent, non-destructive, and openWorld behavior, so the description is not carrying the full safety burden. It adds useful behavioral context by stating the call is 'Free' and 'changes nothing,' and it discloses the information returned, though it does not discuss auth, rate limits, or response shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense but purposeful sentences. The primary content is front-loaded in the first sentence, and the second sentence adds only actionable usage guidance and a cost/side-effect note, with no wasted prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no parameters, the description must explain what the call returns and when to use it. It does both in detail, covering account balance fields, spend cap fields, pause state, auto-recharge, and token expiry, which is enough for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. There is no parameter meaning to explain, and the description correctly does not fabricate any input semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pairing and enumerates exactly what the balance and spend-cap result contains: payable balance, running machine cost, runway, pause status, auto-recharge, cap limit, committed amount, remaining amount, longest rental, and token expiry. This clearly distinguishes it from every sibling tool, which are deployment, rental, listing, event, and market tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit usage context: 'Call it before long jobs and whenever an alert mentions the balance.' It does not name alternatives or when-not conditions, but there is no sibling tool that overlaps with balance/spend-cap checking, so the guidance is clear without needing exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Events on your machines, newest first: machine.ready (with its SSH command), machine.ended (reason says why: evicted when its host took it back or stopped working, otherwise stopped, removal_time, out_of_funds, paused or failed) and machine.notice (its host will take it back or restart it at notice_at, stopped answering, or it failed). Check it when a machine stops answering, and after any alert on a tool result. Free; changes nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Default 20. | |
| since | No | Only events after this ISO 8601 time. Default: 30 days. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and non-destructive, so 'Free; changes nothing' is largely confirmatory, but the description adds real behavioral content the schema does not: newest-first ordering and the meaning of each machine.ended reason (evicted vs stopped, out_of_funds, paused, failed). It does not mention retention or result-size behavior beyond the default window.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads what it is, then conditions, then cost. The middle sentence is a dense run-on with nested parentheticals, but nearly every clause carries event-type semantics that the agent needs given there is no output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must carry return-value meaning, and it does by explaining all three event types and their failure reasons. Pagination and the 30-day default window are left to the schema, which is acceptable; nothing an agent needs to call it is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and both parameters (limit, since) already document their defaults and ISO 8601 format. The description adds no syntax, bounds or semantics beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific resource and ordering: 'Events on your machines, newest first', then enumerates the three event kinds and what each carries. It clearly differs from siblings like list_instances or get_instance, though it never names an alternative explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Check it when a machine stops answering, and after any alert on a tool result' gives concrete trigger conditions an agent can act on. It stops short of exclusions or naming the sibling (get_instance) that covers a still-running machine, so it is clear context rather than full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One machine now: state (PENDING or PROVISIONING while it boots, which is free; RUNNING when ssh_command works; then TERMINATED or FAILED), price per hour, ssh_command, removed_by, any notice from its host (host_notice and host_notice_at, host_down_since) and, once it ended, ended_reason (evicted when its host took it back). After rent_gpu, call it every 30-60 seconds until RUNNING. Free; changes nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| instance_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite annotations already covering read-only, idempotent, non-destructive behavior, the description adds substantial context: boot states are free, RUNNING is tied to ssh_command working, host notices and host_down_since are surfaced, ended_reason can indicate eviction, and polling cadence is specified. It also explicitly says the call is free and changes nothing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but largely front-loaded and information-rich, with no filler. It is somewhat run-on and packs state semantics, return fields, polling guidance, and billing behavior into a single paragraph, which slightly hurts readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and a complex instance lifecycle, the description does a strong job explaining returned fields and state meanings. The main gap is the lack of explicit instance_id semantics, but otherwise an agent has enough context to call and interpret this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one required parameter, instance_id, and schema description coverage is 0%. The description does not define the ID format or where to obtain it, though 'One machine now' and the rent_gpu workflow imply it identifies a rented instance. The parameter name is self-explanatory, making this minimally viable rather than undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly frames this as retrieving the current status/details of a single machine, and it enumerates the returned state fields, pricing, SSH command, host notices, and termination reason. It does not explicitly name or contrast with siblings such as list_instances, so it stops short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a concrete usage pattern: after rent_gpu, call every 30-60 seconds until RUNNING. That is strong context, but it does not explicitly state when to prefer this over list_instances or other siblings for broader inspection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Live market summary by GPU family: cheapest price per GPU-hour, GPUs available and machines. Free; needs no token; changes nothing.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description adds context beyond them: it is free, requires no token (auth requirement), and 'changes nothing' (side-effect confirmation). It does not mention rate limits or freshness/latency guarantees of the 'live' data, so it falls short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single compact sentence that front-loads the scope ('by GPU family') and the returned fields, then closes with cost/auth/side-effect facts. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-param tool with no output schema, the description enumerates the key return fields well enough to plan a call. It omits output shape/ordering details, but that is a minor gap given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters with full schema coverage, so there is nothing for the description to disambiguate. Baseline 4 applies; the description correctly signals a parameterless call by not implying filters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Live market summary by GPU family') and names the returned metrics: cheapest price per GPU-hour, GPUs available, machines. An agent can tell it is an aggregate market view rather than a per-item query, though it does not explicitly contrast with siblings like search_gpus or list_instances.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Live market summary' implies when it is useful (current pricing/availability overview), but there is no explicit when-to-use vs when-not, nor any pointer to search_gpus or list_instances for per-GPU detail. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
For partners (agents and people who bring customers to Arrakis): your partner codes with the link and a message to share, what each earns you (a share of what the customers you bring pay), the customers your codes brought (each with what they paid and earned you, and your link tag; never who they are), what you have earned, what is pending until those payments reach Arrakis or held before a cash-out, what you can cash out or move to your balance, any sales target with its progress, and whether the partner program is open to join. Free; changes nothing. Wherever you recommend Arrakis, say that you earn from referrals (the partner terms). Needs a token with the billing scope.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already cover read-only, idempotent, non-destructive behavior, but the description adds substantial context: it is free, changes nothing, requires a billing-scoped token, hides customer identity, and includes referral-disclosure obligations. It also explains pending versus cash-out/balance states, which goes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description front-loads the audience and then compresses many return fields and caveats into a few dense sentences. It is somewhat run-on due to the long enumeration, but the content is relevant and avoids repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must explain what comes back. It does so comprehensively: partner codes, links/messages, per-customer earnings with privacy constraints, totals, pending amounts, cash-out/balance amounts, sales targets, and program status. It also covers auth scope and cost.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero input parameters, so the baseline is 4. The schema is fully described and there are no parameters whose meaning needs clarification in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource: partner codes, referral customers, earnings, pending amounts, cash-out/balance amounts, sales targets, and program status. It distinguishes the scope from a generic balance check by focusing on partner earnings and mentioning movement to balance, though it does not explicitly contrast itself with sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It establishes the audience ('For partners') and a prerequisite ('Needs a token with the billing scope'), which gives useful usage context. However, it does not explicitly say when to use this instead of get_balance or join_partner_program, and it mentions program-open status without routing the agent to join_partner_program for joining.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Join the Arrakis partner program and get your own partner code, link and a message to share. The account earns a share of what the customers it brings pay, as cash (paid through Stripe to the person or company you act for, once they set up payouts in the console) or Arrakis credit you can spend on GPUs. Only join if the person or company you act for agrees: joining accepts the partner terms (terms_url from get_partner_earnings) for them. Pass the terms_version you read. Free; joining again returns the same code. Add ?tag= to your link to tell your own channels apart. Needs a token with the billing scope.
| Name | Required | Description | Default |
|---|---|---|---|
| terms_version | Yes | The partner terms version you read (get_partner_earnings returns it). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations it discloses the legal consequence (joining accepts the partner terms on behalf of the entity), the payout mechanics (Stripe cash or Arrakis GPU credit, requiring payouts setup in console), and that re-joining returns the same code. It also documents the '?tag=' link convention, which no structured field covers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the benefit and the returned artifacts, then layers consent, terms, cost, and scope. It is dense but nearly every clause carries decision-relevant information; the Stripe/credit payout detail is the one passage that could be trimmed for an agent audience.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter mutation with no output schema, the description covers the return values (code, link, message), the consent/terms prerequisite, the auth scope, and idempotency. Nothing an agent needs in order to call it safely is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With one parameter at 100% schema coverage the baseline is 3, but the description reinforces the provenance of terms_version ('the terms_version you read', tied to get_partner_earnings) so the agent understands it must be fetched, not invented. It adds little else about the field's format, hence not a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Join the Arrakis partner program') plus the concrete artifacts produced ('your own partner code, link and a message to share'). This clearly separates it from the read-only sibling get_partner_earnings, which only reports earnings/terms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit gating condition ('Only join if the person or company you act for agrees'), a prerequisite chain ('Pass the terms_version you read', sourced from get_partner_earnings), and an auth requirement ('Needs a token with the billing scope'). It also notes the free/idempotent path so the agent knows re-joining is safe.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Images a machine can boot, for rent_gpu's template_id: the Arrakis images (PyTorch, CUDA toolkit, Ubuntu; SSH, login banner and tools built in) and the account's saved ones, with download size. Any other public image works through rent_gpu's image. Free; changes nothing.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so 'changes nothing' largely restates them; however, 'Free' adds billing context not captured by any annotation, and the enumeration of what the listing contains (Arrakis images with SSH/banner/tools, account-saved images, download sizes) tells the agent what it will actually see. No pagination or ordering behavior is disclosed, but with zero parameters that is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence identifies the resource immediately, then qualifies it. It is dense with nested parentheses (image contents, image-source split), which slightly hurts scannability, but no sentence is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no input parameters and no output schema, the description carries the burden of describing the return set and does so: two image categories plus download size. It omits any field-level detail (IDs, names, ordering) beyond size, which keeps it just short of fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes no parameters and the schema is fully described, so there is nothing for the description to disambiguate. Baseline 4 applies for a zero-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (lists bootable images) and then partitions the result set into Arrakis images vs. the account's saved images, with download size. It also names the sibling entry point (rent_gpu's template_id / image) that consumes the output, so an agent can place it precisely among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The mention that 'any other public image works through rent_gpu's image' routes the agent to the alternative when the desired image isn't listed, and the template_id framing implies this is the lookup step before rent_gpu. It stops short of an explicit 'call this before renting to obtain template_id' instruction or any when-not-to-use statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every machine on the account with its state, price per hour, SSH command, removal time and any notice from its host. Check it at the start of a session: a machine left running keeps billing until its removal time. Free; changes nothing.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description still adds genuine value beyond them: the billing consequence of leaving a machine running until its removal time, plus "Free; changes nothing," which tells the agent there is no cost or side effect in polling it often.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences: the first front-loads what comes back, the second front-loads the reason to call it. No filler, and the fragments "Free; changes nothing" carry real information rather than padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and no output schema, the description carries the burden of describing returns, and it does — state, price per hour, SSH command, removal time, host notice. It also closes the loop on the cost model, which is the one thing an agent could get wrong about a free read on a billing resource.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline applies. The description correctly spends no words on arguments and instead describes the result shape.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource and its scope precisely — "Every machine on the account" — and enumerates what each entry carries (state, price/hour, SSH command, removal time, host notice), which cleanly implies the list-all behavior in contrast to the singular get_instance. The only shortfall is that the verb is implicit and no sibling is named outright, so differentiation relies on the agent inferring singular vs. plural from the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Check it at the start of a session" gives an explicit trigger condition, and the billing rationale explains why. It stops short of naming alternatives (e.g., use get_instance for one machine, list_images before renting), so the when-not guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rent one machine found by search_gpus. COSTS MONEY: price per GPU-hour x GPUs, paid an hour at a time from when it starts running (booting is free) until terminate_instance or termination_hours, whichever comes first; worst_case_usd in the result is the most it can cost, and balance_covers_hours says how many hours the balance pays. It rents every GPU on the machine unless gpu_count says fewer (only some hosts allow that). Pass max_price_per_gpu_hour, normally the price search_gpus showed: if the live price is higher nothing is rented and the error gives the new price. Spot machines can be taken back by their host at any time. Boots the Arrakis PyTorch image unless template_id (list_images) or a public image is given; uses ssh_public_key, else ssh_key_id, else the account's first SSH key. Returns instance_id, state, the locked price, worst_case_usd and what to do next. Calling again with the same idempotency_key, or the same node_id and name within 10 minutes, returns the same machine instead of renting a second; use a new name for a second machine.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | A name you will recognise. | |
| image | No | Or any public image as docker pull takes it, e.g. vllm/vllm-openai:v0.11.0 or nvcr.io/nvidia/pytorch:25.01-py3 (x86-64). Checked with its registry before anything is charged. Not with template_id. | |
| start | No | With image: idle (default) keeps the machine waiting for SSH; image runs the image's own command (server images such as vLLM). Reach a server with ssh -L 8000:localhost:8000. | |
| node_id | Yes | node_id from search_gpus. | |
| gpu_count | No | GPUs to rent on that machine. Default: all of them (the whole machine); fewer works only on hosts that allow splitting. | |
| ssh_key_id | No | Id of an SSH key saved on the account. | |
| template_id | No | Image to boot: an id from list_images. Default: the Arrakis PyTorch image (SSH, login banner and tools built in). | |
| ssh_public_key | No | Your SSH public key, for example the contents of ~/.ssh/id_ed25519.pub. | |
| idempotency_key | No | Reuse when retrying. | |
| termination_hours | Yes | Hours until the machine is removed automatically. | |
| max_price_per_gpu_hour | No | The most to pay per GPU-hour (USD). If the live price is higher, nothing is rented. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare the safety profile (non-readonly, open-world, idempotent, non-destructive) but say nothing about cost, and the description carries that burden in detail: hourly per-GPU billing, booting free, billing from running until terminate_instance or termination_hours, worst_case_usd as the ceiling, balance_covers_hours, and spot preemption risk. It also discloses defaults and fallback order (Arrakis PyTorch image, ssh_public_key then ssh_key_id then account's first key) and the exact idempotency window (same key, or same node_id and name within 10 minutes).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and a capitalized COSTS MONEY warning, and nearly every clause carries distinct information (billing window, price guard, spot risk, image default, SSH key fallback, idempotency). It is a single dense paragraph though, and the cost/idempotency material would scan faster as separated sentences or bullets.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 11-parameter mutation with no output schema, the description covers everything an agent needs before spending money: cost model and ceiling, price-cap failure mode, spot risk, image and SSH defaults, idempotent retry semantics, and an explicit statement of what is returned (instance_id, state, locked price, worst_case_usd, next steps). Nothing material is left to inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 genuinely adds meaning: gpu_count defaults to the whole machine and only some hosts permit splitting, max_price_per_gpu_hour is framed as a guard rail whose violation returns the new price rather than renting, and the template_id/image/ssh-key parameters get a precedence order the schema only states per-field. It stops short of explaining termination_hours' interaction with billing beyond the stop-condition clause.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb and resource — 'Rent one machine found by search_gpus' — and explicitly anchors it to the sibling that produces the required node_id. An agent can distinguish this from search_gpus (discovery) and deploy_model (a different provisioning path) without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit prerequisite chain (search_gpus to get node_id and price), states that max_price_per_gpu_hour should normally be the price search_gpus showed and what happens if the live price exceeds it, and tells the agent how to rent a second machine (new name) versus retrying (same idempotency_key). It also names terminate_instance and termination_hours as the two stop conditions, which is when-to-use information for the lifecycle siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Change when a machine is removed automatically (ISO 8601, UTC). It bills until then, and removal deletes the machine and its disk. Use it to end a rental early when the job will finish sooner, or, with a token that has no spend cap, to extend a long run. A token with a spend cap can only move removal earlier.
| Name | Required | Description | Default |
|---|---|---|---|
| at | Yes | When to remove it, for example 2026-10-13T18:00:00Z. | |
| instance_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, so safety is structured. The description goes well beyond them by disclosing that billing continues until the scheduled time, that removal deletes both the machine and its disk, and that spend-capped tokens are restricted to moving removal earlier — consequences not derivable from any structured field.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the action and timestamp format, then consequences, then usage rules. No filler; every clause conveys something an agent would otherwise have to guess.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive, billed, open-world mutation with no output schema, the description covers cost accrual, what gets destroyed, idempotency implications, and the token-permission constraint on direction of change. Nothing material for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: the 'at' parameter is already documented with a date-time format and example, so the description's '(ISO 8601, UTC)' only adds a modest clarification. instance_id is never mentioned in the description, though its meaning is self-evident from the tool's context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action and resource — changing when a machine is removed automatically — with the key qualifier 'automatically' that separates it from an immediate termination. Combined with the billing and disk-deletion consequences, an agent can tell this apart from terminate_instance without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use cases: ending a rental early when the job finishes sooner, or extending a long run. It also names the condition that changes behavior — a token with a spend cap can only move removal earlier — which is exactly the routing rule an agent needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search GPU machines you can rent now at live prices: B300, B200, H200, RTX PRO 6000, RTX 5090, H100 and more. Free; changes nothing. Use it before rent_gpu and to answer what a GPU costs right now. Rows come best first: what the GPU can do (capability, H100 = 1.0), its price and how reliable its host is, with badges saying why (Reliable host, NVLink, or a warning such as a host taking it back soon); sort=price lists the cheapest first. pick is the first row with the reason, cheapest the lowest whole-machine price. Each row has node_id (for rent_gpu), gpu, gpu_count (rent_gpu rents all of them unless gpu_count says fewer; max_gpus 1 finds single-GPU machines), vram_gb per GPU, price_per_gpu_hour_usd, price_per_hour_usd for the whole machine, CPUs (and cpu, the model), RAM, disk, location, tier and network. Badges also say when renters rate a host low, it often fails to start or its GPUs are slow next to the same GPU elsewhere. Tiers: on_demand runs until its removal time; spot costs less but its host can take it back at any time, so use it only for work that saves checkpoints off the machine. Prices can move within a minute: pass the row's price to rent_gpu as max_price_per_gpu_hour. For multi-machine training add min_nic_gbps 400 and min_nics_per_gpu 1; null network fields were not reported.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | recommended (default), price (cheapest first), value (capability per dollar on a trusted host) or capability (fastest GPU first). | |
| tier | No | Only this tier. Default: all. | |
| limit | No | ||
| country | No | Two-letter country code, for example US or DE. | |
| gpu_type | No | GPU family, for example H100. | |
| max_gpus | No | Only machines with at most this many GPUs; 1 for a single-GPU job. | |
| min_gpus | No | Only machines with at least this many GPUs. | |
| nic_type | No | Only this NIC type. | |
| min_vram_gb | No | Only GPUs with at least this much memory each. | |
| min_nic_gbps | No | RDMA NICs at least this fast, Gb/s (400, 800). | |
| gpudirect_rdma | No | true: only machines whose market reports GPUDirect RDMA. | |
| min_nics_per_gpu | No | RDMA NICs per GPU; 1 = one NIC per GPU. | |
| max_price_per_gpu_hour | No | Price ceiling in USD per GPU-hour. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations establish the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description goes well beyond them: prices can move within a minute, spot hosts can reclaim machines so checkpoints must be saved off-box, null network fields mean 'not reported', and badges warn about unreliable or slow hosts. That is exactly the operational context an agent needs to act safely.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and the call-before-rent rule are front-loaded, and almost every clause carries information. It is still a dense, semicolon-chained block, and the long enumeration of row fields (CPUs, cpu model, RAM, disk, location, tier, network) is tedious even though there is no output schema to carry it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 13-parameter, zero-required tool with no output schema, the description covers result ordering, badge meanings, tier risk, price volatility and the multi-machine recipe. Minor gaps remain: the default limit of 10 / max 50 and the fact that results are paged are left entirely to the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 92%, so the schema carries most of the load, yet the description adds cross-tool meaning the schema cannot: node_id feeds rent_gpu, gpu_count determines how many GPUs rent_gpu takes, max_gpus 1 finds single-GPU machines, and a row's price should be passed back as max_price_per_gpu_hour. It adds little to the enum filters themselves, which the schema already documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Starts with a concrete verb and resource ('Search GPU machines you can rent now at live prices') and enumerates the GPU families covered, so the agent knows exactly which results to expect. It is clearly distinguishable from rent_gpu, which it explicitly names as the downstream action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit sequencing rule ('Use it before rent_gpu and to answer what a GPU costs right now') and a scenario-specific recipe ('For multi-machine training add min_nic_gbps 400 and min_nics_per_gpu 1'). It also implicitly excludes itself from mutating flows by noting it is free and changes nothing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop a machine now and delete it with everything on its disk; billing stops (the hour already started is paid). Copy results off first, for example with scp or rsync over its ssh_command. Cannot be undone; terminating a machine that already ended changes nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| instance_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description adds important behavioral details: all disk contents are deleted, billing stops except for the already-started hour, data should be copied off first, and the action is irreversible. It also reinforces idempotency by noting that terminating an already-ended machine changes nothing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core action and consequence. Every sentence adds useful operational context, including the billing caveat and the data-copy warning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive one-parameter tool with rich annotations and no output schema, the description covers the essential consequences: data loss, irreversibility, billing, and idempotency. The main remaining gap is the lack of explicit instance_id semantics or permission requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single required parameter is instance_id, but the description never explicitly explains it or its expected format. With 0% schema description coverage, the description only indirectly refers to 'a machine' and does not compensate for the missing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: stop a machine now and delete it with everything on disk. It is very clear about what the tool does, but it does not explicitly differentiate this from the sibling schedule_removal tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by saying to copy results off first with scp or rsync, and warns that the action cannot be undone. However, it does not explicitly say when to choose this tool over alternatives such as schedule_removal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
deploy_modelget_balanceget_eventsget_instanceget_market_summaryget_partner_earningsjoin_partner_programlist_imageslist_instancesrent_gpuschedule_removalsearch_gpusterminate_instanceRent cloud GPUs from AI agents: live prices, VRAM estimates, launch, logs and stop.
GPU cloud for AI agents: launch GPUs, run jobs that stop their own billing, schedule runs.
GPU compute for agents: run commands on an L4/A100/H100, watch logs, billed per second.
Cloud GPU prices with live stock from 22 providers. Find where to rent an H100 or B300 now.
Add one secure layer between your agents and this server.
