Official Model Context Protocol server for otwa.cloud — provision and manage servers from Claude Code, Claude Desktop, Cursor, Windsurf, VS Code, Zed, Continue, OpenCode and other MCP-capable AI tools.
Strong foundation with 22 well-named tools following verb_noun convention (list_, get_, create_, purchase_, remove_, set_, delete_). All tools have descriptions (avg 180 chars, within 10-1024 baseline). Input schemas present and typed with Zod. Critical gaps: output schemas undocumented (no return type specs visible), parameter descriptions vary in quality (some excellent like otwa_create_server, others minimal), and error handling lacks recovery guidance. Missing tool annotations (readOnlyHint, destructiveHint, idempotentHint). Composition is strong, tools chain well (list_servers → get_server → get_server_credentials). Security-conscious: credentials never exposed as params, sensitive operations documented.
Returns the authenticated user account: id, email, name, balance, tier, signup date. Call this first to confirm which account the current API key belongs to before any other operation.
Creates and provisions a new server on otwa.cloud. The customer is billed immediately for the first month — quote the monthly price from otwa_list_products and get explicit confirmation before calling. Always call otwa_list_products + otwa_list_os_templates first so productId, `os` and `osTemplate` come from the real catalogue, never guessed. EXCEPTION — capacity pools: pass `poolId` and the server is FREE. It is checked against the pool's quota instead of the wallet, is never charged and never renews, so there is no price to quote and no confirmation to collect. List pools with otwa_list_pools and check what still fits with otwa_get_pool (quota minus usage) before choosing a plan.
Removes the reverse DNS hostname for an IP, returning it to the otwa.cloud default.
Returns the full invoice including line items, taxes, and payment status.
Returns full detail for a server: status, specs (vCPU/RAM/disk/bandwidth), region, OS, primary IP, gateway, and any additional IPs. Always call this before any destructive operation so the user can confirm against the current label.
Output schemas not documented. No return type specifications visible in tool definitions. LLMs cannot plan downstream calls or extract required fields without knowing response structure.
Tool annotations missing. No readOnlyHint, destructiveHint, or idempotentHint declarations. Agents cannot distinguish safe reads from destructive writes without parsing descriptions.
Error handling lacks recovery guidance. No actionable error messages visible (e.g., 'pool has no room left' should suggest otwa_get_pool). Agents cannot self-correct on failures.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | 2026-07-28+ | v2 |
Returns the login credentials for a server: Linux gives a root SSH login; Windows gives an RDP login whose admin username is per-template (Administrator on Windows Server, OtwaCloud on Windows 11) — use the returned `username` field. SENSITIVE — never paste the password into a chat transcript; instead summarise that credentials are available and offer to open the dashboard via otwa_get_dashboard_sso.
Returns a server's power state plus the latest CPU / RAM / disk / network metrics. Numbers come from vSphere and are seconds-fresh. `powerState` is always present for a provisioned server; the `live` metrics block is null when the guest agent (VMware Tools) is quiet — that means "running, no telemetry", not offline. A stopped server returns powerState POWERED_OFF with live null.
Returns the on-chain wallets the account holds, with chain, address, and balance. The address can be shared with the user to top up. Read-only — does not create new addresses.
Returns every add-on offered by this server's plan — extra IPs, /24 class blocks, the SEO IP Pack (7 dedicated IPs each from a DIFFERENT /24, for SEO hosting and sender-reputation isolation), and backups. Each entry carries id, name, type, `price` (what this API key is charged monthly, reseller discount already applied), `retailPrice`, `proratedPrice` (charged immediately, based on days left in the cycle), `owned`, and `ownedByType`. ONLY ONE add-on per type can be active at a time, so treat `ownedByType: true` as "not orderable until the current one is removed". Stock-limited add-ons (the SEO IP Pack) also carry `available` and a `stockNote`. Featured add-ons come first. Use these ids with otwa_purchase_addon, otwa_remove_addon, or the `addons` array of otwa_create_server.
Returns paged invoice history (most recent first). Each entry has id, invoiceNumber, total, status (paid/open/void), and creation date. Use otwa_get_invoice for line-item detail.
Returns the catalogue of ready-to-boot custom ISO images (e.g. MikroTik RouterOS, FreeBSD). To deploy one, call otwa_create_server with `os: "custom-iso"` and `osTemplate` set to the ISO `id` returned here. Only fully-uploaded images are listed.
Returns the catalogue of OS images available for new servers and reinstalls. Each entry has `id` (use as `osTemplate`), `family` (use as `os` — Ubuntu, Debian, Rocky, etc.) and `label`. Always call this before otwa_create_server so you pick a real template id, never a guessed string.
Returns the plans this server can switch to — plans in the SAME product family with the SAME disk size (a plan change never alters disk). Response has `current` (the active plan) and `options` (switchable plans, cheapest first) each with id/name/vcpu/ramMb/diskGb/monthlyPrice. Pass an option `id` to otwa_change_server_plan. Empty `options` means the server has no same-disk plans to move to (only the Cloud Router S/M/L line supports this today).
Returns every server plan available to the current account, including CPU, RAM, disk, bandwidth, monthly price, and the productId UUID required to call otwa_create_server. Resellers see wholesale prices.
Returns the list of regions where new servers can be deployed. Use the `slug` value as the `region` argument to otwa_create_server. Most accounts can omit region — the platform picks one based on product availability — but specifying a region pins the deploy location.
Returns every IP attached to a server (primary + additional), with gateway, netmask, CIDR, and current PTR (reverse DNS).
Returns every server the account owns, with id, label, status, region, primary IP, and any additional IPs. Use the `id` field as input to per-server tools.
Returns the point-in-time disk snapshots for a server: id, name, createTime, power state when taken, and whether it's the current one. Pass a snapshot `id` to otwa_revert_snapshot or otwa_delete_snapshot.
Returns paged transaction history. Distinct from invoices — invoices are the document, transactions are the money movements (Stripe charges, crypto deposits, balance adjustments).
Attaches an add-on to an already-running server. The prorated amount is charged to the wallet IMMEDIATELY and the full monthly price joins every future renewal — call otwa_list_addons first and show the user both numbers before confirming. For IP add-ons the addresses are routed to the VM but the customer must configure them inside the guest OS themselves. The SEO IP Pack allocates 7 IPs each from a different /24 and fails with 400 if distinct-subnet stock is short. Also 400s when an add-on of the same type is already active (remove it first via otwa_remove_addon) or the wallet balance is insufficient.
Cancels an active add-on: its price leaves the recurring total from the NEXT renewal onward. There is NO prorated refund for the current cycle. For IP add-ons this is disruptive and immediate — the addresses are released back to the pool and stop routing to the VM at once, so anything bound to them in the guest OS (sites, SSL, mail) breaks. Tell the user to unconfigure them first. Use the add-on id from otwa_list_addons or the server's own metadata.
Sets the reverse DNS hostname for an IP attached to a server. Changes propagate to PowerDNS within seconds. Useful for mail servers and anything that needs forward-confirmed reverse DNS.
Pagination not visible in list tools. otwa_list_servers, otwa_list_invoices, otwa_list_transactions accept page/limit but no total count or next_cursor documented. Large result sets risk context window exhaustion.
Parameter descriptions inconsistent in detail. otwa_create_server has excellent descriptions (e.g., poolId, ipCount with warnings); otwa_account has none. Agents struggle with underspecified params like 'id' across tools.