How do I use Infracost MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Infracost MCP Server estimate the cost of my Terraform project" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Infracost MCP Server

by DownAtTheBottomOfTheMoleHole

Overview Schema Related Servers Score Discussions

TypeScript

Infracost MCP Server

CI/Publish Coverage npm License: MIT Node Version

Note: This is a community-maintained MCP server. It is not an official Model Context Protocol server from Infracost.

A Model Context Protocol (MCP) server for running the Infracost CLI to estimate, compare, and publish infrastructure cost changes from Terraform and other Infrastructure as Code projects.

Overview

This server provides eight MCP tools across estimation, reporting, collaboration, and operations workflows:

infracost_breakdown to generate baseline cost estimates.
infracost_diff to compare planned cost changes.
infracost_output to render existing Infracost JSON in different formats.
infracost_comment to post PR comments on supported SCM platforms.
infracost_upload to upload reports to Infracost Cloud.
infracost_configure to get or set CLI configuration.
infracost_auth to run authentication flow.
infracost_generate_usage to generate usage files with sensible defaults.

Platform Compatibility

This MCP server is platform-agnostic and works in local and CI environments:

Local development
GitHub Actions
GitLab CI/CD
Azure DevOps
CircleCI, Jenkins, and Bitbucket Pipelines
AI Agents and Copilot workflows

The primary requirements are Node.js and the Infracost CLI binary.

Tool Matrix

Tool	Category	Typical outcome
`infracost_breakdown`	Estimation	Monthly cost baseline for current IaC
`infracost_diff`	Comparison	Cost delta from a planned change
`infracost_output`	Reporting	Rendered table/JSON/HTML/comment output
`infracost_comment`	Collaboration	PR comment with estimated impact
`infracost_upload`	Cloud Sync	Cost report visible in Infracost Cloud
`infracost_configure`	Configuration	Persisted CLI config update/read
`infracost_auth`	Authentication	Login flow for Infracost Cloud
`infracost_generate_usage`	Utilities	Pre-filled usage file template with defaults

Related MCP server: Azure FinOps Elite

Tools

`infracost_breakdown`

Runs infracost breakdown.

Inputs:

workingDirectory (string, optional): Command working directory.
path (string, optional): Path to Terraform/IaC directory or plan JSON.
configFile (string, optional): Path to Infracost config file.
usageFile (string, optional): Path to usage file.
format (string, optional): Output format. Default: table.
fields (string[], optional): Fields to include in output.
showSkus (boolean, optional): Include SKU details.
syncUsageFile (boolean, optional): Sync usage file with detected resources.
compareTo (string, optional): Baseline Infracost JSON path.
terraformWorkspace (string, optional): Terraform workspace.
terraformPlanFlags (string, optional): Flags for terraform plan.
timeoutSeconds (number, optional): Timeout in seconds.
extraArgs (string[], optional): Additional CLI arguments.

`infracost_diff`

Runs infracost diff.

Inputs:

workingDirectory (string, optional): Command working directory.
path (string, optional): Path to Terraform/IaC directory or plan JSON.
configFile (string, optional): Path to Infracost config file.
usageFile (string, optional): Path to usage file.
format (string, optional): Output format. Default: table.
compareTo (string, optional): Baseline Infracost JSON path.
showSkus (boolean, optional): Include SKU details.
syncUsageFile (boolean, optional): Sync usage file with detected resources.
terraformWorkspace (string, optional): Terraform workspace.
terraformPlanFlags (string, optional): Flags for terraform plan.
timeoutSeconds (number, optional): Timeout in seconds.
extraArgs (string[], optional): Additional CLI arguments.

`infracost_output`

Runs infracost output.

Inputs:

workingDirectory (string, optional): Command working directory.
path (string, optional): Infracost JSON file path. Auto-detected when omitted.
format (string, optional): Output format. Default: table.
fields (string[], optional): Fields to include in output.
showSkus (boolean, optional): Include SKU details.
timeoutSeconds (number, optional): Timeout in seconds.
extraArgs (string[], optional): Additional CLI arguments.

`infracost_comment`

Runs infracost comment.

Inputs:

