Skip to main content
Glama
Sign In
VPSnet

VPSnet

by bacarrdy
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Quote VPN period renewal

quote_vpn_period_renewal

Get a no-charge quote for a VPN gateway renewal over a chosen term, defaulting to one month, so you can review the exact EUR total before confirming payment.

Instructions

Quote the VPN's selected term (one month when omitted) on its actual paid scope; no charge. Availability follows the owned gateway's current capability. 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
gateway_idYesExact 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/5.0
Behavior5/5

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

Extensive disclosure beyond annotations: no charge, auth scopes (networking:read/manage, full access), backend ownership/feature/2FA enforcement, pending operation semantics, polling on in_progress with reason_code interpretation, idempotency key reuse rules, transport uncertainty handling, payment method limitation, and that payment acceptance is not resource readiness. No contradiction with annotations.

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?

A long but dense paragraph where every sentence conveys behavioral or prerequisite information. It is front-loaded with purpose and key constraints, though better structuring with bullets could improve readability without losing content.

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?

Given no output schema and high complexity, the description covers prerequisites, operation lifecycle (polling, reason_code), idempotency, and payment constraints thoroughly. Nothing critical for correct invocation is missing.

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

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with detailed descriptions for all three parameters. The description repeats the default term (one month when omitted) and the bound caveat, but adds no new syntax or constraints beyond what the schema already provides. Baseline 3 is appropriate when schema does the heavy lifting.

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?

States a specific verb 'Quote' and resource 'VPN's selected term' with scope 'actual paid scope; no charge'. It distinguishes from renewal siblings by noting no charge, but does not name alternatives like renew_vpn_period or quote_account_vpn to guide selection.

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

Usage Guidelines3/5

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

Provides clear prerequisites (read capabilities first, obtain approval, requires networking:read/manage) and steps (choose catalog tier, disclose gross_amount), but never explicitly states when to use this tool versus sibling quote/renew tools. Usage is implied by context rather than contrasted with alternatives.

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