The default endpoint is Kilawatt Cloud's gateway: https://www.kilawattcloud.dev/api/public/v1.
Model Context Protocol (MCP) server for Kilawatt Cloud GPU provisioning. Enables Cursor, Claude Desktop, and other AI agents to programmatically request and manage real GPU compute nodes.
This server calls the real Kilawatt gateways. Every response is an actual HTTP result from the Kilawatt public API or the x402 endpoint. There are no fabricated responses.
goose
Claude Desktop
Cursor
Using goose? Follow the step-by-step guide: docs/GOOSE_TUTORIAL.md
Related MCP server: clausius
The default endpoint is Kilawatt Cloud's gateway: https://www.kilawattcloud.dev/api/public/v1. Change it with the KILAWATT_BASE_URL environment variable.
Install and run via npx:
npx -y kilawatt-mcp-serverSet your Kilawatt API key to use deploy_gpu_node. It is not required to start the server or use the x402 tools:
export KILAWATT_API_KEY=kw_live_YOUR_KEY_HEREThe API key must start with kw_live_. API keys are issued through your Kilawatt Cloud account. Contact hello@kilawattcloud.dev for assistance if you don't have access to generate keys yet.
Add this configuration to your MCP client settings:
{
"mcpServers": {
"kilawatt": {
"command": "npx",
"args": ["-y", "kilawatt-mcp-server"],
"env": {
"KILAWATT_API_KEY": "kw_live_YOUR_KEY_HERE"
}
}
}
}Replace kw_live_YOUR_KEY_HERE with your Kilawatt API key when using deploy_gpu_node. For x402-only use, omit KILAWATT_API_KEY.
Using goose? See GOOSE.md.
Start the MCP server:
npm startOr directly:
node index.jsThe server listens on stdio for MCP requests from your agent.
deploy_gpu_nodeProvision real GPU compute on Kilawatt Cloud. This starts an actual machine. Set dry_run: true to check pricing and routing without provisioning or charging.
Parameters:
Parameter | Type | Required | Default | Range | Description |
| string | No | server default | N/A | GPU model identifier supported by the endpoint |
| integer | No |
| 1–64 | Number of GPUs to provision |
| number | No |
| 1-86400 | How long the node is needed, in seconds. Billed up front. |
| string | No |
|
| How the smart order router picks a node |
| boolean | No |
| N/A | Price and pre-authorize only. Returns cost estimate and routing order without provisioning or charging. |
Example: Deploy 4 GPUs for 1 hour at lowest cost
{
"name": "deploy_gpu_node",
"arguments": {
"card_count": 4,
"duration_seconds": 3600,
"routing_policy": "lowest_cost",
"dry_run": false
}
}Example: Dry-run to check pricing
{
"name": "deploy_gpu_node",
"arguments": {
"card_count": 2,
"duration_seconds": 1800,
"dry_run": true
}
}Tool results are formatted from the real HTTP response returned by the Kilawatt gateway.
The x402 tools let you request capacity with Base USDC without a Kilawatt account or API key:
x402_quote checks the current price and payment details without paying.
x402_run_job quotes and pays for one GPU job. It requires confirm: true and a positive max_usd; payment is refused above that amount or either configured spend cap.
x402_job_status checks a paid job using the API key saved locally by x402_run_job.
The server must be able to read the following environment variables when you use x402 payments:
Variable | Purpose | Default |
| Base-compatible wallet key, needed only to pay with | Not set |
| Maximum price for one paid job |
|
| Maximum cumulative spend in this server process |
|
| Override the x402 execution endpoint | Kilawatt production endpoint |
The returned API key is stored at ~/.config/kilawatt/x402-api-key with restrictive file permissions. It is never shown in tool output. Existing deploy_gpu_node still requires KILAWATT_API_KEY.
Use a separate small wallet for x402, and keep its private key out of prompts and shared configuration. The payer does not need ETH; the facilitator submits the transaction.
For x402 users: Check that your Base wallet has enough USDC and that your spend caps allow the amount.
All errors are descriptive and indicate whether anything was provisioned or charged. Common scenarios:
400 Bad Request: Invalid arguments (e.g., card_count > 64). Fix and retry.
401 Unauthorized: API key missing, malformed, or revoked. Issue a new key in your Kilawatt account or contact hello@kilawattcloud.dev.
402 Payment Required: the payment was not accepted. Check your balance and spend caps, then retry.
429 Rate Limited: Concurrency or rate limit hit. Retry after a delay.
503 No Capacity: No nodes available matching your criteria. Try a different gpu_type or smaller card_count.
Timeout: Gateway did not respond within 60 seconds. No compute was provisioned; retry if needed.
npm Package: https://www.npmjs.com/package/kilawatt-mcp-server
GitHub Repository: https://github.com/KilaWattCloud/kilawatt-mcp-server
Kilawatt Cloud: https://kilawattcloud.dev
Model Context Protocol: https://modelcontextprotocol.io
MIT
Provision real GPU compute on Kilawatt Cloud. Charges the caller's Kilawatt wallet and starts an actual machine. Set dry_run to true to price the run and check balance, spend caps, rate limits and concurrency without provisioning or charging anything.
| Name | Required | Description | Default |
|---|---|---|---|
| dry_run | No | Price and pre-authorize only. Returns the cost estimate, the routing order and whether the account is authorized, without provisioning or charging. | |
| gpu_type | No | GPU model identifier, e.g. nvidia-h100, nvidia-h200, nvidia-b200. | nvidia-h100 |
| card_count | No | Number of GPUs to provision. | |
| routing_policy | No | How the smart order router picks a node. | lowest_cost |
| duration_seconds | No | How long the node is needed, in seconds. Billed up front. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses that this is a real, billable, mutating operation ('charges the caller's Kilawatt wallet and starts an actual machine') and details the dry-run safety valve. It stops short of stating failure/refund behavior, auth prerequisites, or what happens to the node when duration elapses.
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 tight sentences with zero waste; the provisional/billing nature and the dry-run escape hatch are both front-loaded where an agent will read them.
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?
Covers the critical facts for a 5-param, no-annotation, mutating tool: cost incurred, machine actually started, and a safe preview path. With no output schema present, it could say more about what a successful provision returns (node id, endpoint, expiry), which is the remaining gap.
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%, so every parameter already has documented meaning, including dry_run's pre-authorization semantics. The description reinforces dry_run's behavior but adds no syntax, format, or unit details beyond what the schema provides.
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 ('Provision') and resource ('real GPU compute on Kilawatt Cloud'), plus the side effects (charges the caller's wallet, starts an actual machine). An agent knows exactly what this tool does without opening the 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?
Explicitly tells the agent to set dry_run=true to price a run and check balance, spend caps, rate limits and concurrency without provisioning. That is clear usage context, but there are no alternatives or exclusion conditions (e.g. how to stop or resize an existing node).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the status of a job created through x402 using this server's locally saved API key.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses the auth mechanism ('this server's locally saved API key'), which is real added context, but says nothing about whether the call is read-only, rate limits, error behavior, or what the status payload contains.
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 with no filler; every clause (verb, resource, provenance, auth) earns its place. Nothing is repeated or padded.
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 and no annotations, so the description is the only source of information about what a 'status' result looks like or what states exist. For a 1-param polling tool it should say more about the returned status values and error cases; it omits both.
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 0% and the single job_id parameter is undocumented in the schema. The description partially compensates by scoping job_id to 'a job created through x402' via this server, telling the agent which job namespace is valid, but adds no format or constraint detail.
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 ('Get the status of a job'), which is unambiguous against siblings like x402_run_job (which runs a job) and x402_quote. It does not explicitly name or contrast with those siblings, so it falls just short of a 5.
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 phrase 'a job created through x402' implies this is a follow-up/polling call after job submission, but it never states when to use it versus x402_run_job or x402_quote, nor any preconditions. Usage is inferable but not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current price and Base USDC payment details for a GPU job without paying.
| Name | Required | Description | Default |
|---|---|---|---|
| gpu_type | No | nvidia-h100 | |
| card_count | No | ||
| workload_type | No | ||
| routing_policy | No | ||
| duration_seconds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. 'Without paying' discloses one important trait (no charge is incurred) and 'current' hints at dynamic pricing, but nothing is said about whether a quote reserves capacity, whether it expires, what permissions are needed, or the 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?
A single front-loaded sentence with zero filler that states the purpose, the key non-charging behavior, and the payment context in one pass.
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 5-parameter tool with no annotations and no output schema, the description omits the parameter meanings and the return contents that an agent would need. It adequately conveys only the top-level purpose, leaving significant gaps for correct invocation.
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?
Five parameters exist with 0% schema description coverage and three enums whose meanings (routing_policy, workload_type, duration_seconds, gpu_type) are entirely unexplained. The description adds no parameter meaning at all, so it fails to compensate for the coverage gap.
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 a specific verb ('Get'), resource ('current price and Base USDC payment details'), and scope ('for a GPU job'). The phrase 'without paying' implicitly contrasts it with x402_run_job, so an agent can roughly distinguish it from the paying sibling, though no sibling is named 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?
'Without paying' implies this is a pre-payment preview step, so usage is inferable, but there is no explicit when-to-use statement, no direction to call this before x402_run_job, and no prerequisites or exclusions. The routing to alternatives is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Quote and, only with confirm=true and all spend caps passing, pay for one GPU job in Base USDC.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | Yes | ||
| max_usd | Yes | ||
| gpu_type | No | nvidia-h100 | |
| card_count | No | ||
| workload_type | No | ||
| routing_policy | No | ||
| duration_seconds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose a meaningful safety gate: payment is conditional on confirm=true and passing spend caps, and settlement is in Base USDC. It still omits failure/refund semantics, idempotency, and whether confirm=false returns a quote, which matters for a financial mutation.
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 dense sentence with the action and its safety condition front-loaded, no filler. The interposed 'only with confirm=true and all spend caps passing' clause slightly disrupts flow but is well placed as a guard on the pay verb.
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 7-parameter financial mutation with no annotations and no output schema, the description is too thin: it never explains the quote-then-pay return shape, what happens when confirm=false, or how the six optional parameters affect the job. An agent cannot confidently invoke it beyond the happy path.
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 0% across 7 parameters, so the description must compensate and largely does not. It only gestures at confirm and the spend cap (max_usd); gpu_type, card_count, workload_type, routing_policy, and duration_seconds are entirely unexplained in both schema and 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 names a specific verb pair (quote and pay) and a specific resource (one GPU job) with the payment currency (Base USDC), so the agent knows this is the execution/payment step of the x402 flow. It does not explicitly differentiate itself from x402_quote, which creates mild ambiguity about whether quoting also happens here.
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 states the precondition for the payment leg ('only with confirm=true and all spend caps passing'), which is genuine usage guidance. However, it never says when to prefer this tool over x402_quote or x402_job_status, so the routing decision is left implied.
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.
v0.2.1x402_job_statusx402_quotex402_run_jobv0.1.2deploy_gpu_nodeScored across 4 tools
The x402 trio (quote/run_job/status) has a clear preview-pay-check progression, but deploy_gpu_node overlaps heavily with x402_run_job since both provision GPU compute and charge the caller, and both support a dry-run/quote mode that echoes x402_quote. An agent could reasonably misselect between the Kilawatt-wallet path and the Base USDC x402 path.
Three tools use a consistent x402_ prefix while deploy_gpu_node stands alone, and the verb/noun ordering varies across the set (x402_quote vs x402_job_status vs x402_run_job). It remains readable but the convention is not uniform.
Four tools is on the lean side but fits the narrow domain of quoting, paying for, provisioning, and checking a single GPU job. Each tool maps to a distinct step in that lifecycle with little redundancy.
The quote/pay/status/deploy lifecycle is covered, but there is no cancel, refund, list-jobs, or log/result-retrieval operation, so an agent facing a failed or stuck job has limited recourse. The two parallel execution paths (x402 vs Kilawatt) also leave ambiguous ownership of follow-up operations.
Massed Compute MCP — GPU inventory, VM lifecycle, billing, SSH keys, and setup recipes.
HiveCompute MCP Server — decentralized inference router for AI agents
Protocol-native energy infrastructure orchestration for AI data centers. Provides 46 MCP tools across 8 grid protocols (IEC-61850, DNP3, Modbus, OCPP, OpenADR, IEEE 2030.5, IEC 60870-5-104, ICCP) with 5 core API primitives: connect, dispatch, settle, comply, and intel. Enables AI agents to programmatically interact with substations, grid interfaces, and energy assets for real-time workload-grid coordination.
MCP server connecting AI agents to non-custodial staking data across 130+ networks.