workingDirectory (string, optional): Command working directory.
platform (string, optional): Platform (github, gitlab, azure-repos, bitbucket). Default: github.
path (string, optional): Infracost JSON file path. Auto-detected when omitted.
repo (string, optional): Repository (owner/repo).
pullRequest (string, optional): Pull request number.
commit (string, optional): Commit SHA.
token (string, optional): Platform token.
tag (string, optional): Comment tag.
behavior (string, optional): Comment update behavior.
dryRun (boolean, optional): Generate without posting.
timeoutSeconds (number, optional): Timeout in seconds.
extraArgs (string[], optional): Additional CLI arguments.

`infracost_upload`

Runs infracost upload.

Inputs:

workingDirectory (string, optional): Command working directory.
path (string, optional): Infracost JSON file path. Auto-detected when omitted.
timeoutSeconds (number, optional): Timeout in seconds.
extraArgs (string[], optional): Additional CLI arguments.

`infracost_configure`

Runs infracost configure.

Inputs:

workingDirectory (string, optional): Command working directory.
set (string, optional): Set configuration value.
get (string, optional): Read configuration value.
timeoutSeconds (number, optional): Timeout in seconds.
extraArgs (string[], optional): Additional CLI arguments.

`infracost_auth`

Runs infracost auth login.

Inputs:

workingDirectory (string, optional): Command working directory.
timeoutSeconds (number, optional): Timeout in seconds.
extraArgs (string[], optional): Additional CLI arguments.

`infracost_generate_usage`

Generates an Infracost usage file with sensible defaults for specified resource types. This is a utility tool that complements infracost_configure by providing pre-filled templates you can customize for your workloads. Returns both raw JSON and formatted guidance.

Inputs:

resourceTypes (string[], required): Resource types to include (e.g., ["aws_lambda_function", "aws_s3_bucket"]).
outputFilePath (string, optional): Path where usage file should be saved (for guidance only).
includeGuidance (boolean, optional): Include formatted guidance. Default: true.
onlyJson (boolean, optional): Return only raw JSON (no guidance). Default: false.

Supported resource types: aws_lambda_function, aws_instance, aws_db_instance, aws_s3_bucket, aws_dynamodb_table, aws_ebs_volume, aws_cloudfront_distribution, aws_lb, aws_nat_gateway, google_compute_instance, google_storage_bucket, azurerm_windows_virtual_machine, azurerm_linux_virtual_machine, azurerm_storage_account, azurerm_mssql_database.

Prompt Cookbook

