Loading ToolBench
MCP server for NordBastion — provision KYC-free, crypto-paid Nordic VPS & dedicated servers from any AI agent (Claude, Cursor, …).
Strong foundation with 28 well-named tools, comprehensive schemas, and clear descriptions. All tools follow verb_noun naming (register_, login_, create_, list_, get_, etc.). Input schemas are complete with proper JSON Schema types, enums, and constraints. Descriptions average ~120 chars, meeting the 10-1024 char baseline. However, parameter descriptions are sparse, most params lack inline guidance on format, range, or dependencies. Output schemas are not documented, forcing LLMs to infer response structure. Error handling is absent from tool definitions. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk stratification (READ_ONLY, WRITE, DESTRUCTIVE, REVERSIBLE). Security-sensitive tools (login, create_api_key, order_server) lack explicit permission/scope documentation in descriptions.
Add an SSH public key to a server.
Cancel (delete) a server immediately. Irreversible.
Cancel a still-open top-up.
Mint a long-lived scoped API key. Requires at least one confirmed top-up on the account. Plaintext returned ONCE.
Open a crypto invoice for an account top-up. The minimum is server-enforced (amounts below it return HTTP 422 `amount_too_low`). Returns wallet_address + QR + expiry. Poll `get_topup` until status is `confirmed`.
Return the current account (no secrets, no password hash).
Output schemas not documented. LLMs cannot infer response structure (fields, types, pagination). Forces agents to guess what data is returned and how to chain tools.
Parameter descriptions are minimal or absent. Most params lack guidance on format, range, or constraints. E.g., 'ip_allowlist' says 'Comma-separated CIDRs' but no example or validation rules. 'hostname' has no length/format constraints.
No tool annotations despite clear risk stratification. Tools marked DESTRUCTIVE (revoke_api_key, cancel_server) or WRITE (order_server, create_topup) lack destructiveHint or idempotentHint annotations. Agents cannot distinguish safe retries from irreversible operations.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | 2026-07-28+ | v2 |
List the last N authenticated requests for this account.
Get the current wallet balance in USD.
Get details of a single server by id.
Read a top-up by order_number.
List API keys on the account (metadata only — no plaintext recoverable).
List Nordic bastion locations (Stockholm, Helsinki, Oslo, Reykjavík).
Top-up bonus ladder (linear interpolation between anchors).
Full catalog bundle: VPS + dedicated tiers + bastions + OS images.
Cryptocurrencies accepted for top-ups.
List dedicated bare-metal tiers (5 tiers, Bastion-Lite → Hyperion).
List available OS images (Ubuntu 24/22, Debian 13/12, AlmaLinux 9, Rocky 9).
List all servers on the account.
List recent top-up invoices, optionally filtered by status.
List VPS tiers (5 tiers, Sentinel → Citadel).
Exchange email + password for access/refresh tokens. If 2FA is enabled, returns 202 and asks for a follow-up `login_totp` call.
Second factor for a pending login (use after `login` returned `totp_required: true`).
Provision a new VPS or dedicated server. Requires a confirmed top-up on the account. Returns server id, root password (ONCE), and status.
Reboot a server (soft or hard).
Rotate a refresh token into a fresh access pair.
Create a new NordBastion account from an email + password. Returns the user + access/refresh tokens. KYC-free: no name, phone, or document is ever requested.
Remove an SSH public key from a server.
Revoke an API key by id.
No error handling guidance in tool definitions. Descriptions do not explain failure modes (e.g., 'amount_too_low' for create_topup, '202 + totp_required' for login) or recovery steps. Agents cannot self-correct on errors.
Scope/permission requirements not documented in descriptions. Tools like create_api_key (scope='full'), revoke_api_key (scope='full'), order_server (scope='servers') lack inline guidance on what permissions are needed or why. Agents cannot plan permission-aware workflows.