Skip to main content
Glama
Sign In
VPSnet

VPSnet

by bacarrdy
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Quote account VPN

quote_account_vpn

Creates an account VPN quote for checkout using an owned network and selected term; no provisioning or charge occurs before payment.

Instructions

Create an account VPN quote for common checkout when vpn_account_order is advertised. Pass its owned attachment network when required; no provisioning or charge occurs before payment. Uses prepare_after_payment=true. Requires explicit networking:read for reads or networking:manage for changes; full/read defaults do not grant networking. The backend enforces ownership, feature availability and service 2FA locks. Read current capabilities and owned resource state first; obtain approval for the exact change. An accepted operation is pending, not proof of connectivity. Poll the returned operation/resource on its in_progress flag, waiting next_check_seconds between reads: while in_progress is true its reason_code is what is awaited (reason_kind waiting, e.g. a queued or pending reason, or a control plane that has not answered yet), never an error; only in_progress false with reason_kind failure is a failure. Preserve reason_code. On transport uncertainty inspect state and reuse only the original key and unchanged request; never automatically retry. Requires full API access, networking:manage, enabled paid operations, networking:order and spend caps. Choose a supported live catalog tier and its documented request kind; preserve the exact quote; disclose its gross_amount in EUR before user approval. The same Idempotency-Key is required for quote and confirmation. API-key checkout supports the advertised account-balance payment method only. Payment acceptance is not resource readiness.

Input Schema

NameRequiredDescriptionDefault
tierYes
network_idNoExact lowercase UUID returned by an owned networking resource
period_monthsNoPaid term in months from the current list_network_products catalog; omit for one month. The 1-120 bound is not an offer list. Disclose this term and the exact quoted total before confirmation.
idempotencyKeyYesStable Idempotency-Key for this exact intent; reuse unchanged on recovery, never generate a new key for an uncertain result

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.3.20
    • addedInput schema / properties / period_months
      Added value: +{
+  "description": "Paid term in months from the current list_network_products catalog; omit for one month. The 1-120 bound is not an offer list. Disclose this term and the exact quoted total before confirmation.",
+  "maximum": 120,
+  "minimum": 1,
+  "type": "integer"
+}
  2. First observedv2.3.16

TDQS

A4.1/5.0
Behavior5/5

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

Beyond the annotations it discloses the economic behavior (no provisioning or charge before payment, gross_amount in EUR must be disclosed, payment acceptance is not resource readiness), the permission model (networking:read vs networking:manage, full/read defaults excluded), and the pending-operation semantics with reason_code and polling rules. It also states the retry contract explicitly (reuse the original key, never auto-retry on transport uncertainty), which is exactly the kind of information 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.

Conciseness3/5

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

The purpose leads, which is good, but the remainder is a dense run-on that chains permissions, idempotency, polling mechanics, payment-method restrictions and prerequisites without paragraph breaks or ordering. Every sentence is substantive yet the lack of structure makes the call-critical points (tier source, EUR disclosure, key reuse) harder to locate than they should be.

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

Completeness4/5

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

There is no output schema, and the description compensates by explaining the returned operation/resource, the in_progress polling loop, next_check_seconds, and reason_kind handling. Coverage of the quoting-to-confirmation flow and its prerequisites is strong; the remaining gap is that the checkout/confirmation step sequence and accepted `tier` values are left implicit.

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 75%, so the baseline is 3; the description earns above that by supplying meaning for the undescribed `tier` parameter (a supported live catalog tier with its documented request kind) and by constraining `idempotencyKey` (same key required for quote and confirmation, reuse on recovery). It does not spell out what values `tier` accepts, but the catalog pointer is a useful addition over the bare regex.

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

Purpose4/5

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

The opening sentence names a specific verb and resource ("Create an account VPN quote") and scopes it with a condition ("for common checkout when vpn_account_order is advertised"), which separates it from the many other quote_* siblings. It does not explicitly name a competing sibling such as quote_network_product or quote_vpn_period_renewal, so the differentiation is by condition rather than by contrast.

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

Usage Guidelines4/5

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

It gives real preconditions: read capabilities and owned resource state first, obtain approval for the exact change, and pass the owned attachment network when required. However, it never names an alternative tool or a when-not-to-use case, so an agent must infer the boundary with quote_network_product and the VPN renewal quoters.

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

Deploy Server

Other Tools