Skip to main content
Glama
Sign In

EQVPS — VPS and code sandboxes for AI agents

by io.github.Poiuyhje
OverviewDiscussionsAdmin

Change VPS plan (resize / convert)

change_plan
Destructive

Switch a VPS to another plan IN PLACE — files and the OS are kept; the server reboots once (~1 min). target_plan = product_id from get_upgrade_options. The prorated difference is charged from the prepaid balance right away (402 with needed/balance if it is short — top up and retry); convert_to_nat refunds the unused difference to the balance. The next renewal uses the new price. Same function as the cabinet's Upgrade panel. If the server's host has no free room (or no free IPv4 for NAT → IP) right now, the response is 202 with queued: true: the difference is charged now and the upgrade is applied automatically from the queue, usually within 24 hours — the server reboots once at that moment and keeps running on the current plan until then; a second change_plan meanwhile returns 409 upgrade_queued. The response shows charged, unused_credit (unused time of the old plan, counted) and new_cost. Set confirm: true. Requires: token + balance for the prorated difference + confirm: true. No room on the server's host → 202 queued (paid, applied automatically, usually within 24 hours). Typical errors: 402 (top up), 409 upgrade_queued (one upgrade is already paid and waiting), 422 not an upgrade (pick from get_upgrade_options).

Input Schema

NameRequiredDescriptionDefault
confirmYesRequired. Must be true — you agree to the charge and one reboot.
service_idNoOptional. Service code as returned by list_vps/order_vps, e.g. "68J67T5" (a plain numeric id is also accepted).
target_planYesRequired. Target plan `product_id` from get_upgrade_options `options[]`, integer, e.g. 11.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / confirm / description
      Previous value: -"Must be true — you agree to the charge and one reboot."New value: +"Required. Must be true — you agree to the charge and one reboot."
    • changedInput schema / properties / service_id / description
      Previous value: -"Service code as returned by list_vps/order_vps, e.g. \"68J67T5\" (a plain numeric id is also accepted)."New value: +"Optional. Service code as returned by list_vps/order_vps, e.g. \"68J67T5\" (a plain numeric id is also accepted)."
    • changedInput schema / properties / target_plan / description
      Previous value: -"product_id from get_upgrade_options"New value: +"Required. Target plan `product_id` from get_upgrade_options `options[]`, integer, e.g. 11."
  2. Added

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only give destructiveHint/idempotentHint; the description goes far beyond by disclosing the in-place semantics, the single ~1 min reboot, immediate prorated charging from prepaid balance, refund behavior for convert_to_nat, and the full 402/409/422/202 error and queueing model with a 24h fulfillment window. This is exactly the behavioral context an agent needs for a destructive, non-idempotent operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action, but the 202 queued behavior is explained twice in near-identical wording ('If the server's host has no free room... 202 with queued: true' then 'No room on the server's host → 202 queued (paid, applied automatically, usually within 24 hours)'). That duplication pads an otherwise dense but single-topic paragraph.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no output schema, the description covers charges, refunds, reboot count, queue fallback, the response fields (charged, unused_credit, new_cost), and all typical error codes. Nothing material an agent needs to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

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 adds genuine meaning by tying `target_plan` to get_upgrade_options' options[] and by explaining the charging/refund semantics attached to `confirm` and the convert_to_nat variant. It does not add syntax details beyond the schema, so it stays below a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource with scope ('Switch a VPS to another plan IN PLACE — files and the OS are kept'). It is clearly distinguishable from siblings like get_upgrade_options (which supplies the target), reinstall_vps, and order_vps.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes the agent to get_upgrade_options for `target_plan`, names convert_to_nat as a variant behavior, and states the failure conditions (422 not an upgrade, 409 upgrade_queued). When-to-use and prerequisites (token + balance + confirm) are all spelled out.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All EQVPS — VPS and code sandboxes for AI agents toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources