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 gateway — every response is an actual HTTP result from https://www.kilawattcloud.dev/api/public/v1. There are no mock or fabricated responses.
Install via npm:
npm install kilawatt-mcp-serverRelated MCP server: clausius
Set your Kilawatt API key as an environment variable before running the server:
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.
Optionally, override the gateway URL:
export KILAWATT_BASE_URL=https://www.kilawattcloud.dev/api/public/v1Start 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 immediately charges the caller's Kilawatt wallet and starts an actual machine. Set dry_run: true to validate pricing, routing, and account balance without provisioning.
Parameters:
Parameter | Type | Required | Default | Range | Description |
| string | No |
| — | GPU model identifier, e.g. |
| 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 |
| — | Price and pre-authorize only. Returns cost estimate and routing order without provisioning or charging. |
Example: Deploy 4 H100 GPUs for 1 hour at lowest cost
{
"name": "deploy_gpu_node",
"arguments": {
"gpu_type": "nvidia-h100",
"card_count": 4,
"duration_seconds": 3600,
"routing_policy": "lowest_cost",
"dry_run": false
}
}Example: Dry-run to check pricing
{
"name": "deploy_gpu_node",
"arguments": {
"gpu_type": "nvidia-b200",
"card_count": 2,
"duration_seconds": 1800,
"dry_run": true
}
}Response (Success):
GPU node running. Job ID: job_abc123xyz
Node: provider-name
Hardware: 4× nvidia-h100
Workload: default Routing policy: lowest_cost
Billed: $12.3456
Status: runningResponse (Dry Run):
DRY RUN — nothing was provisioned and nothing was charged.
Authorized: yes
Estimated cost: $6.1728 for 2× nvidia-b200
Routing policy: lowest_cost
Would route through (in order): provider-a → provider-b → provider-cAll 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: Insufficient balance or spend cap. Top up in the Kilawatt wallet.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.2deploy_gpu_nodeScored across 1 tool
There is only one tool, deploy_gpu_node, so there is no possibility of confusing it with another tool. Its purpose is clearly provisioning GPU compute on Kilawatt Cloud.
The single tool name deploy_gpu_node uses a clear snake_case verb_noun pattern. With only one tool, there is no inconsistency across the set.
A single tool is borderline thin for a cloud provisioning server, even though the tool itself is substantial. The rubric treats 1-2 tools as borderline, so it is not clearly well-scoped or clearly mismatched.
The surface only covers provisioning/deployment via deploy_gpu_node. There are no tools to list, inspect, update, stop, or terminate existing GPU nodes, leaving significant lifecycle gaps for agents managing real infrastructure.
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.