Use these minimal prompts in Copilot Chat with @infracost. CLI tools default to the current workspace root when no path is given. If you add a file or folder as Copilot context (#file or #folder), reference it in your prompt and the tool will target that path. The server auto-detects common report files (infracost-diff.json, infracost-base.json, infracost.json), so you usually do not need to pass path for infracost_output, infracost_comment, or infracost_upload.

Quick prompts

@infracost run infracost_breakdown
@infracost run infracost_diff
@infracost run infracost_output
@infracost run infracost_comment with dryRun true
@infracost run infracost_upload

Run breakdown (`infracost_breakdown`)

@infracost run infracost_breakdown

Expected output: Baseline cost estimate with command output, exit code, stdout, and stderr.

Run diff (`infracost_diff`)

@infracost run infracost_diff

Expected output: Cost delta from the planned change compared to current baseline.

Render output (`infracost_output`)

@infracost run infracost_output with format html

Expected output: Formatted output from existing Infracost JSON (auto-detected when possible).

Post PR comment (`infracost_comment`)

@infracost run infracost_comment with repo owner/repo and pullRequest 123 and dryRun true

Expected output: Generated comment payload, or posted comment when not in dry-run mode. Platform defaults to github.

Upload report (`infracost_upload`)

@infracost run infracost_upload

Expected output: Upload confirmation for Infracost Cloud ingestion.

Configure CLI (`infracost_configure`)

@infracost run infracost_configure with:
- set: currency=USD

Expected output: Configuration update confirmation from the CLI.

Authenticate (`infracost_auth`)

@infracost run infracost_auth

Expected output: Authentication flow prompt or login success details.

Generate usage file (`infracost_generate_usage`)

@infracost run infracost_generate_usage with:
- resourceTypes: ["aws_lambda_function", "aws_s3_bucket", "aws_dynamodb_table"]
- outputFilePath: ./infracost-usage.json
- includeGuidance: true

Expected output: Pre-filled usage file JSON with sensible defaults, plus guidance on customization and usage. Use onlyJson: true to return only the JSON for programmatic handling.

Dependencies

System Dependencies

Node.js >=24.14.0
npm (bundled with Node.js)
Infracost CLI installed and available in PATH (or via INFRACOST_BINARY_PATH)

npm Dependencies

Runtime:

@modelcontextprotocol/sdk (MCP server SDK)

Development:

typescript (build/compile)
tsx (development runner)
vitest (unit test runner)
@types/node (Node.js typings)

Environment Variables

INFRACOST_API_KEY: Infracost API key for cloud-backed features.
INFRACOST_BINARY_PATH: Override path to Infracost binary.

Installation

npm install
npm run build

Configuration

Usage with VS Code Copilot Chat

This workspace is preconfigured in .vscode/mcp.json:

{
  "servers": {
    "infracost": {
      "type": "stdio",
      "command": "node",
      "args": ["./dist/index.js"]
    }
  }
}

Reload VS Code (Cmd+Shift+P -> Developer: Reload Window) after changing MCP configuration.

Then query the server from Copilot Chat with @infracost, for example:

@infracost run infracost_breakdown
@infracost run infracost_diff

Usage with Other MCP Clients

Use stdio transport with the built entrypoint:

{
  "name": "infracost-mcp-server",
  "type": "stdio",
  "command": "node",
  "args": ["/absolute/path/to/infracost-mcp/dist/index.js"]
}

Build first with npm run build, then start your MCP client.

Running

npm start

Development mode:

npm run dev

Built mode:

npm run start

Debugging

Use .vscode/launch.json:

Debug MCP Server (runs npm run dev)
Debug MCP Server (Built) (runs dist/index.js after build)

Set breakpoints in src/index.ts, then press F5.

Testing

See docs/TESTING.md for Copilot Chat scenarios, manual JSON-RPC checks, and troubleshooting guidance.

Quick validation prompt in Copilot Chat:

@infracost run infracost_breakdown

Interactive VS Code Workflows

1. PR Cost Impact Review

Generate a baseline:

@infracost run infracost_breakdown with:
- path: .
- format: json

Generate a diff:

@infracost run infracost_diff with:
- path: .
- format: diff

Draft a PR comment:

@infracost run infracost_comment with:
- platform: github
- path: infracost-diff.json
- repo: owner/repo
- pullRequest: 123
- dryRun: true

2. Reporting Pipeline Setup

Render a report for humans:

@infracost run infracost_output with:
- path: infracost-diff.json
- format: html

Upload for centralized tracking:

@infracost run infracost_upload with:
- path: infracost-diff.json

3. Environment Bootstrap

Configure defaults:

@infracost run infracost_configure with:
- set: currency=USD

Authenticate:

@infracost run infracost_auth

Best Practices

Keep workingDirectory explicit when running inside monorepos.
Use --format json for machine processing and --format table for human triage.
Keep timeoutSeconds high enough for large Terraform plans.
Prefer infracost_comment with dryRun=true before posting to production PR threads.
Use infracost_upload for historical visibility in Infracost Cloud.

Additional Use Cases

Pre-merge cost gates in pull requests.
Scheduled baseline cost snapshots in CI.
Cost delta reporting for release trains.
Team-level FinOps dashboards based on uploaded reports.

Infracost Resources

Model Context Protocol

Community and Contributing

Attribution and License

Maintained by Carl Dawson under the Down At The Bottom Of The Mole Hole organization.

Development

npm run lint
npm test
npm run build

License

Licensed under the MIT License.

Available Tools

8 tools

infracost_authA

Authenticate with Infracost Cloud. Opens browser for login flow.

ParametersJSON Schema

Name	Required	Description
`apiKey`	No	Infracost API key (alternative to browser login).
`extraArgs`	No	Additional CLI arguments.
`timeoutSeconds`	No	Command timeout in seconds.
`workingDirectory`	No	Directory where the command is executed.

TDQS

A3.5/5.0

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.

infracost_breakdownB

Generate cost breakdown for Infrastructure as Code (Terraform, CloudFormation, etc.). Shows cost estimates for cloud resources.

ParametersJSON Schema

Name	Required	Description	Default
`path`	No	Path to the Terraform/IaC directory or plan JSON file.
`apiKey`	No	Infracost API key (can also use INFRACOST_API_KEY env var).
`fields`	No	Fields to include in output (all, price, monthlyQuantity, unit, hourlyCost, monthlyCost).
`format`	No	Output format: table, json, html, diff, github-comment, gitlab-comment, azure-repos-comment, slack-message, etc.	table
`showSkus`	No	Show SKU details in the output.
`compareTo`	No	Path to baseline Infracost JSON for comparison.
`extraArgs`	No	Additional CLI arguments.
`usageFile`	No	Path to Infracost usage file for resource usage estimates.
`configFile`	No	Path to Infracost config file.
`syncUsageFile`	No	Sync usage file with missing resources.
`timeoutSeconds`	No	Command timeout in seconds.
`workingDirectory`	No	Directory where the command is executed. Defaults to current directory.
`terraformPlanFlags`	No	Flags to pass to 'terraform plan'.
`terraformWorkspace`	No	Terraform workspace to use.

TDQS

B3.4/5.0

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.

infracost_commentA

Post cost estimate comments to pull requests on GitHub, GitLab, Azure Repos, or Bitbucket.

ParametersJSON Schema

Name	Required	Description	Default
`tag`	No	Customize comment tag to support multiple scenarios.
`path`	No	Path to Infracost JSON file. Optional; auto-detected from common filenames when omitted.
`repo`	No	Repository in format owner/repo.
`token`	No	GitHub/GitLab/Azure DevOps/Bitbucket token.
`apiKey`	No	Infracost API key.
`commit`	No	Commit SHA.
`dryRun`	No	Dry run mode - generate comment without posting.
`behavior`	No	Behavior: update (default), new, or delete-and-new.
`platform`	No	Platform: github, gitlab, azure-repos, or bitbucket.	github
`extraArgs`	No	Additional CLI arguments.
`pullRequest`	No	Pull request number.
`timeoutSeconds`	No	Command timeout in seconds.
`workingDirectory`	No	Directory where the command is executed.

TDQS

A3.6/5.0

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.

infracost_configureB

Get or set Infracost configuration options (API key, currency, etc.).

ParametersJSON Schema

Name	Required	Description
`get`	No	Get configuration value for a key (e.g., 'api_key', 'currency').
`set`	No	Set configuration key-value (e.g., 'api_key=YOUR_KEY' or 'currency=EUR').
`apiKey`	No	Infracost API key.
`extraArgs`	No	Additional CLI arguments.
`timeoutSeconds`	No	Command timeout in seconds.
`workingDirectory`	No	Directory where the command is executed.

TDQS

B3.4/5.0

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.

infracost_diffA

Show cost diff between current IaC and planned changes. Useful for pull request reviews to understand cost impact.

ParametersJSON Schema

Name	Required	Description	Default
`path`	No	Path to the Terraform/IaC directory or plan JSON file.
`apiKey`	No	Infracost API key.
`format`	No	Output format: table, json, html, diff, github-comment, etc.	table
`showSkus`	No	Show SKU details.
`compareTo`	No	Path to baseline Infracost JSON for comparison.
`extraArgs`	No	Additional CLI arguments.
`usageFile`	No	Path to Infracost usage file.
`configFile`	No	Path to Infracost config file.
`syncUsageFile`	No	Sync usage file with missing resources.
`timeoutSeconds`	No	Command timeout in seconds.
`workingDirectory`	No	Directory where the command is executed. Defaults to current directory.
`terraformPlanFlags`	No	Flags to pass to 'terraform plan'.
`terraformWorkspace`	No	Terraform workspace to use.

TDQS

A3.8/5.0

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.

infracost_generate_usageB

Generate Infracost usage file with sensible defaults for specified resource types. Complements infracost_configure by providing pre-filled templates.

ParametersJSON Schema

Name	Required	Description
`onlyJson`	No	Return only the raw JSON (no guidance). Overrides includeGuidance. Default: false.
`resourceTypes`	Yes	Resource types to include in usage file (e.g., ["aws_lambda_function", "aws_s3_bucket"]). Required.
`outputFilePath`	No	Optional path where the usage file should be saved (for guidance only).
`includeGuidance`	No	Include formatted guidance on how to use the generated file. Default: true.

TDQS

B3.3/5.0

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.

infracost_outputB

Format Infracost JSON output to different formats (table, html, github-comment, etc.).

ParametersJSON Schema

Name	Required	Description	Default
`path`	No	Path to Infracost JSON file. Optional; auto-detected from common filenames when omitted.
`apiKey`	No	Infracost API key.
`fields`	No	Fields to include in output.
`format`	No	Output format: table, json, html, diff, github-comment, etc.	table
`showSkus`	No	Show SKU details.
`extraArgs`	No	Additional CLI arguments.
`timeoutSeconds`	No	Command timeout in seconds.
`workingDirectory`	No	Directory where the command is executed.

TDQS

B3.4/5.0

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.

infracost_uploadA

Upload Infracost JSON output to Infracost Cloud for centralized cost visibility and reporting.

ParametersJSON Schema

Name	Required	Description
`path`	No	Path to Infracost JSON file to upload. Optional; auto-detected from common filenames when omitted.
`apiKey`	No	Infracost API key.
`extraArgs`	No	Additional CLI arguments.
`timeoutSeconds`	No	Command timeout in seconds.
`workingDirectory`	No	Directory where the command is executed.

TDQS

A3.5/5.0

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.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.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.

Maintenance

ActivityActive

ResponsivenessUnresponsive

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

CostPilot
com.mcpgatepro
Hosted MCP server for AWS cloud spend: service breakdowns, anomalies, savings and forecasts.
Cloud Platforms Finance Monitoring
1
Azure DevOps (ADO)
io.github.PremierInc
The MCP server for Azure DevOps, bringing the power of Azure DevOps directly to your agents.
CI/CD & DevOps Version Control Project Management
21,993
Appcircle MCP
io.appcircle
MCP server for Appcircle mobile CI/CD platform.
CI/CD & DevOps Developer Tools
2
docs
dev.continue
An MCP server for docs.continue.dev
Documentation Access Developer Tools Search
2

Related MCP Servers

cloudscope-mcp
Cloud Platforms Finance
alexpota
A
license
A
quality
B
maintenance
Cloud cost management MCP server for Azure. Ask your AI about your cloud bill.
Updated 22 days ago (2026-08-12 01:27 UTC)
15
80
1
MIT
Azure FinOps Elite
Cloud Platforms Monitoring Finance
mazhar480
A
license
Not graded
quality
D
maintenance
Production-grade MCP server for enterprise Azure cost optimization, enabling spend anomaly detection, multi-tenant auditing, budget validation, and compliance-aware recommendations.
Updated 7 months ago (2026-02-11 10:48 UTC)
1
MIT
AWS Pricing Calculator MCP
Cloud Platforms Finance
elchanio-76
A
license
Not graded
quality
C
maintenance
MCP server that provides tools for automating AWS Pricing Calculator estimate generation.
Updated 6 months ago (2026-03-11 21:05 UTC)
MIT
MCP Terraform Assistant
Cloud Platforms Developer Tools
guilhermeyoshida
A
license
Not graded
quality
D
maintenance
MCP server for managing Terraform infrastructure as code, enabling initialization, planning, applying, destroying, validating, and showing state of Terraform configurations.
Updated a year ago (2025-04-08 04:10 UTC)
1
MIT

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

Infracost MCP Server

Overview

Platform Compatibility

Tool Matrix

Tools

infracost_breakdown

infracost_diff

infracost_output

infracost_comment

infracost_upload

infracost_configure

infracost_auth

infracost_generate_usage

Prompt Cookbook

Quick prompts

Run breakdown (infracost_breakdown)

Run diff (infracost_diff)

Render output (infracost_output)

Post PR comment (infracost_comment)

Upload report (infracost_upload)

Configure CLI (infracost_configure)

Authenticate (infracost_auth)

Generate usage file (infracost_generate_usage)

Dependencies

System Dependencies

npm Dependencies

Environment Variables

Installation

Configuration

Usage with VS Code Copilot Chat

Usage with Other MCP Clients

Running

Debugging

Testing

Interactive VS Code Workflows

1. PR Cost Impact Review

2. Reporting Pipeline Setup

3. Environment Bootstrap

Best Practices

Additional Use Cases

Related Projects

Infracost Resources

Model Context Protocol

Community and Contributing

Attribution and License

Development

License

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

`infracost_breakdown`

`infracost_diff`

`infracost_output`

`infracost_comment`

`infracost_upload`

`infracost_configure`

`infracost_auth`

`infracost_generate_usage`

Run breakdown (`infracost_breakdown`)

Run diff (`infracost_diff`)

Render output (`infracost_output`)

Post PR comment (`infracost_comment`)

Upload report (`infracost_upload`)

Configure CLI (`infracost_configure`)

Authenticate (`infracost_auth`)

Generate usage file (`infracost_generate_usage`)