Azure VM sizes and USD list prices in 24 regions, updated weekly. Find, price and compare VMs.
Scored across 4 tools
Each tool has a distinct primary purpose: cost estimation, requirement-based discovery, single-size specs, and market change reporting. There is mild overlap since estimate_vm_cost and get_vm_size both surface pricing, and find_vm_sizes and get_vm_size both involve size selection, but the descriptions make the boundaries clear enough.
All four tools follow a clean verb_noun snake_case pattern (estimate_vm_cost, find_vm_sizes, get_price_changes, get_vm_size). The convention is consistent throughout with no deviations.
Four tools is a tight, well-scoped set for a focused Azure VM pricing server. It is slightly on the lean side but each tool clearly earns its place without redundancy.
The surface covers the main pricing workflows: finding sizes, getting specs, estimating commitment costs, and tracking market changes. Minor gaps exist (e.g. no direct region/OS comparison helper or currency options), but core agent needs are met.
Monthly and yearly cost of one or more Azure VM sizes for pay as you go, reservations and savings plans, with the break-even hours per month for each commitment. Use it to compare sizes or regions.
| Name | Required | Description | Default |
|---|---|---|---|
| os | No | Operating system for pay-as-you-go prices. Default linux. | |
| sizes | Yes | One to five VM sizes to price, e.g. ["Standard_D4s_v5", "Standard_D4as_v6"]. | |
| region | No | Azure region, e.g. westeurope or "West Europe". Omit to use each size's cheapest region. | |
| instances | No | Number of VMs. Default 1. | |
| hours_per_month | No | Runtime hours per month. Default 730 (always on). |
| Name | Required | Description |
|---|---|---|
| size | No | |
| region | No | |
| options | No | |
| cheapest | No | |
| estimates | No | |
| dataSource | Yes | pricesAsOf (ISO date), currency, source, dataset, stale (true if the weekly refresh is late). |
| hoursPerMonth | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description goes further by disclosing the commitment models priced, the break-even-hours output, and the cheapest-region fallback behavior — real context beyond the annotations, though it says nothing about pricing freshness or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly packed sentences with the core output (costs plus break-even) front-loaded and the usage hint last. No filler, no restatement of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return-format details are unnecessary, and the annotations carry the safety profile. The description covers what is computed and how it can be used; only the routing relative to sibling pricing/lookup tools is left implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so every parameter including defaults (linux, 730 hours, 1 instance) is already documented in the schema. The description adds only the loose hint of comparing sizes or regions, which does not meaningfully extend the parameter definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific computed output (monthly and yearly cost for one or more Azure VM sizes) plus the pricing models covered (pay-as-you-go, reservations, savings plans) and the break-even metric. This distinguishes it from the lookup-oriented siblings find_vm_sizes and get_vm_size, though it never names them explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Use it to compare sizes or regions" gives an implied usage scenario but offers no when-not-to-use guidance or explicit routing to find_vm_sizes / get_vm_size / get_price_changes. An agent can infer the fit, but nothing is stated about exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the cheapest Azure VM sizes that meet vCPU, memory and workload requirements, with monthly USD list prices. Burstable (B-series) and confidential sizes are only included when that workload is requested.
| Name | Required | Description | Default |
|---|---|---|---|
| os | No | Operating system for pay-as-you-go prices. Default linux. | |
| arch | No | CPU architecture. | |
| sort | No | price = cheapest first (default); fit = least spare vCPU/memory first. | |
| region | No | Azure region, e.g. westeurope or "West Europe". Omit to use each size's cheapest region. | |
| min_gpus | No | Minimum number of whole GPUs (partitioned GPUs such as 1/6 A10 do not count). | |
| workload | No | Workload family. ai = NVIDIA GPUs only (CUDA, PyTorch, vLLM); gpu = any GPU incl. AMD. Omit for any (excludes burstable and confidential). | |
| min_vcpus | No | Minimum vCPUs. | |
| max_results | No | Default 10. | |
| min_memory_gib | No | Minimum memory in GiB. | |
| need_temp_disk | No | Only sizes with a local temporary disk. |
| Name | Required | Description |
|---|---|---|
| os | No | |
| results | Yes | |
| pricedIn | No | |
| dataSource | Yes | pricesAsOf (ISO date), currency, source, dataset, stale (true if the weekly refresh is late). |
| matchCount | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), so the description's job is to add operational context, which it does by disclosing the pricing basis (monthly USD list prices) and the workload-gated filtering of burstable/confidential SKUs. No rate limits or result-cap behavior beyond what the schema's max_results already carries.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no waste, and the core capability plus its price output are front-loaded before the filtering caveat. Every clause carries information the agent needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values need no explanation, and all ten parameters are schema-documented. The description supplies the purpose, price basis, and inclusion semantics an agent needs; only explicit sibling routing is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all ten parameters, including the enum semantics for workload and sort and the default for region. The description adds only the pricing basis (list vs. negotiated) and reinforces the workload gating, which is marginal over the structured fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (find Azure VM sizes) plus the defining output constraint: cheapest sizes meeting vCPU/memory/workload requirements with monthly USD list prices. This separates it from get_vm_size (single size lookup) and estimate_vm_cost (cost estimation for a known config), though it never names those siblings explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a real inclusion rule: burstable and confidential families are returned only when that workload is explicitly requested, which tells the agent when results will and will not contain those SKUs. It stops short of naming alternatives or stating when to reach for estimate_vm_cost instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Weekly report of new Azure VM sizes, retired sizes and the biggest list-price moves across 24 regions.
| Name | Required | Description | Default |
|---|---|---|---|
| weeks | No | How many weekly reports, newest first. Default 1. |
| Name | Required | Description |
|---|---|---|
| message | No | |
| reports | No | |
| dataSource | Yes | pricesAsOf (ISO date), currency, source, dataset, stale (true if the weekly refresh is late). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare a safe read-only, idempotent, non-destructive profile. The description adds useful scope context: the report is weekly, covers 24 regions, and includes new, retired, and biggest list-price moves. It does not mention auth, rate limits, or pagination, but the output schema and annotations reduce the need for that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence that front-loads the tool's purpose and report contents. Every phrase earns its place and no extraneous detail is included.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only report tool with a full output schema, complete parameter documentation, and strong annotations, the description is largely complete. It explains what the report contains but leaves ambiguous when an agent should select it over sibling tools that also relate to Azure VM sizes and costs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the `weeks` parameter is already fully documented in the schema. The description does not add any parameter syntax or default-info beyond what the schema provides, making the baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific report resource and its contents: new Azure VM sizes, retired sizes, and biggest list-price moves across 24 regions. It clearly distinguishes this reporting tool from cost-estimation and VM-size lookup siblings, though it does not explicitly name those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The weekly-report framing implies the tool is used for recurring price-change tracking, and the schema's `weeks` parameter supports that by allowing retrieval of prior reports. However, there is no explicit when-to-use guidance or routing against siblings like estimate_vm_cost or find_vm_sizes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Specs of one Azure VM size and its hourly USD prices per region (Linux, Windows, 1/3-year reservations, 1/3-year savings plans), cheapest region first.
| Name | Required | Description | Default |
|---|---|---|---|
| size | Yes | VM size, e.g. Standard_D4s_v5 or D4s v5. | |
| region | No | Limit prices to one region. |
| Name | Required | Description |
|---|---|---|
| url | No | |
| size | Yes | |
| vcpus | No | |
| prices | Yes | Hourly USD prices per region, cheapest first. |
| category | No | |
| memoryGiB | No | |
| dataSource | Yes | pricesAsOf (ISO date), currency, source, dataset, stale (true if the weekly refresh is late). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and non-destructive, so safety is covered. The description adds genuinely useful behavioral context beyond that: the output is ordered cheapest-region-first and spans Linux/Windows plus 1/3-year reservation and savings-plan pricing, which tells the agent what shape of data to expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence, front-loaded with the resource and followed by the output scope. Every clause earns its place, though the parenthetical price enumeration is long enough to slightly slow the read.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values needn't be described, yet the description still usefully previews the price dimensions and ordering. Combined with full schema coverage and complete annotations, an agent has everything needed to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both size and region are documented with examples), so the baseline is 3. The description's 'per region' phrasing hints that region narrows prices but adds no syntax or default behavior beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Specs of one Azure VM size') and scopes it to a single size, which implicitly contrasts with the listing sibling find_vm_sizes. However, it never names a sibling or explicitly distinguishes itself from estimate_vm_cost, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: an agent can infer this is for detailed single-size lookup, but there is no explicit 'use this when...' statement and no mention of when to prefer estimate_vm_cost or find_vm_sizes instead. Adequate but with a clear gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
estimate_vm_costfind_vm_sizesget_price_changesget_vm_sizeVPS prices read daily from providers' own pricing pages and APIs: cheapest by size, place or app.
Live VPS, bare metal and GPU hosting prices across ~75 providers, rescraped daily.
Published list prices of compute (VPS, GPU hours, LLM tokens, media), archived daily. Read-only.
Hourly cloud GPU prices from 80+ providers: find, compare, cost and track GPUs.
Add one secure layer between your agents and this server.