OpenCloudCosts MCP

Overview Schema Related Servers Score Discussions

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.3.1
Disambiguation5/5
Every tool has a clearly distinct purpose. While several tools deal with pricing (get_price, compare_prices, find_cheapest_region, etc.), their specific functions are well-defined and non-overlapping, preventing confusion.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., compare_prices, describe_catalog, list_instance_types). The naming is predictable and clear, with only minor stylistic variations (get vs list) that are standard.
Tool Count5/5
15 tools is appropriate for a cloud cost server. The set covers core queries, comparisons, batch operations, catalog discovery, and utilities without being overwhelming. Each tool serves a clear purpose and earns its place.
Completeness5/5
The tool surface is comprehensive for cloud pricing: single and batch price queries, region comparison, instance type discovery, catalog help, unit economics, BOM estimation, and spot history. It covers the full lifecycle of pricing analysis with no obvious gaps.
Average 4.2/5 across 15 of 15 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 248 commits in the last 12 weeks
- Last stable release on July 9, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the core purpose without mentioning authentication, rate limits, or whether results are paginated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: one sentence for purpose followed by clear arg definitions. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple tool but lacks details on what 'available' means and how it relates to sibling tools. Output schema exists but return values are not described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds meaningful parameter explanations (provider: aws/gcp/azure, domain: compute/storage/database) that compensate for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists regions for a given provider. However, it does not explicitly differentiate from sibling tools like find_available_regions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings like find_available_regions or find_cheapest_region. No conditions or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 implies read-only behavior ('return statistics') but does not disclose if the call has side effects, permissions required, or if the stats are real-time. It is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has zero parameters and an output schema exists (not provided), the description offers minimal context about the return value ('entry counts, DB size'). It is adequate for a simple stats tool but could be more informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the description adds no parameter information. Baseline 4 is appropriate per the rubric.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns statistics about the local pricing cache, specifying 'entry counts, DB size'. The verb 'return' and resource 'local pricing cache' are precise, and it distinguishes from sibling tools like refresh_cache which modify the cache.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when or when not to use this tool. It does not mention when querying cache stats is appropriate, nor does it contrast with alternatives like 'refresh_cache'. The context must be inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description holds the burden. It describes the estimation behavior and input format but does not state side effects (e.g., read-only, no modifications). As an estimation tool, likely idempotent, but not explicitly disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise: a clear purpose sentence followed by parameter definitions. No redundant information, well-structured with Args section.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters, no annotations, and presence of output schema, description adequately covers input semantics and cross-references estimate_bom. It does not describe return values, but output schema likely handles that. Slight gap in not explaining output format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description adds meaning: clarifies items format (PricingSpec dicts with quantity), units_per_month as monthly volume, unit_label with default 'user' and examples. This compensates well for missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'estimate' and resource 'per-unit economics', with specific examples (cost per user/request/transaction). It implies differentiation from sibling estimate_bom but does not explicitly contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description indicates when to use: for per-unit cost estimation given BOM and volume. It references estimate_bom for item format but does not explain when not to use this tool versus alternatives like estimate_bom or get_price.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions invalidation but lacks details on whether the operation is reversible, the scope of cache cleared (all or per provider), and what 'expired entries' means. More context is needed for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences covering purpose and parameter usage. No superfluous content; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (1 parameter) and presence of an output schema, the description is adequate but could benefit from clarifying that the effect is immediate and affects subsequent queries. Otherwise, it sufficiently covers the tool's functionality.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds value by specifying valid provider values ('aws', 'gcp', 'azure') and the behavior for an empty string (purge expired entries). This goes beyond the schema, which only defines type and default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool invalidates the pricing cache to force fresh data on next request. The verb 'invalidate' and resource 'pricing cache' are specific, and it distinguishes from siblings like 'cache_stats' which likely shows cache status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when fresh pricing data is needed but does not provide explicit guidance on when to use vs alternatives, such as checking cache age via 'cache_stats' first. It also lacks scenarios where this tool should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It mentions that credentials and a specific environment variable are required. However, it does not state whether the operation is read-only, idempotent, or any rate limits. The description is adequate but could be more explicit about safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at three sentences plus a bullet-like line. The main purpose is front-loaded. The structure could be improved by separating theArgs line more clearly, but overall it is efficient and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description need not detail return values. It already lists what is returned for AWS. The tool has one optional parameter, and the description covers the prerequisite. This is sufficient for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one string parameter 'provider' with a default and no description. The description adds value by specifying that only 'aws' is valid now and mentioning future GCP support. This clarifies the parameter's allowed values beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns a summary of active cloud discounts, specifying AWS details (Savings Plans, Reserved Instances, Cost Explorer). The verb 'Return a summary' and resource 'active cloud discounts' are specific and distinguishable from sibling tools, none of which cover discounts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions prerequisites: credentials and the environment variable OCC_AWS_ENABLE_COST_EXPLORER=true for AWS. It also notes that only AWS is currently supported, implying when not to use for other providers. However, it does not explicitly state alternatives or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses concurrent fetching, sorting cheapest first, % delta inclusion, and optional baseline region comparison. This provides solid behavioral detail beyond basic read or write hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a clear purpose sentence, a behavioral note, then listed arguments. Every sentence adds value without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, return value details are not needed. The description covers input parameters, concurrency, sorting, delta, and baseline. It could mention potential limits (e.g., number of regions) or prerequisites, but overall it's sufficiently complete for a comparison tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description compensates well. For 'spec', it explains it's a PricingSpec dict like get_price and notes region override. 'regions' is clarified with an example list. 'baseline_region' includes purpose. Meaning is added beyond the basic schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Compare pricing for any service across multiple regions' with a specific verb and resource. It distinguishes itself from siblings like get_price, get_prices_batch, and find_cheapest_region by focusing on cross-region comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need to compare pricing across regions, but lacks explicit guidance on when to use this tool versus alternatives such as find_cheapest_region or get_prices_batch. No when-not-to-use or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses 'cheapest first' ordering and that region in spec is overridden. Lacks mentions of rate limits, auth, or edge cases (e.g., behavior when service not found).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, front-loaded with main purpose. Each sentence adds value: purpose, spec reuse, region usage, baseline option. No extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three parameters (one required, one nested object) and an output schema, description covers key aspects. Does not explain output schema structure but that is handled by schema itself. Suffers slightly from missing explicit sibling usage guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but description compensates by explaining spec as 'same as get_price' and region override, regions parameter usage, and baseline_region purpose. Could further detail spec structure, but references get_price as baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Find all regions where a specific service/instance type is available, cheapest first.' Uses specific verb-resource pair and ordering, differentiating from siblings like find_cheapest_region (which returns only the cheapest) and compare_prices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on spec parameter (same as get_price, region overridden) and regions parameter (omit for major, 'all' for full scan). Mentions baseline_region for delta comparison. Missing explicit differentiation from siblings like find_cheapest_region or compare_prices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 that pricing is queried concurrently, results are sorted cheapest first, and a delta is calculated. It also notes that the region field in the spec is overridden. However, it does not mention idempotency, rate limits, or caching behavior (though cache_stats sibling suggests caching exists).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately sized, starting with a clear title line, then a brief explanation, followed by an Args section with bullet points. It is front-loaded with the main purpose. A few words could be trimmed, but overall it is efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists (context signal), the description mentions only that results are sorted cheapeast first with a price delta. It lacks details about the output structure, formats, or edge cases. Given the complexity of nested input and 0% schema coverage, the description could be more complete about caching and performance implications.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description explains each parameter: spec is a PricingSpec dict (same as get_price) with region overridden; regions can be omitted, a list, or ['all'] with speed implications; baseline_region is optional for delta. The spec parameter is not detailed but references get_price, which is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Find the cheapest region for any cloud service.' It specifies the verb 'find' and the resource 'cheapest region', and explains concurrent querying and sorting behavior. The purpose is distinct from siblings like get_price, compare_prices, and find_available_regions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage guidance: 'Omit for major regions (faster). Pass ["all"] to search every available region' and mentions baseline_region for delta comparison. It implies when to use each parameter variant, but does not explicitly state when not to use this tool or provide alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It describes the return values (public_prices[] always, contracted_prices[], effective_price, auth_available=true when auth exists) but does not mention side effects, rate limits, error handling, or other behaviors. It is partially transparent but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but well-organized with sections for each domain and bullet-style field requirements. It includes multiple examples. While it could be slightly more concise, the complexity of the tool justifies the length, and the structure aids readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the existence of an output schema (so return details need not be in description), the description is thorough. It covers all domains, references a sibling tool (describe_catalog) for additional guidance, and provides concrete examples that an agent can copy. The context is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines only a generic spec object with additionalProperties: true, providing zero semantic guidance. The description compensates fully by detailing domain-specific required fields (e.g., for COMPUTE, STORAGE, DATABASE, AI, etc.) with concrete key-value pairs and examples, massively adding value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines get_price as a unified pricing tool that returns public catalog rates and contracted/effective prices. It distinguishes itself from sibling tools like compare_prices and find_cheapest_region by focusing on precise pricing for specific configurations and requiring a spec dict with provider, domain, and region.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states minimum required fields (provider, domain, region) and that domain-specific fields are needed, directing users to describe_catalog for the complete list. It provides multiple examples. However, it does not explicitly state when not to use this tool versus alternatives, though the examples and context imply its specific purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 mentions 'fetches all prices concurrently', which is a useful behavioral trait. However, it does not disclose response format, error handling, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with an introductory sentence, a use-case sentence, and a clear Args list. It is front-loaded with the purpose. The Args section adds length, but each line is earned.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters (3 required), an output schema, and sibling tools, the description covers the input semantics and use case well. However, it lacks details on handling partial failures, pagination, or response structure beyond what the output schema provides.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description includes a detailed Args section explaining each parameter (provider, instance_types, region, os, term) with examples and defaults, adding significant meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs and resources: 'Get prices for multiple compute instance types in a single region'. It clearly distinguishes from sibling tools like 'get_price' (single instance) and 'compare_prices' (likely cross-provider comparison).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states it's 'useful for comparing a shortlist of candidate instance types' and that it 'fetches all prices concurrently' to avoid separate calls. While it gives clear context, it does not explicitly state when not to use it or name alternatives beyond implication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description clearly indicates a read-only list operation with filtering. Does not mention side effects or return format, but output schema exists to cover return structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise description with front-loaded purpose and structured Args section. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, and parameters well. Could mention default values or behavior of max_results, but it is already documented. Good overall for a 7-parameter tool with output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but the description thoroughly explains each parameter with examples and usage context, adding significant value beyond the property titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'List' and resource 'compute instance types' with optional filters. Distinguishes from sibling tools like compare_prices and search_pricing by focusing on instance type discovery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the tool is useful for discovering instances before fetching pricing or for meeting specific requirements. Could be improved by explicitly stating when not to use it, but the context provides sibling alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 explains that the tool returns a 'support matrix' or targeted guidance with specific fields like required_fields, supported_terms, filter_hints, and example_invocation, which is transparent and helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, using bullet points for argument combinations. Every sentence adds value, and there is no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no annotations, the description comprehensively covers all arguments, usage scenarios, and return values. It even mentions example_invocation, which aligns with the output schema. The tool's contextually complete given its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameters. It does so effectively, listing provider values ('aws', 'gcp', 'azure'), domain examples (compute, storage, etc.), and service examples (bedrock, rds, etc.), adding meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Discover what each provider supports and how to call get_price.' It differentiates from sibling tools like get_price and search_pricing by focusing on exploration and guidance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Use this before get_price when unsure of exact field names or values.' It also outlines behavior with different argument combinations, though it could mention when not to use (e.g., if you already know the exact fields).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description discloses provider-specific behavior and return structure. It could mention read-only nature but is otherwise transparent about supported providers and output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and well-structured: purpose first, then returns, then provider support, then parameters with examples. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive given output schema exists. Summarizes returns (per-AZ stats, volatility, stability, recommendation) and provider constraints. No missing critical information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds significant meaning beyond the schema: explains spec as PricingSpec dict with example, hours as lookback with default/max, availability_zone as filter. Schema coverage 0% so description is essential.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets spot price history and stability analysis for a compute instance type, listing specific return values. This distinguishes it from sibling tools that focus on on-demand pricing or other aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context on provider support (AWS requires credentials, GCP/Azure return not_supported), guiding when to use. Does not explicitly contrast with alternatives but implies use for spot pricing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes a search operation, which implies read-only and non-destructive behavior. However, it does not explicitly state safety or side-effect guarantees, but the nature of search is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a brief introductory sentence followed by a clear bullet list of parameters. Every sentence adds value and is well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 5 parameters and no schema descriptions, the description covers all parameters and provides usage context. It references an output schema (though not shown), so return values need not be explained. Complete for a search tool with good sibling differentiation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds meaning by explaining each parameter: provider (with example values), query (with examples), domain, region, and max_results (with default). This compensates fully for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it's a free-text search across the pricing catalog, distinguishes itself from get_price by noting it's useful before calling that tool, and provides examples. This differentiates it from siblings like compare_prices or get_price.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use: for exploring SKUs before get_price or for services not covered by a specific domain. Implicitly suggests not for exact price lookups (handled by get_price). Provides clear context with sibling references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully discloses behavior: returns per-item and total costs, real public pricing data, and a not_included list. Also explains input format requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured, front-loaded with purpose and guidelines, then behavioral notes, then parameter format, then examples. Every sentence adds value; no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity of multi-resource estimation, description covers input format, output structure, required follow-up actions, and examples. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% coverage, but description completely compensates by detailing the structure of items: PricingSpec dict with provider, domain, region, quantity, hours_per_month, etc., and provides examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it computes total infrastructure cost, TCO, monthly spend for multi-resource stacks. Distinguishes from get_price by explicitly saying not to use get_price for multi-resource questions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (multi-resource stack, cost comparison) and when not to (avoid get_price individually). Also gives important post-call instructions for not_included items.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![cloudcostsmcp MCP server](https://glama.ai/mcp/servers/x7even/cloudcostsmcp/badges/card.svg)](https://glama.ai/mcp/servers/x7even/cloudcostsmcp)

Score Badge

Copy to your README.md:

[![cloudcostsmcp MCP server](https://glama.ai/mcp/servers/x7even/cloudcostsmcp/badges/score.svg)](https://glama.ai/mcp/servers/x7even/cloudcostsmcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/x7even/cloudcostsmcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server