Skip to main content
Glama
Sign In

EQVPS — VPS and code sandboxes for AI agents

by io.github.Poiuyhje
OverviewDiscussionsAdmin

Order limits & add-ons

get_order_limits
Read-only

Before order_vps: the per-order maximum (max_quantity = 50, a typo guard; limit_reason max_per_order) and which add-ons a plan has with their monthly price (addons.backups, addons.extra_ipv4). Orders are never refused for capacity — servers without free room are queued for creation (usually within 24 hours, see queue_note). Pass the same product and months (or period/plan_id) you will order; the response carries months, term_price (plan price for the term, one server, before add-ons and an automatic offer) and terms (1–36 months, quick picks 1/3/6/12). Works without a token. Requires: nothing (with a token the limit is for your account; without one — as for a new account).

Input Schema

NameRequiredDescriptionDefault
addonsNoOptional. Add-ons to price: array of "backups" and/or "extra_ipv4", e.g. ["backups"]. Default: none.
monthsNoOptional. Billing term in months, integer 1–36 (default 1); 12 = the annual plan. Takes precedence over period/plan_id.
periodNoOptional. Billing period to price: "month" (default) or "year". Ignored when `months` or `plan_id` is given.
plan_idNoOptional. Billing plan id from list_plans `plans[].plan_id`, integer, e.g. 24. Ignored when `months` is given.
productYesRequired. Plan slug from list_plans, e.g. "nano-ip".
locationNoOptional. Server country to check: "de" (Germany) or "fi" (Finland). Default: automatic placement.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • addedInput schema / properties / addons / description
      Added value: +"Optional. Add-ons to price: array of \"backups\" and/or \"extra_ipv4\", e.g. [\"backups\"]. Default: none."
    • addedInput schema / properties / location / description
      Added value: +"Optional. Server country to check: \"de\" (Germany) or \"fi\" (Finland). Default: automatic placement."
    • addedInput schema / properties / months / description
      Added value: +"Optional. Billing term in months, integer 1–36 (default 1); 12 = the annual plan. Takes precedence over period/plan_id."
    • addedInput schema / properties / period / description
      Added value: +"Optional. Billing period to price: \"month\" (default) or \"year\". Ignored when `months` or `plan_id` is given."
    • addedInput schema / properties / plan_id / description
      Added value: +"Optional. Billing plan id from list_plans `plans[].plan_id`, integer, e.g. 24. Ignored when `months` is given."
    • addedInput schema / properties / product / description
      Added value: +"Required. Plan slug from list_plans, e.g. \"nano-ip\"."
  2. Changed1 schema field changed
    • addedInput schema / properties / months
      Added value: +{
+  "maximum": 36,
+  "minimum": 1,
+  "type": "integer"
+}
  3. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already mark it read-only and closed-world, but the description adds substantial behavior beyond them: orders are never refused for capacity (queued, usually within 24h, see queue_note), and it discloses auth behavior ("works without a token"; with a token the limit is account-scoped). This is exactly the kind of context annotations cannot carry.

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

Conciseness4/5

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

The purpose and constraint are front-loaded in the first clause, and nearly every sentence carries information (limits, add-ons, queue policy, response fields). It is dense with parentheticals and slightly heavy, but there is little dead weight.

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?

With no output schema, the description takes on the burden of describing returns and does so fully (months, term_price, terms with quick picks, addons.*, queue_note). An agent has everything needed to call it and interpret the result.

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 parameters are documented, but the description adds meaning beyond the schema by tying product/months to the subsequent order call and explaining max_quantity = 50 as a typo guard. This goes past the baseline 3 by supplying usage semantics the schema lacks.

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?

It states a specific resource (per-order max quantity, limit_reason, and plan add-on pricing) with an explicit relationship to the sibling order_vps, which an agent can use to distinguish this lookup from the actual ordering tool without opening any schema.

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?

"Before order_vps" names the trigger condition and the sibling it precedes, and the instruction to pass the same product/months you will order tells the agent exactly how to use it in the ordering flow. No ambiguity about when this tool is appropriate.

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