VPSnet

Quote network product

quote_network_product

Generate the exact paid quote for a supported network product (load balancer or VPN gateway) before checkout approval. No charge or stock preparation occurs.

Instructions

Create the network product's exact paid quote for COMMON CHECKOUT. No charge or stock preparation occurs here. prepare_after_payment=true is always sent. Catalog product load_balancer maps to request kind private_lb for tier nlb or proxy_lb for tiers alb_proxy_3/alb_proxy_5; vpn_gateway maps directly. Only use currently supported catalog tiers. Create with order_network_product after disclosure and approval. 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

Name	Required	Description
`kind`	Yes
`tier`	Yes
`network_id`	Yes	Exact lowercase UUID returned by an owned networking resource
`period_months`	No	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.
`idempotencyKey`	Yes	Stable 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.

Changed1 schema field changedv2.3.20Oct 30, 2026

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"
+}

First observedv2.3.16Oct 16, 2026

TDQS

A4.2/5.0

Behavior5/5

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

The description adds substantial behavioral context beyond the annotations: no charge occurs, prepare_after_payment is always sent, permissions are required, backend enforcement applies, operations are asynchronous, polling semantics are defined, and idempotency-key recovery rules are specified. These details are highly valuable for a non-destructive but state-changing quote 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?

The purpose is front-loaded, but the description is long, dense, and repetitive, especially around permissions, supported tiers, and approval. It contains many useful details, yet some sentences repeat earlier points and the overall structure could be tightened.

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 complex quote tool with no output schema, the description covers the critical context: authorization, ownership enforcement, async polling, idempotency, payment-method constraints, and the distinction between payment acceptance and resource readiness. An agent has enough information to call it safely.

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 60%, and the description adds meaningful mapping for kind and tier: load_balancer maps to private_lb for nlb or proxy_lb for alb_proxy_3/alb_proxy_5, while vpn_gateway maps directly. It also reinforces idempotencyKey semantics, though it adds little beyond the schema for network_id and period_months.

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 description states a specific verb and resource: create the network product's exact paid quote for COMMON CHECKOUT, and it clarifies that no charge or stock preparation occurs. It distinguishes this from order_network_product, but does not explicitly distinguish it from the sibling quote_network_product_renewal.

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 clear usage context: read capabilities first, obtain approval, choose a supported live catalog tier, preserve the quote, and then create with order_network_product. It also lists permission and account prerequisites. It stops short of explicit when-not-to-use guidance or naming renewal alternatives.

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

Deploy Server

Quote network product

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools