Enables comparison of Cloudflare cloud pricing across compute, database, serverless, storage, AI, GPU, containers, and app-hosting categories.
Enables comparison of DigitalOcean cloud pricing across compute, database, serverless, storage, AI, GPU, containers, and app-hosting categories.
Enables comparison of Google Cloud pricing across compute, database, serverless, storage, AI, GPU, containers, and app-hosting categories.
Provides token pricing and context window data for Meta Llama models in AI model searches.
Provides token pricing (input, output, prompt caching) and context window data for OpenAI models in AI model searches.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Compare Cloud Costs MCP Server estimate monthly cost for a 3-tier web app on AWS vs Azure"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A standalone Model Context Protocol server that gives your AI assistant access to the Compare Cloud Costs pricing catalog — cloud and AI model pricing across AWS, Azure, Google Cloud, Oracle, DigitalOcean, Alibaba, Cloudflare and the frontier AI providers, aligned to the FinOps FOCUS™ standard.
Data freshness: CCC refreshes its pricing information about once a week. The catalog is not real-time or live data, so use it for planning and comparison rather than minute-by-minute price checks.
This package is the installable, stdio-transport MCP server. Tool names and schemas match the canonical catalog used by the Compare Cloud Costs backend, and every tool is backed by the site's real public APIs — no sample data.
Tool | What it does |
| Query and compare multi-cloud compute, database, and serverless pricing across AWS, Azure, Google Cloud, Oracle, DigitalOcean, Alibaba, and Cloudflare. Filters: |
| Search token pricing (input, output, prompt caching) and context windows for AI LLMs across OpenAI, Anthropic, DeepSeek, Mistral, Meta Llama, and Cohere. Filters: |
| End-to-end multi-cloud monthly cost benchmarks for realistic full-stack architectures (VMs + managed DB + load balancers + storage + egress). Takes a |
| Checks global data center availability and region locations from the pricing catalog, with pointers to certification details. Filters: |
estimate_workload_architecture accepts the workload slugs from https://comparecloudcosts.com/workloads, e.g. 3-tier-web, serverless-web-app, rag-ai-app, k8s-app-platform, ecommerce-microservices, streaming-analytics, data-warehouse-bi, ml-training-hosting, agentic-ai-swarm. (The example slugs in the tool description — three-tier-web-app, ai-rag-pipeline, etc. — predate the current catalog; if an ID is unknown the tool returns the list of valid IDs.)
Related MCP server: CloudCost MCP Server
Tool calls need a free Compare Cloud Costs API key:
Go to https://comparecloudcosts.com/mcp and click Generate preview key (1-click, no card). Keys look like ccc_live_….
Set it as the CCC_API_KEY environment variable in your MCP client config (see below).
tools/list works without a key; tools/call returns an error explaining how to get one. Free preview keys are rate-limited per hour (the remaining quota is reported in tool responses).
Add to claude_desktop_config.json (macOS: ~/Library/Application Support/Claude/claude_desktop_config.json; Windows: %APPDATA%\Claude\claude_desktop_config.json):
{
"mcpServers": {
"compare-cloud-costs": {
"command": "npx",
"args": ["-y", "@comparecloudcosts/mcp-server"],
"env": {
"CCC_API_KEY": "ccc_live_your_key_here"
}
}
}
}Add to ~/.cursor/mcp.json (or a project .cursor/mcp.json):
{
"mcpServers": {
"compare-cloud-costs": {
"command": "npx",
"args": ["-y", "@comparecloudcosts/mcp-server"],
"env": {
"CCC_API_KEY": "ccc_live_your_key_here"
}
}
}
}Add to .vscode/mcp.json (note VS Code uses the servers key):
{
"servers": {
"compare-cloud-costs": {
"command": "npx",
"args": ["-y", "@comparecloudcosts/mcp-server"],
"env": {
"CCC_API_KEY": "ccc_live_your_key_here"
},
"type": "stdio"
}
}
}Requires Node.js ≥ 18.
All pricing data comes from GET https://comparecloudcosts.com/api/v1/pricing with header X-API-Key: <CCC_API_KEY> (documented in the "Public API" section of https://comparecloudcosts.com/docs). The endpoint is a faceted filter over the pricing database; the mappings below follow its server-side filter semantics exactly.
compare_cloud_pricingTool argument | API parameter | Notes |
|
| The API has no category filter that accepts these values — its |
|
| Provider slugs pass through unchanged ( |
|
| Numeric minimum. |
|
| Numeric minimum, GB. |
|
| The API has no region-slug parameter. Region IDs ( |
Results are ordered by price ascending (cheapest first) by the API. The server requests a 500-record page and returns the total count plus the 50 lowest-priced records, trimmed to the comparison-relevant fields.
search_ai_modelsproduct=ai plus provider (passed through) and model_family → the API's free-text search parameter. Records are returned with their attributes (modality, model tier, etc.); token prices are per the record's unit (typically per 1M tokens).
estimate_workload_architectureWired to the site's real estimator: POST https://comparecloudcosts.com/api/workloads with { "workloadId": "<id>" }, which returns per-provider monthly totals and a component breakdown (instance types, quantities, monthly prices) computed from catalog pricing records (refreshed about once a week). The tool returns those totals and components as-is. Unknown IDs return the API's "Workload not found" plus the list of valid IDs — numbers are never invented.
lookup_datacenter_complianceRegional availability is computed from the site's facets endpoint, GET https://comparecloudcosts.com/api/facets?product=compute[&geography=…] (the same endpoint that powers the website's filter sidebar), which returns catalog-wide record counts per geography and per provider with proper faceted-search semantics. This is deliberately not derived from a sample of pricing records — the pricing endpoint returns records cheapest-first, which badly under-reports non-US geographies.
Honest limitation: per-datacenter compliance certifications (SOC 2, ISO 27001, HIPAA, PCI-DSS, FedRAMP, GDPR) are not exposed by any public API — the pricing records carry no certification fields. When a compliance_standard is requested, the tool says so explicitly and points to https://comparecloudcosts.com/datacenters and https://comparecloudcosts.com/compliance instead of fabricating coverage.
Also note: at the time of writing, the catalog's geography tagging for compute records is concentrated in North America (with a small Asia Pacific set), so geography-filtered queries for other regions may return zero records. That is the catalog's real coverage, reported as-is.
npm install
npm run build
npm start # stdio server on dist/index.js
node test/smoke.mjs # optional smoke test (set CCC_SMOKE_KEY to include API calls)server.json — official MCP Registry manifest (com.comparecloudcosts/mcp-server); the matching mcpName field is in package.json, as the Registry requires.
glama.json — Glama ownership-claim file (maintainer: the repository owner).
MIT
Query and compare multi-cloud compute, database, and serverless pricing across AWS, Azure, Google Cloud, Oracle, DigitalOcean, Alibaba, and Cloudflare.
| Name | Required | Description | Default |
|---|---|---|---|
| region | No | Target deployment geography or region (e.g. us-east-1, eastus, us-central1, sa-east-1) | |
| category | Yes | Product category: vm, database, serverless, storage, ai, networking, etc. | |
| min_vcpu | No | Minimum required vCPUs for instance configurations | |
| provider | No | Filter by provider ID: aws, azure, gcp, oracle, digitalocean, alibaba, cloudflare | |
| min_ram_gb | No | Minimum required RAM memory in Gigabytes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full burden, yet it only implies read-only behavior via "query" and lists provider coverage — which largely duplicates the provider enum in the schema. It says nothing about pricing freshness/currency, whether prices are list vs. discounted, regional caveats, or rate limits, all of which materially affect trust in pricing results.
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?
One sentence, zero filler, front-loaded with the action and scope. Nothing in it is redundant padding.
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 full schema coverage and no output schema, the minimum bar is met, but an agent still lacks information about return shape (normalized per-hour price? per-provider records?) and data provenance/freshness. For a comparison tool that feeds downstream decisions, that is a meaningful gap.
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 baseline is 3. The description adds no parameter-level nuance beyond echoing the category and provider lists already present in the schema enums, and does not explain how filters combine (e.g., whether min_vcpu/min_ram_gb apply only to vm/gpu categories).
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 gives a specific verb pair ("query and compare") and resource (multi-cloud pricing), and enumerates the covered providers, so the agent knows exactly what domain this covers versus siblings like search_ai_models or estimate_workload_architecture. Minor deduction because the stated scope ("compute, database, and serverless") understates the category enum, which also includes storage, ai, gpu, containers, and app-hosting.
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 implied by "compare" — you call it when you need cross-provider price data — but there is no explicit when-to-use, when-not-to-use, or routing guidance relative to the three sibling tools. It does not say, for example, whether to use this before or instead of estimate_workload_architecture.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculates end-to-end multi-cloud cost benchmarks for realistic full-stack architectures (VMs + Managed DB + Load Balancers + Storage + Egress).
| Name | Required | Description | Default |
|---|---|---|---|
| workload_id | Yes | Pre-modeled workload slug (e.g. three-tier-web-app, ai-rag-pipeline, high-throughput-api, batch-processing) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses the scope of components included in the estimate, but says nothing about whether this is a read-only computation, whether benchmarks are cached/precomputed, latency, rate limits, or cost/credential implications of an estimate call.
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 front-loaded sentence with the core action stated first and the parenthetical component list adding useful scope at the end. No wasted text, though it is essentially one clause long.
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 one-parameter tool with no annotations and no output schema, the description is adequate: it conveys the output is a multi-cloud cost benchmark. However, it omits any return-format hint and any usage context, leaving gaps an agent must infer.
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?
Only one parameter exists and its schema description has 100% coverage, including example slugs, so the schema already does the heavy lifting. The description adds no further meaning about how workload_id is chosen or what values are valid beyond what the schema states.
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 (calculates) and a well-scoped resource (end-to-end multi-cloud cost benchmarks for full-stack architectures), enumerating the covered components. It is clear what the tool does, but it never distinguishes itself from the sibling compare_cloud_pricing, which an agent could easily confuse it with.
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?
There is no explicit when-to-use guidance, no statement of prerequisites, and no routing to or away from the sibling compare_cloud_pricing tool. The only implied usage signal is the 'workload_id' parameter, which is left for the agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Checks global data center availability, region locations, and compliance certifications (SOC 2, ISO 27001, HIPAA, PCI-DSS, FedRAMP).
| Name | Required | Description | Default |
|---|---|---|---|
| country_or_city | No | Filter by geographical location (e.g. Brazil, Germany, Tokyo, Virginia) | |
| compliance_standard | No | Compliance standard code: soc2, iso27001, hipaa, pci-dss, fedramp, gdpr |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full behavioral burden. It does disclose the categories of data returned (availability, regions, certifications), which is useful, but it says nothing about how the two optional filters combine (AND vs OR) or what is returned when no filter is supplied.
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 efficient sentence with the resource list front-loaded and no filler. It could be marginally tighter but wastes no words.
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 two-parameter, optional-filter lookup with no output schema and no annotations, the description covers what the tool returns but leaves filter-combination and no-filter behavior undefined. Adequate, but not complete enough to call it correctly without guessing.
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 baseline is 3. The description restates the certification list, but it actually omits 'gdpr', which the schema does list, so it adds no meaning beyond the schema and is slightly less complete than the parameter documentation.
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 ('Checks') plus three concrete resources: data center availability, region locations, and compliance certifications, with named standards. The purpose is unambiguous, though it never explicitly distinguishes itself from siblings like compare_cloud_pricing, which it could be confused with at the margins.
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?
There is no when-to-use guidance, no stated prerequisites, and no mention of alternatives. The agent must infer that this is the tool for datacenter/compliance questions purely from the topic.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search token pricing (Input, Output, Prompt Caching) and context windows for AI LLMs across OpenAI, Anthropic, DeepSeek, Mistral, Meta Llama, and Cohere.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | No | AI model provider: openai, anthropic, deepseek, mistral, cohere, google | |
| model_family | No | Model family name (e.g. gpt-4o, claude-3-5-sonnet, deepseek-r1, mistral-large) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses what data domains are searched (input/output/caching pricing, context windows), which is useful, but says nothing about read-only nature, result format, pagination, or no-match behavior.
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 with the key content (pricing dimensions, providers, context windows) front-loaded and no filler. It earns its place, though the provider enumeration is long and partly redundant with the schema.
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?
Both parameters are optional and fully documented by the schema, and there is no output schema. The description covers the domain well enough to invoke the tool, but for a search tool with no annotations or output schema it could say more about what results look like.
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 the schema already documents both optional parameters fully; baseline is 3. The description adds a provider list, but it omits 'google' which the schema explicitly supports, making the description slightly less complete than the schema rather than additive.
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 (search) and resource (token pricing and context windows for AI LLMs), and enumerates the pricing dimensions covered. It is distinguishable from compare_cloud_pricing by scope (AI model token pricing vs cloud infrastructure), though the sibling differentiation is implicit rather than stated.
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 implied by the scope statement – an agent can infer this is for looking up LLM pricing/context data. However, there is no explicit when-to-use guidance, no mention of compare_cloud_pricing as the alternative for cloud pricing, and no exclusions.
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.
v1.0.0compare_cloud_pricingestimate_workload_architecturelookup_datacenter_compliancesearch_ai_modelsScored across 4 tools
Each tool targets a distinct resource: AI model token pricing, cloud infrastructure pricing, full-stack workload estimation, and datacenter compliance. There is mild overlap between compare_cloud_pricing and estimate_workload_architecture since both deal with compute costs, but they operate at different levels of abstraction (raw pricing vs. composed architecture benchmarks) which keeps them separable.
All four tools follow a consistent snake_case verb_noun pattern (search_ai_models, compare_cloud_pricing, estimate_workload_architecture, lookup_datacenter_compliance). The verb choice is clear and predictable across the set.
Four tools is a lean but reasonable surface for a cost-comparison server, with each tool earning its place across distinct resource types. It is slightly thin—one might expect an additional tool for pure region/instance lookup—but nothing redundant is present.
The surface covers AI pricing, cloud pricing, workload estimation, and compliance/region lookup, which addresses the core cost-comparison workflow. Minor gaps exist, such as historical pricing trends or detailed per-instance configuration calculators, but agents can work around these.
Unified API to query AWS, GCP, Azure and generate Terraform/CLI execution kits for AI agents.
Verified cloud cost forecasting for AI agents. AWS, GCP, Azure pricing matrix.
Verified cloud cost forecasting for AI agents. AWS, GCP, Azure pricing matrix.
Cloud cost + FinOps knowledge for AI agents: AWS/Azure/GCP optimisation, AI spend, waste playbooks.
