Skip to main content
Glama

infracost_output

Combine and format Infracost cost estimation files to merge multiple estimates or convert between formats like JSON, HTML, and PR comments.

Instructions

Combine and format Infracost JSON files. Useful for merging multiple cost estimates or converting formats. Requires infracost CLI to be installed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYesPath to Infracost JSON file(s) - supports glob patterns
formatNoOutput format
outFileNoSave output to a file
fieldsNoFields to include in output (e.g., ["price", "monthlyQuantity"])
showSkippedNoShow skipped resources in output

Implementation Reference

  • Core handler function that executes the 'infracost output' CLI command with the provided options, handles output parsing for JSON, and returns success/error with stdout/stderr.
    export async function executeOutput(options: OutputOptions): Promise<CommandResult> {
      try {
        const args = ['output', '--path', resolve(options.path)];
    
        if (options.format) {
          args.push('--format', options.format);
        }
    
        if (options.outFile) {
          args.push('--out-file', resolve(options.outFile));
        }
    
        if (options.fields && options.fields.length > 0) {
          args.push('--fields', options.fields.join(','));
        }
    
        if (options.showSkipped) {
          args.push('--show-skipped');
        }
    
        const { stdout, stderr } = await execFileAsync('infracost', args, {
          maxBuffer: 10 * 1024 * 1024,
        });
    
        let parsedData;
        if (options.format === 'json' && !options.outFile && stdout.trim()) {
          try {
            parsedData = JSON.parse(stdout);
          } catch (e) {}
        }
    
        return {
          success: true,
          output: options.outFile ? `Output saved to ${options.outFile}` : stdout,
          error: stderr || undefined,
          data: parsedData,
        };
      } catch (error) {
        return {
          success: false,
          error: error instanceof Error ? error.message : 'Unknown error occurred',
        };
      }
    }
  • MCP tool handler method in InfracostTools class. Checks if infracost CLI is installed, calls executeOutput, and formats the response as MCP content.
    async handleOutput(args: z.infer<typeof OutputSchema>) {
      const isInstalled = await checkInfracostInstalled();
      if (!isInstalled) {
        throw new Error(
          'Infracost CLI is not installed. Please install it from https://www.infracost.io/docs/'
        );
      }
    
      const result = await executeOutput(args);
    
      if (!result.success) {
        throw new Error(result.error || 'Output command failed');
      }
    
      return {
        content: [
          {
            type: 'text',
            text: result.output || 'Output generated successfully',
          },
        ],
      };
    }
  • Zod schema for validating input arguments to the infracost_output tool.
    export const OutputSchema = z.object({
      path: z.string().describe('Path to Infracost JSON file(s)'),
      format: z
        .enum([
          'json',
          'table',
          'html',
          'diff',
          'github-comment',
          'gitlab-comment',
          'azure-repos-comment',
          'bitbucket-comment',
        ])
        .optional()
        .describe('Output format'),
      outFile: z.string().optional().describe('Save output to file'),
      fields: z.array(z.string()).optional().describe('Fields to include in output'),
      showSkipped: z.boolean().optional().describe('Show skipped resources'),
    });
  • src/index.ts:714-717 (registration)
    Switch case in CallToolRequestHandler that routes 'infracost_output' calls to tools.handleOutput after schema validation.
    case 'infracost_output': {
      const validatedArgs = OutputSchema.parse(args);
      return await tools.handleOutput(validatedArgs);
    }
  • src/index.ts:134-175 (registration)
    Tool registration in ListToolsRequestHandler, including name, description, and input schema mirroring OutputSchema.
    {
      name: 'infracost_output',
      description:
        'Combine and format Infracost JSON files. Useful for merging multiple cost estimates or converting formats. Requires infracost CLI to be installed.',
      inputSchema: {
        type: 'object',
        properties: {
          path: {
            type: 'string',
            description: 'Path to Infracost JSON file(s) - supports glob patterns',
          },
          format: {
            type: 'string',
            enum: [
              'json',
              'table',
              'html',
              'diff',
              'github-comment',
              'gitlab-comment',
              'azure-repos-comment',
              'bitbucket-comment',
            ],
            description: 'Output format',
          },
          outFile: {
            type: 'string',
            description: 'Save output to a file',
          },
          fields: {
            type: 'array',
            items: { type: 'string' },
            description: 'Fields to include in output (e.g., ["price", "monthlyQuantity"])',
          },
          showSkipped: {
            type: 'boolean',
            description: 'Show skipped resources in output',
          },
        },
        required: ['path'],
      },
    },
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 mentions a prerequisite (infracost CLI installation) and hints at merging/formatting functions, but fails to disclose critical traits: whether this is a read-only or mutating operation, potential side effects (e.g., file creation with outFile), error handling, or performance considerations. For a tool with 5 parameters and no annotations, this is a significant gap in transparency.

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 appropriately sized with three concise sentences that are front-loaded with the core purpose. Each sentence adds value: the first states the action, the second gives usage context, and the third specifies a prerequisite. There is no wasted text, making it efficient, though it could be slightly more structured for clarity.

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 complexity (5 parameters, no output schema, no annotations), the description is incomplete. It lacks details on behavioral traits, output expectations, error conditions, and how it differs from sibling tools. While it covers basic purpose and a prerequisite, it doesn't provide enough context for an agent to fully understand the tool's operation and limitations in this rich environment.

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 schema already documents all 5 parameters thoroughly. The description adds minimal value beyond the schema, only implying that 'path' can handle multiple files via 'JSON files' and glob patterns, and 'format' relates to 'converting formats.' Since the schema does the heavy lifting, the baseline score of 3 is appropriate, with no extra semantic insights provided.

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's purpose: 'Combine and format Infracost JSON files' with specific verbs and resources. It distinguishes from siblings like infracost_breakdown or infracost_diff by focusing on post-processing output rather than cost analysis or comparison. However, it doesn't explicitly contrast with all siblings, keeping it at 4 instead of 5.

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 provides some context with 'Useful for merging multiple cost estimates or converting formats,' which implies when to use it. It also mentions a prerequisite: 'Requires infracost CLI to be installed.' However, it lacks explicit guidance on when to choose this tool over alternatives like infracost_comment or infracost_upload, leaving usage somewhat implied rather than fully clarified.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

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/phildougherty/infracost_mcp'

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