Infracost MCP Server

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct action: breakdown (cost estimate), diff (comparison), output (formatting), comment (posting), upload (cloud sync), configure (settings), auth (login), and generate_usage (usage templates). There is no ambiguity between them.
Naming Consistency5/5
All tools follow the consistent `infracost_<verb>` pattern, using snake_case throughout. Even though some verbs are nouns (output, breakdown), the prefix and lowercase snake_case make the set uniform and predictable.
Tool Count5/5
Eight tools is a well-scoped count for a cost-estimation server, covering core operations without bloat. Each tool serves a clear purpose in the workflow.
Completeness5/5
The domain (Infracost cost analysis) is fully covered: generating estimates, diffs, formatted output, PR comments, cloud upload, authentication, configuration, and usage file generation. No obvious gaps exist for the intended purpose.
Average 3.5/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 34 commits in the last 12 weeks
- Last stable release on March 8, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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 carry the full burden. It mentions 'sensible defaults' and 'pre-filled templates' but fails to disclose what happens to the generated file (e.g., whether it's saved, returned as output, or has side effects). The behavior of onlyJson, outputFilePath, and includeGuidance is not explained in the description, leaving significant gaps.
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 two concise sentences with no redundant information. It front-loads the core purpose and quickly adds the relationship to infracost_configure. Every word 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?
The tool has a simple function and the schema fully describes its parameters. However, there is no output schema and no annotation context. The description doesn't explain the return format, how the generated file is delivered, or how to use the output, leaving some ambiguity about the tool's overall behavior. It is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all four parameters, including resource types and usage file options. The description adds a small amount of context about 'sensible defaults' and 'pre-filled templates', but overall does not meaningfully enhance the parameter understanding beyond the schema.
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 generates an Infracost usage file for specified resource types, using a specific verb ('Generate') and object ('usage file'). It also differentiates itself by mentioning it complements infracost_configure, though it doesn't distinguish from all siblings.
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 context by stating it 'Complements infracost_configure by providing pre-filled templates', indicating a relationship with that tool. However, it doesn't explicitly state when to use this tool versus alternatives like breakdown or diff, nor does it provide exclusions or clear use-case guidance.
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 only gives a high-level purpose ('Generate cost breakdown... Shows cost estimates') and omits important details such as API key requirements, execution of terraform plan, output formats, or potential side effects. This is a significant gap for a tool with no annotation support.
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 two concise sentences that are front-loaded with the core purpose. Every word adds value without redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (14 parameters, no output schema, no annotations), the description is too thin. It does not explain return value structure, setup prerequisites, or typical usage patterns. A more complete description should clarify what the output looks like and any execution context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all 14 parameters (100% coverage), so the description adds little beyond that. It mentions 'Terraform, CloudFormation, etc.' which gives context for the path parameter, but this is already implied by the schema. Baseline 3 is appropriate.
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 function: generating cost breakdowns for Infrastructure as Code. It uses a specific verb ('Generate') and resource ('cost breakdown'), distinguishing it from sibling tools like diff, upload, and output.
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 the tool is for producing cost estimates from IaC, but it does not explicitly state when to use it versus alternatives like infracost_diff or infracost_output. There is no mention of exclusions or comparison with sibling tools.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'get or set' without explaining side effects, persistence of changes, or potential exposure of sensitive data like the API key. This is a significant gap for a tool that can read and write configuration.
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, front-loaded with the verb, and contains no unnecessary information. It is highly concise and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has six parameters, no output schema, and no annotations, the description is insufficiently complete. It does not describe return values, the behavior when both get and set are provided, or any side effects, leaving an agent without critical context for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with descriptions for all six parameters, so the baseline is 3. The description adds minimal context with examples like 'api_key' and 'currency', but does not clarify the relationship between get, set, and apiKey parameters, or how they interact.
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 or sets Infracost configuration options, using a specific verb and resource. It distinguishes itself from sibling tools like infracost_breakdown or infracost_diff, which focus on cost analysis rather than configuration.
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 for configuration management but does not explicitly state when to use this tool versus alternatives, such as infracost_auth for API key handling. It lacks clear 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.
Behavior2/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 of behavioral disclosure. It does not mention side effects, whether the operation is read-only, how output is delivered (stdout, file), or authentication requirements (despite an apiKey parameter). The description restates the function without adding operational context.
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, focused sentence that states the core purpose and provides three concrete examples of formats. It is concise, front-loaded, and contains no filler or redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters, no output schema, and no annotations, the one-sentence description is insufficient. It omits details about how the path is resolved, what fields control, what the output looks like, or any execution context. The description is too sparse for an agent to fully understand the tool's behavior and requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 8 parameters have descriptions in the input schema, giving 100% schema coverage. The description itself adds no additional parameter semantics—it only mentions output formats, which aligns with the 'format' parameter but does not enrich understanding. Baseline of 3 is appropriate since the schema already documents parameters.
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 a specific verb 'Format' and clearly identifies the resource 'Infracost JSON output' while listing example output formats (table, html, github-comment). This distinguishes it from sibling tools like infracost_breakdown or infracost_diff, which focus on generating or comparing cost data rather than reformatting output.
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 this tool is used when Infracost JSON output needs to be converted to another format, but it does not explicitly state when to use it versus alternatives like infracost_diff or infracost_comment. There are no exclusions, prerequisites, or alternative tool mentions, so usage context is only implied.
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?
The description discloses the browser-based login flow, which is a useful behavioral trait. However, with no annotations, it omits other relevant behaviors such as the ability to use an API key, potential blocking behavior, or failure modes.
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 concise two sentences that front-load the action and add no unnecessary detail. Every word 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?
The description covers the core purpose and primary login method but omits the apiKey alternative and the tool's role as a prerequisite for sibling commands. Given the simplicity of the tool, these gaps are noticeable but not fatal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all four parameters, so the description itself adds no additional parameter semantics. The baseline of 3 applies since the schema already provides the necessary detail.
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 authenticates with Infracost Cloud and opens a browser for login flow, using a specific verb and resource. This distinguishes it from sibling tools that perform cost analysis, uploads, or diffs.
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 is provided on when to use this tool versus alternatives, such as whether authentication is required before running other infracost commands. The description gives no explicit context or exclusions.
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 carries the full burden of disclosing behavior. It only states 'Upload', which implies a network write, but does not mention authentication requirements, file handling, or potential side effects. This is a significant gap for a mutation-like tool without annotation support.
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, front-loaded sentence that states the action and purpose without extra words. It is appropriately concise and 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?
The schema provides rich parameter details, but the description lacks guidance on when to use this tool versus sibling tools and does not address behavioral aspects like authentication or side effects. Given the tool has 5 optional parameters, a bit more contextual narrative would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all 5 parameters, so the schema fully documents each parameter. The description adds no additional parameter-specific meaning, warranting the baseline of 3.
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 a specific verb 'Upload' and identifies the resource ('Infracost JSON output') and destination ('Infracost Cloud'), clearly differentiating this from sibling tools like breakdown or diff. The phrase 'for centralized cost visibility and reporting' adds purpose.
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 its use case—uploading Infracost JSON output for centralized reporting—but does not explicitly state when to use it vs. alternatives or mention any exclusions. Given the presence of sibling tools, this lack of differentiation guidance leaves some ambiguity.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It conveys the core side effect ('post'), but omits important context such as the need for authentication tokens, the ability to update/delete comments via the 'behavior' parameter, or that 'dryRun' prevents actual posting. This leaves the agent without critical details about how the tool modifies external resources.
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, compact sentence that immediately states the tool's action, target, and supported platforms. It is front-loaded and contains no redundant or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 13 parameters and no output schema, the description is too thin. It does not explain the expected workflow (e.g., whether a prior Infracost breakdown is needed), the behavior of the comment (create/update/delete), or any prerequisites like tokens. The schema documents parameters but not the overall operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional parameter semantics beyond the schema; it does not reinforce or clarify parameter usage. However, the schema's own descriptions are thorough, so the description doesn't need to compensate.
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 with a specific verb ('Post') and resource ('cost estimate comments to pull requests'), explicitly naming four supported platforms. This distinguishes it from sibling tools like infracost_breakdown or infracost_diff, which serve different functions.
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 implies when to use the tool (when you need to post cost estimates to PRs) and names the supported platforms, providing clear context. However, it does not explicitly mention alternatives or exclusions, such as when to use infracost_diff or infracost_output instead.
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 full burden of behavioral disclosure. The word 'Show' implies a read-only operation, but the description does not mention that it may run terraform plan, require an API key, or have network side effects. It adds minimal behavioral context beyond the operation's purpose.
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 two sentences long, front-loading the primary function and then adding relevant use-case context. Every sentence contributes meaning with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 13 parameters, no annotations, and no output schema, the description is far too brief. It does not explain how the diff is computed, prerequisites like an API key, relationship to sibling commands, or expected output format, making it inadequate for reliable agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all 13 parameters having descriptions in the input schema, so the baseline is 3. The tool description itself does not add any parameter-specific meaning, but the schema already fulfills this need.
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 function with a specific verb 'Show' and resource 'cost diff between current IaC and planned changes'. This distinguishes it from sibling tools like infracost_breakdown, and the mention of pull request reviews adds concrete scope.
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 clear context by noting it is 'Useful for pull request reviews to understand cost impact', giving a specific when-to-use scenario. However, it does not mention alternatives or when not to use the tool, so it lacks explicit exclusion guidance.
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

$infracost-mcp MCP server$

Copy to your README.md:

[![infracost-mcp MCP server](https://glama.ai/mcp/servers/DownAtTheBottomOfTheMoleHole/infracost-mcp/badges/card.svg)](https://glama.ai/mcp/servers/DownAtTheBottomOfTheMoleHole/infracost-mcp)

Score Badge

$infracost-mcp MCP server$

Copy to your README.md:

[![infracost-mcp MCP server](https://glama.ai/mcp/servers/DownAtTheBottomOfTheMoleHole/infracost-mcp/badges/score.svg)](https://glama.ai/mcp/servers/DownAtTheBottomOfTheMoleHole/infracost-mcp)

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/DownAtTheBottomOfTheMoleHole/infracost-mcp'

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