Claude(또는 MCP 호환 클라이언트)가 AWS, Azure, GCP 전반의 온디맨드 컴퓨팅 + 스토리지 가격을 실시간으로 비교할 수 있게 해주는 MCP 서버입니다.
다음과 같이 질문해 보세요:
"us-east 지역에서 4 vCPU / 16 GB Linux VM의 AWS, Azure, GCP 가격은 얼마인가요?"
"3계층 배포 환경이 있습니다: 웹 8개(4/16), 앱 12개(8/32), DB 4개(16/64), 각 200 GB SSD OS 디스크 포함, 추가로 5 TB SSD 공유 및 50 TB HDD 벌크 스토리지가 있습니다. AWS vs Azure vs GCP 월 비용을 비교해 주세요."
"EC2
t3.xlarge의 월 비용은 얼마인가요?"
Claude가 적절한 도구를 호출하면, 행별 + 클라우드별 + 합산 총액이 포함된 깔끔한 답변을 얻을 수 있습니다. 콘솔을 클릭하거나 세 개의 가격 계산기 사이를 오갈 필요가 없습니다.
pip install cloudprice-mcp또는 설치 없이 실행:
pipx run cloudprice-mcpPython 3.10 이상이 필요합니다.
Related MCP server: Cloud Cost MCP
Claude Desktop 설정을 편집하세요:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
다음 내용을 추가하세요:
{
"mcpServers": {
"cloudprice": {
"command": "cloudprice-mcp"
}
}
}Claude Desktop을 재시작하세요. 아래의 7가지 도구를 사용할 수 있게 됩니다.
도구 | 기능 |
| EC2 인스턴스 유형 조회 → vCPU, 메모리, 시간당 + 월간 USD (us-east-1) |
| Azure VM 크기 조회 → vCPU, 메모리, 시간당 + 월간 USD (eastus) |
| GCP Compute Engine 머신 유형 조회 → vCPU, 메모리, 시간당 + 월간 USD (us-east1) |
| 대상 사양(vCPU + GB)이 주어지면 각 클라우드에서 가장 저렴한 SKU를 반환하며, 월간 비용순으로 정렬하고 절감액 요약을 제공 |
도구 | 기능 |
| 컴퓨팅 워크로드 목록(각 vCPU / 메모리 / 수량 / 시간 / 선택적 OS 디스크 포함)을 벌크 비교합니다. 행별 일치 항목, 클라우드별 합계 및 전체적으로 가장 저렴한 클라우드를 반환합니다. |
| 스토리지 볼륨 목록(각 용량 / 디스크 유형 / 수량 포함)을 벌크 비교합니다. 행별 일치 항목, 클라우드별 합계 및 가장 저렴한 클라우드를 반환합니다. |
| 컴퓨팅 + 스토리지를 한 번에 비교합니다. 두 개의 시트(컴퓨팅 BoM + 스토리지 BoM)로 구성된 사이징 워크북을 반영합니다. 섹션별 상세 내역과 클라우드별 합산 총액을 반환합니다. |
{
"compute": [
{ "name": "web", "tier": "Web", "vcpus": 4, "memory_gb": 16, "quantity": 8, "os_disk_gb": 100, "os_disk_type": "ssd" },
{ "name": "app", "tier": "App", "vcpus": 8, "memory_gb": 32, "quantity": 12, "os_disk_gb": 200, "os_disk_type": "ssd" },
{ "name": "db", "tier": "DB", "vcpus": 16, "memory_gb": 64, "quantity": 4, "os_disk_gb": 500, "os_disk_type": "ssd" }
],
"storage": [
{ "name": "shared-fast", "tier": "DB", "capacity_gb": 5000, "disk_type": "ssd" },
{ "name": "shared-bulk", "tier": "App", "capacity_gb": 50000, "disk_type": "hdd" }
]
}스토리지 행의 snapshot_count와 컴퓨팅 행의 os_disk_snapshot_count가 이제 가격에 포함됩니다. 클라우드별/디스크 유형별 스냅샷 요율이 합산됩니다(AWS/Azure의 경우 GB당 월 약 $0.05, GCP의 경우 GB당 월 약 $0.026).
주의 — 상한선 추정: 스냅샷은 GB당 월 스냅샷 비용 × 전체 용량 × 수량 × 스냅샷 개수로 계산됩니다. 실제 스냅샷은 증분 방식(변경된 블록만 저장)이므로 실제 비용은 일반적으로 이 모델 수치의 20~50% 수준입니다. 스냅샷 비용이 전체의 큰 비중을 차지한다면, 해당 클라우드의 계산기를 통해 더 정확한 추정치를 확인하세요.
스토리지 행의 iops 및 throughput_mbs는 메타데이터로만 허용되며, 이번 릴리스에서는 SKU 매칭에 사용되지 않습니다.
compare_workload는 선택적 commitment 매개변수를 허용합니다:
값 | 컴퓨팅 할인 | 사용 사례 |
| 0% | 온디맨드 전용 |
| 30% | 1년 AWS Savings Plan / Azure RI / GCP CUD (선결제 없음) |
| 50% | 3년, 부분 선결제 — 일반적인 "기준 사용량 보장" 계약 |
스토리지와 스냅샷은 할인되지 않습니다(대부분의 클라우드는 스토리지에 대한 유의미한 약정 할인을 제공하지 않음). 할인 등급은 보수적인 평균치이며, 실제 요율은 인스턴스 제품군, 결제 옵션 및 리전에 따라 다릅니다.
가격은 클라우드별 일반적인 SKU(VM 약 45개 SKU 및 클라우드별 블록 스토리지 SSD + HDD)의 큐레이팅된 데이터셋으로 번들되어 있으며, 공개된 AWS / Azure / GCP 가격표를 기반으로 합니다. 각 응답에는 데이터의 최신성을 확인할 수 있도록 as_of 날짜가 포함되어 있습니다.
향후 릴리스에서는 라이브 모드가 추가될 예정이며, 각 클라우드의 공개 가격 API에서 직접 가격을 가져오게 됩니다:
AWS: Price List Bulk API
Azure: Retail Prices API
라이브 모드는 issue #1을, 클라우드 간 서비스 매핑(RDS↔SQL DB↔Cloud SQL 등)은 issue #2를 추적해 주세요.
git clone https://github.com/alialbaker/cloudprice-mcp.git
cd cloudprice-mcp
pip install -e ".[dev]"
pytestClaude Desktop이 개발 복사본을 가리키도록 하려면 설정에서 command를 다음과 같이 변경하세요:
{
"mcpServers": {
"cloudprice": {
"command": "python",
"args": ["-m", "cloudprice_mcp.server"]
}
}
}MIT — LICENSE를 참조하세요.
클라우드 아키텍트 Ali Albaker가 제작했습니다. AWS, Azure, GCP 전반에서 월 약 $1.80의 3개 클라우드 포트폴리오를 운영 중입니다.
Project cross-cloud cost + payback for moving a workload away from its source cloud. Inputs: source_cloud + workload inventory (compute / storage / object_storage / databases / egress) + optional one_time data to migrate. Returns per-target monthly cost, savings %, exit egress cost, payback months, ranked recommendation by 3-year TCO, and triggered caveats (e.g., 'OCI A1.Flex is ARM — verify your AMIs'). The kind of FinOps decision that normally lives in a half-built spreadsheet — now one tool call.
| Name | Required | Description | Default |
|---|---|---|---|
| egress | No | ||
| compute | No | ||
| storage | No | ||
| targets | No | Target clouds to evaluate. Default: all clouds except source_cloud. | |
| multi_az | No | ||
| one_time | No | ||
| databases | No | ||
| commitment | No | none | |
| source_cloud | Yes | Cloud the workload currently runs on. | |
| object_storage | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. It discloses important behavioral traits: returns per-target costs, savings, payback, and caveats (e.g., 'OCI A1.Flex is ARM — verify your AMIs'). This is transparent about the output including warnings, but doesn't explicitly state that it is read-only or idempotent.
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 concise, front-loaded with the main purpose, and uses short sentences to list inputs and outputs. It includes a memorable analogy ('half-built spreadsheet') without wasting 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?
Given the tool's complexity (10 parameters, nested objects, no output schema), the description covers the main purpose, key inputs, and important outputs like caveats. It lacks details on output structure and default behavior for the 'targets' parameter, but is generally complete enough for an agent to understand the tool's utility.
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 low at 20%. The description lists broad input categories (compute, storage, etc.) and gives a high-level overview of output dimensions, but does not explain specific parameters like snapshot_incremental_factor or the structure of egress items. It adds some context but not enough to fully compensate for the schema gaps.
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 clearly states the tool's purpose: 'Project cross-cloud cost + payback for moving a workload away from its source cloud.' It lists specific inputs and outputs, and distinguishes itself from sibling tools by positioning it as an integrated FinOps assessment that replaces a spreadsheet.
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 description implies usage for cost comparison scenarios but does not explicitly state when to use this tool over alternatives like compare_workload or total_cost_of_ownership. There are no exclusion criteria or guidance on prerequisite data preparation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the cheapest equivalent VM across AWS, Azure, GCP, and OCI for a single target spec (vCPUs and memory). Returns the best-fit SKU per cloud sorted by monthly cost, plus the absolute and percent savings of the cheapest vs the most expensive option. OCI A1 Always Free is included — for specs that fit within 4 OCPU + 24 GB Arm, OCI returns $0/mo (real perpetual free tier, not a quirk).
| Name | Required | Description | Default |
|---|---|---|---|
| vcpus | Yes | ||
| memory_gb | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description reveals key behaviors: best-fit SKU per cloud sorted by cost, savings calculation, and OCI free tier inclusion. It is transparent about what the tool returns.
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 redundancies. The first sentence states purpose and outputs, the second adds an important caveat. Front-loaded with key information.
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?
Excellent for a simple tool with two parameters: explains outputs (SKUs, costs, savings) and OCI edge case. Lacks details on return format or error handling, but adequate given no output schema.
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 0%, yet the description explicitly associates vcpus and memory_gb with the target spec, providing necessary meaning beyond the raw 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?
Clearly states the tool finds the cheapest equivalent VM across four cloud providers for a single target spec (vCPUs and memory). It distinguishes itself from siblings like compare_compute_inventory by focusing on a single spec comparison.
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 description implies usage for single spec comparisons via 'single target spec' but does not explicitly state when to use it over siblings or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Bulk-compare a list of compute workloads across AWS, Azure, GCP, and OCI. Each row is independently sized to the cheapest VM that meets its vCPU/memory spec on each cloud, multiplied by quantity and hours_per_month. Optional os_disk_gb adds attached storage cost. Returns per-row matches, per-cloud totals, and the cheapest cloud overall. Useful for sizing-sheet style inputs.
| Name | Required | Description | Default |
|---|---|---|---|
| workloads | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Explains independent sizing, cost multiplication, optional storage, and output structure. Lacks details on pricing freshness or rate limits but is sufficiently transparent.
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 concise sentences; first defines purpose, second details behavior and use case. No redundant or irrelevant information.
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?
Good coverage of behavior and outputs given complexity. Mentions per-row, per-cloud, and cheapest cloud results. No output schema, so description compensates well, though could clarify output format details.
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 descriptions cover many parameters (e.g., name, tier, os_disk_gb). Description adds limited extra value beyond mentioning os_disk_gb's effect. No additional parameter-specific guidance.
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?
Description clearly states it bulk-compares compute workloads across four clouds, with specific verbs and resource. Distinguishes from siblings like 'compare_workload' (single workload) and 'compare_clouds' (generic).
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?
Implies usage for 'sizing-sheet style inputs' but does not explicitly state when to use vs alternatives or when not to use. No exclusions or alternative tool names mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare data-transfer costs across AWS, Azure, GCP, and OCI for a given monthly volume. Two directions supported: 'out_to_internet' (tiered pricing with free-tier credits — AWS/Azure 100 GB, OCI 10 TB free) and 'inter_region' (flat rate for cross-region transfer within the same cloud). At 50 TB/mo of internet egress OCI is ~12× cheaper than the hyperscalers — a real competitive moat for content/CDN workloads. VPC peering is NOT yet modeled.
| Name | Required | Description | Default |
|---|---|---|---|
| transfers | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the two directions, free-tier credits, and an example pricing comparison. It also notes that VPC peering is not accounted for. However, it does not describe the output format or any error handling expectations.
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 verbose and includes promotional language ('a real competitive moat') that is unnecessary for tool selection. While front-loaded with purpose, the detailed pricing example adds length without improving clarity for the agent.
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?
Given no output schema, the description adequately covers behavior and limitations (VPC peering not modeled). However, it lacks information on expected output structure, error scenarios, or how to interpret the comparison results, leaving some gaps.
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?
The input schema has one parameter (transfers) with property descriptions, but the tool description adds context on the meaning of directions and free tiers (e.g., AWS/Azure 100 GB free, OCI 10 TB). The description coverage of parameters is 0% from the tool text, but the schema provides some detail, resulting in a moderate score.
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 clearly states the tool compares data-transfer costs across four major cloud providers for a given volume. It specifies the two supported directions (out_to_internet and inter_region) with context on pricing tiers, distinguishing it from sibling tools like find_egress_arbitrage and compare_clouds.
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 description implies usage for comparing egress costs but does not explicitly state when to use this tool versus alternatives like assess_migration or find_egress_arbitrage. It mentions that VPC peering is not modeled, which is a limitation, but lacks direct guidance on scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare object-storage pricing across AWS S3, Azure Blob, GCP Cloud Storage, and OCI Object Storage. Each request specifies capacity_gb and access tier (hot/cool/archive); the tool picks the cheapest SKU per cloud at that tier. OCI offers 20 GB Always Free in the 'hot' tier — surfaced when capacity fits. NOTE: egress, request, and retrieval costs are not modeled (often the actual hidden killer). v0.3 preview — placeholder pricing, verify before relying on numbers.
| Name | Required | Description | Default |
|---|---|---|---|
| volumes | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses that the tool picks the cheapest SKU per cloud, highlights OCI free tier, and warns about missing costs and preview status. This is comprehensive for a pricing comparison tool.
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 efficiently structured: purpose first, then inputs, then a critical limitation note. Every sentence adds value without redundancy.
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?
Given no output schema, the description lacks details on result format (e.g., table of prices). However, it covers core behavior, inputs, and limitations adequately for the tool's simplicity.
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?
The description explains the tier parameter (hot/cool/archive) and adds context about OCI free tier based on capacity. Schema descriptions also cover tier, but the description provides additional behavioral semantics.
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 explicitly states the tool compares object-storage pricing across AWS S3, Azure Blob, GCP Cloud Storage, and OCI Object Storage, and mentions key inputs. This clearly distinguishes it from sibling tools like compare_egress.
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 description specifies when to use the tool (comparing pricing for a given capacity and tier) and notes limitations (egress not modeled). However, it does not explicitly name alternative tools for excluded costs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare managed PostgreSQL pricing across AWS RDS, Azure Database for PostgreSQL, GCP Cloud SQL, and OCI Database with PostgreSQL. Each request specifies vCPUs, memory, and storage_gb; the tool picks the cheapest matching SKU per cloud and totals compute + storage. v0.3 preview — pricing is bundled placeholder data; verify against current cloud pricing pages before relying on numbers.
| Name | Required | Description | Default |
|---|---|---|---|
| databases | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully bears the transparency burden. It discloses that pricing is bundled placeholder data, advises verification, and explains the tool's logic (picks cheapest SKU per cloud, totals compute+storage). This is transparent about limitations and behavior, though it omits details like rate limits or authentication needs.
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 concise, with a clear first sentence stating purpose, a second sentence explaining how it works, and a third sentence providing an important caveat. Every sentence is essential and front-loaded for quick understanding.
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?
Given the tool's complexity (multi-cloud comparison), the lack of output schema, and the placeholder data warning, the description provides sufficient context for an agent to use the tool correctly. It covers input requirements, tool behavior, and a crucial limitation. It is complete for the task.
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?
The input schema has descriptions for some nested properties, but the context reports 0% schema description coverage. The tool description adds value by explaining how the parameters (vCPUs, memory, storage_gb) are used to select and total SKUs. This goes beyond what the raw schema provides, even though the schema has some self-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?
The description clearly states the tool compares managed PostgreSQL pricing across four major clouds. It uses specific verbs (Compare) and resource (managed PostgreSQL pricing), distinguishing it from sibling tools that compare other resources like compute or storage.
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 description explains that each request must specify vCPUs, memory, and storage_gb, and that the tool picks the cheapest matching SKU per cloud. It also warns that the pricing is placeholder data and should be verified. However, it does not explicitly state when to use this tool over alternatives, though the context from sibling names implies it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Bulk-compare a list of block-storage volumes across AWS, Azure, GCP, and OCI. Each row picks the cheapest SKU matching its disk_type (ssd or hdd) on each cloud, then prices it at capacity_gb × quantity. Returns per-row matches, per-cloud totals, and cheapest cloud. IOPS and throughput are accepted but not used for SKU matching. Snapshot pricing is upper-bound (real-world incremental snapshots cost less).
| Name | Required | Description | Default |
|---|---|---|---|
| volumes | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: cheapest SKU matching by disk_type, pricing formula, ignored fields (IOPS/throughput), and snapshot pricing being upper-bound. Returns per-row, per-cloud totals, and cheapest cloud. No annotations present, so description carries full burden; it meets it well.
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 with no wasted words. First sentence states purpose, second adds critical behavioral details. Front-loaded and efficient.
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?
Given complexity (multi-cloud, many nested parameters, no output schema), the description covers purpose, pricing logic, ignored fields, and output structure. Missing explicit output format details but sufficient for an agent to understand usage.
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?
Adds meaning beyond schema: explains IOPS and throughput are metadata only, snapshot pricing details (upper-bound, incremental factor). Schema has 0% coverage on outer param, but inner properties have descriptions. Description compensates by clarifying behavioral aspects.
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 clearly states it bulk-compares block-storage volumes across four clouds, specifying verb and resource. It distinguishes from siblings like compare_compute_inventory which focuses on compute.
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?
Implied usage for block-storage pricing comparison, but no explicit when-to-use or alternatives given. Does not mention when not to use or differentiate from related tools like compare_object_storage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Project per-cloud per-year cost over a configurable horizon (default 3 years), with linear YoY growth assumptions for compute / storage / egress. Returns cumulative TCO per cloud, year-by-year breakdown by category, and sensitivity analysis identifying the most impactful growth variable. The kind of number that goes into board decks and budget conversations — now computed from a public catalog instead of a spreadsheet.
| Name | Required | Description | Default |
|---|---|---|---|
| egress | No | ||
| growth | No | ||
| compute | No | ||
| storage | No | ||
| targets | No | Clouds to project. Default: all 4 clouds. | |
| multi_az | No | ||
| one_time | No | ||
| databases | No | ||
| commitment | No | none | |
| horizon_years | No | Years to project (default 3 — FinOps standard). | |
| object_storage | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explicitly states the tool uses linear YoY growth assumptions, a configurable horizon (default 3 years), and returns cumulative TCO, year-by-year breakdown, and sensitivity analysis. It also notes it computes from a public catalog, but does not mention if it modifies data or requires authentication.
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 concise (three sentences), front-loaded with the primary action ('Project per-cloud per-year cost'), and efficiently conveys key outputs and use case. It could be slightly tighter but is well-structured.
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?
Given the tool's complexity (11 parameters, nested objects, no output schema), the description provides adequate context for purpose and outputs but lacks details on default behavior (e.g., what happens with empty inputs) and output structure beyond brief mentions. It meets minimum viability but has gaps.
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 very low (18%), and the description does not compensate by explaining individual parameters. It provides high-level context about growth assumptions and horizon but does not describe the meaning of arrays like compute, storage, egress, or their nested fields. The agent would need to infer from parameter names.
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 clearly states the tool's purpose: 'Project per-cloud per-year cost over a configurable horizon' and details the outputs (cumulative TCO, breakdown, sensitivity analysis). It distinguishes itself from sibling tools like compare_clouds (likely static) and assess_migration (likely migration-focused) by focusing on future cost projection with growth assumptions.
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 description mentions the use case: 'The kind of number that goes into board decks and budget conversations,' providing clear context for when to use this tool. However, it does not explicitly exclude alternative tools or state when not to use it, so it falls short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Combined compute + block-storage compare across AWS, Azure, GCP, and OCI. Pass a compute list and a storage list (either may be empty). Returns nested per-row breakdowns plus combined per-cloud totals and the overall cheapest cloud. Mirrors the structure of a two-sheet sizing workbook (compute BoM + storage BoM). Optional commitment parameter estimates 1-year or 3-year Reserved Instance / Savings Plan / Committed Use discount on compute (storage stays at on-demand). For object storage, use compare_object_storage. For managed databases, use compare_postgres_database.
| Name | Required | Description | Default |
|---|---|---|---|
| compute | No | ||
| storage | No | ||
| multi_az | No | If true, double compute cost on every cloud to model Multi-AZ / HA deployments (sync replicas across two zones). Storage stays at 1x because object/block storage is usually cross-AZ at base price already. | |
| commitment | No | Compute commitment tier. 'none' = on-demand only. '1yr_no_upfront' applies a representative 30% compute discount. '3yr_partial_upfront' applies 50%. Storage and snapshots are not discounted. | none |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains the return structure (nested breakdowns, per-cloud totals, cheapest cloud) and the effect of commitment parameter. While it does not explicitly state it's read-only, it implies a query operation. Almost fully transparent.
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 paragraph of five sentences, each adding necessary information. Front-loaded with purpose, then usage, then exclusions. No filler, no repetition of schema details.
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?
Given complexity (nested arrays, no output schema), the description explains return structure and distinguishes sibling tools. It covers the main use case but lacks details on response format or error handling. Almost complete, minor gaps.
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 50%, baseline 3. The description adds semantics for the commitment parameter (explaining discount percentages) but does not delve into the array parameters' sub-fields beyond stating they expect compute and storage lists. Adequate but minimal additional value.
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 clearly states 'Combined compute + block-storage compare across AWS, Azure, GCP, and OCI', providing a specific verb-resource pair. It distinguishes itself from siblings by naming alternative tools for object storage and databases.
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?
Explicitly says 'Pass a compute list and a storage list (either may be empty)' and provides exclusions: 'For object storage, use compare_object_storage. For managed databases, use compare_postgres_database.' This gives clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Specialized assess_migration scoped to egress patterns. Useful when a team's largest cost line is data transfer (CDN workloads, video streaming, content distribution). Returns per-target egress cost, monthly + annual savings, payback months on any one-time exit cost, and recommendation. The OCI 12× moat is the headline finding: at 50 TB/month internet egress, OCI is roughly $340 vs $4,000+ on the hyperscalers because of OCI's 10 TB/month free tier + $0.0085/GB beyond.
| Name | Required | Description | Default |
|---|---|---|---|
| egress | Yes | ||
| targets | No | ||
| one_time | No | ||
| source_cloud | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description details return values (per-target cost, savings, payback months, recommendation) and gives concrete pricing example. Does not disclose side effects or limitations.
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?
Contains verbose example (OCI pricing) that is informative but could be more concise. First sentence is clear; rest adds context but lengthens description.
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?
Despite nested objects and 4 parameters, description lacks explanation of parameter structure (e.g., egress array format, direction enum). No output schema; behavior partially explained but input details missing.
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 0%; description does not explain parameters (egress, targets, one_time, source_cloud). Only indirectly references output, not input 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?
Description clearly defines it as a specialized version of assess_migration focused on egress, with specific use cases (CDN, video streaming). Distinguishes from sibling tools like assess_migration and compare_egress.
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?
Explicitly states when to use: when data transfer is the largest cost line. Provides context but does not mention when not to use or cite alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up the on-demand Linux hourly + monthly price for an AWS EC2 instance type in us-east-1. Returns vCPUs, memory, hourly USD, and monthly USD (730 hours). For multi-cloud comparisons including OCI, Azure, and GCP, use compare_clouds instead.
| Name | Required | Description | Default |
|---|---|---|---|
| instance_type | Yes | EC2 instance type, e.g. 't3.medium'. Available: c5.2xlarge, c5.large, c5.xlarge, m5.2xlarge, m5.4xlarge, m5.large, m5.xlarge, r5.2xlarge, r5.large, r5.xlarge, t3.2xlarge, t3.large, t3.medium, t3.micro, t3.small, t3.xlarge |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes return values (vCPUs, memory, hourly USD, monthly USD) and constraints (on-demand Linux, us-east-1). Lacks explicit mention of read-only nature or any side effects, but no annotations to contradict; behavior is well disclosed.
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 wasted words. First sentence conveys purpose and output, second gives alternative. Front-loaded with key action.
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?
Given simple tool with one parameter and no output schema, description fully covers purpose, return fields, constraints, and alternative. No gaps for effective use.
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 covers 100% of parameter, but description adds context that the instance_type is for on-demand Linux in us-east-1, enhancing meaning beyond the schema's type listing.
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?
Clearly states the verb 'Look up' and specific resource: on-demand Linux hourly and monthly price for AWS EC2 instance type in us-east-1. Distinguishes from sibling compare_clouds by focusing on single AWS instance pricing.
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?
Explicitly specifies when to use (on-demand Linux, us-east-1) and provides an alternative (use compare_clouds for multi-cloud comparisons). Clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up the on-demand Linux hourly + monthly price for an Azure VM size in eastus. Returns vCPUs, memory, hourly USD, and monthly USD.
| Name | Required | Description | Default |
|---|---|---|---|
| vm_size | Yes | Azure VM size, e.g. 'D4s_v5'. Available: B1s, B2ms, B2s, B4ms, D16s_v5, D2s_v5, D4s_v5, D8s_v5, E2s_v5, E4s_v5, E8s_v5, F2s_v2, F4s_v2, F8s_v2 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description discloses that it returns specific fields (vCPUs, memory, hourly/monthly USD) for on-demand Linux pricing. It is transparent about the read-only nature of a lookup.
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?
Single sentence, front-loaded with the action, and includes all essential details without waste. Every word adds value.
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?
Despite no output schema, the description fully specifies return values. The tool is simple with one enumerated parameter, and the description covers all necessary context for correct invocation.
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% for the single parameter. The description adds meaning by specifying region (eastus), OS (Linux), and pricing model (on-demand), which are not in the schema but are critical for correct usage.
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 clearly states the tool looks up Azure VM pricing for a specific VM size in the eastus region, returning vCPUs, memory, and costs. It distinguishes from sibling tools by specifying Azure and the region.
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 description implies when to use (need Azure VM pricing in eastus) and the siblings include other cloud providers for context. It does not explicitly list exclusions or alternatives but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up the on-demand Linux hourly + monthly price for a GCP Compute Engine machine type in us-east1. Returns vCPUs, memory, hourly USD, and monthly USD.
| Name | Required | Description | Default |
|---|---|---|---|
| machine_type | Yes | GCP machine type, e.g. 'e2-standard-4'. Available: c2-standard-4, c2-standard-8, e2-medium, e2-micro, e2-small, e2-standard-16, e2-standard-2, e2-standard-4, e2-standard-8, n2-highcpu-4, n2-highmem-2, n2-highmem-4, n2-standard-2, n2-standard-4, n2-standard-8 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the region (us-east1), OS (Linux), and pricing type (on-demand), but does not mention that the machine type list is limited to the enum values or any caching/real-time 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?
The description is concise, consisting of two sentences that front-load the action and context, then list the returned fields. No redundant information is present.
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 lookup tool with one parameter and no output schema, the description covers the return fields adequately. However, it does not mention the restriction to us-east1 and Linux, which could mislead users expecting other regions or OS options.
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% for the single parameter, so the schema fully documents it. The description adds no further meaning beyond stating 'machine type'; the schema's enum provides the specific allowed values.
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 clearly states the verb 'look up', the specific resource 'GCP Compute Engine machine type', and context 'on-demand Linux hourly + monthly price in us-east1'. It also lists the return fields, differentiating it from sibling tools like get_aws_price and get_azure_price.
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 description implies usage for retrieving GCP VM pricing but does not explicitly state when to use this tool versus alternatives like assess_migration or compare_clouds. It offers no guidance on exclusions such as other regions or OS types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute per-scenario cost / savings / payback for compute commitment options (none, 1yr_no_upfront, 1yr_all_upfront, 3yr_no_upfront, 3yr_partial_upfront, 3yr_all_upfront). Returns each scenario's monthly cost, upfront, 3-year total, savings %, and payback months — plus the recommended scenario by lowest 3-year TCO. Compute-only (storage / database / object / egress are not discounted because most clouds don't offer meaningful commitments on these). Per-family RI tiers come in v0.6.x; v0.6.0 uses cloud-level conservative averages.
| Name | Required | Description | Default |
|---|---|---|---|
| cloud | No | Cloud to evaluate (default: source_cloud, then 'aws'). | |
| egress | No | ||
| compute | Yes | ||
| storage | No | ||
| multi_az | No | ||
| one_time | No | ||
| databases | No | ||
| scenarios | No | Subset of commitment scenarios to evaluate. Default: all 6. | |
| source_cloud | No | Cloud the workload currently runs on. | |
| object_storage | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behavioral traits: compute-only evaluation, no discounts for storage/database/egress, returns recommended scenario by lowest 3-year TCO. Also notes versioning (v0.6.0 uses cloud-level averages, per-family tiers in v0.6.x). No annotation contradiction. Could mention input validation or error states, but overall transparent for a non-destructive tool.
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?
Description is a single informative paragraph that efficiently covers purpose, scope, scenarios, output, and limitations. No wasted sentences. Could be split into bullet points for readability, but current structure is acceptable and front-loaded.
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?
Given 10 parameters, nested objects, and no output schema, the description provides essential context but lacks complete guidance. It explains output and scope but does not clarify required parameters (only compute) or the structure of nested inputs. Missing details on return format beyond text. Adequate but not comprehensive.
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 only 30%, so description must compensate. The description adds context about scenarios and output, but does not explain individual parameters beyond listing scenario options. For example, it does not clarify that 'compute' array requires vcpus and memory_gb or that 'cloud' defaults to source_cloud then 'aws' (though schema has some descriptions). Partial compensation.
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?
Clearly states it computes per-scenario cost/savings/payback for compute commitment options, lists specific scenarios and return fields (monthly cost, upfront, 3-year total, savings %, payback months, recommended scenario). Distinct from sibling tools like compare_total_cost_of_ownership by focusing specifically on commitment options for compute.
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?
Implies use for commitment decision-making but does not explicitly state when to use this tool versus alternatives like compare_total_cost_of_ownership. Mentions compute-only scope and that per-family RI tiers are not yet available, which gives some guidance on limitations but lacks direct comparison guidance.
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.
v0.6.0assess_migrationcompare_total_cost_of_ownershipfind_egress_arbitrageoptimize_commitmentv0.5.0compare_compute_inventory1 field changedInput schema / properties / workloads / items / properties / os_disk_snapshot_incremental_factorAdded value: +{
+ "default": 1,
+ "description": "Multiplier on OS-disk snapshot upper-bound cost. 1.0 = full, 0.3 = typical incremental, 0.0 = exclude. Defaults to 1.0.",
+ "maximum": 1,
+ "minimum": 0,
+ "type": "number"
+}compare_egresscompare_storage_inventory1 field changedInput schema / properties / volumes / items / properties / snapshot_incremental_factorAdded value: +{
+ "default": 1,
+ "description": "Multiplier on the upper-bound snapshot cost. 1.0 = full upper-bound (each snapshot full capacity). 0.3 = typical real-world incremental dedup (~30%). 0.0 = exclude snapshots from total. Defaults to 1.0 for backward compatibility.",
+ "maximum": 1,
+ "minimum": 0,
+ "type": "number"
+}compare_workload3 fields changedInput schema / properties / compute / items / properties / os_disk_snapshot_incremental_factorAdded value: +{
+ "default": 1,
+ "description": "Multiplier on OS-disk snapshot upper-bound cost. 1.0 = full, 0.3 = typical incremental, 0.0 = exclude. Defaults to 1.0.",
+ "maximum": 1,
+ "minimum": 0,
+ "type": "number"
+}Input schema / properties / multi_azAdded value: +{
+ "default": false,
+ "description": "If true, double compute cost on every cloud to model Multi-AZ / HA deployments (sync replicas across two zones). Storage stays at 1x because object/block storage is usually cross-AZ at base price already.",
+ "type": "boolean"
+}Input schema / properties / storage / items / properties / snapshot_incremental_factorAdded value: +{
+ "default": 1,
+ "description": "Multiplier on the upper-bound snapshot cost. 1.0 = full upper-bound (each snapshot full capacity). 0.3 = typical real-world incremental dedup (~30%). 0.0 = exclude snapshots from total. Defaults to 1.0 for backward compatibility.",
+ "maximum": 1,
+ "minimum": 0,
+ "type": "number"
+}v0.3.0compare_object_storagecompare_postgres_databasev0.2.2compare_cloudscompare_compute_inventorycompare_storage_inventorycompare_workloadget_aws_priceget_azure_priceget_gcp_priceScored across 14 tools
Most tools have clearly distinct purposes: compare_clouds for single VM, compare_compute_inventory for bulk compute, compare_workload for combined compute+storage, etc. However, assess_migration and compare_total_cost_of_ownership overlap in projecting workload costs, and compare_workload overlaps with separate inventory tools, causing minor ambiguity.
Names follow a mostly consistent pattern: 'compare_' for multi-cloud comparisons, 'get_' for single-cloud lookups, and specialized verbs like 'assess_', 'find_', 'optimize_'. Minor variations exist (e.g., compare_total_cost_of_ownership vs compare_clouds) but overall readable and predictable.
14 tools is well-scoped for a cloud pricing server. Each tool covers a distinct pricing scenario (single VM, bulk compute, storage, egress, databases, migration, TCO, commitment), avoiding redundancy without missing critical functionality.
The tool set covers core compute, storage, egress, database, migration, and TCO scenarios. Notable gaps include non-PostgreSQL databases, serverless compute, and advanced networking costs (e.g., VPC peering, load balancers). Descriptions acknowledge missing features, which agents can work around.
Hosted MCP server for LLM cost estimation, model comparison, and budget-aware routing.
Hosted Amazon Seller and Vendor MCP server for Claude, ChatGPT, Cursor, Codex, Gemini, Copilot.
Hosted MCP server for AWS cloud spend: service breakdowns, anomalies, savings and forecasts.
Cloud-hosted MCP server for durable AI memory
