Skip to main content
Glama
heroku

Heroku MCP server

Official
by heroku

get_app_info

Retrieve detailed Heroku app information, including configuration, dynos, add-ons, buildpacks, collaborators, and domains. Input app name to access status and metadata in text or JSON format.

Instructions

Get comprehensive information about a Heroku application. Use this tool when you need to: 1) View app configuration and settings, 2) Check dyno formation and scaling, 3) List add-ons and buildpacks, 4) View collaborators and access details, 5) Check domains and certificates. Accepts app name and optional JSON format. Returns detailed app status and configuration.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
appYesThe name of the Heroku app to get information about. This must be an existing app that you have access to.
jsonNoControls the output format. When true, returns a detailed JSON response containing app metadata such as add-ons, dynos, buildpack configurations, collaborators, and domain information. When false or omitted, returns a simplified text format.

Implementation Reference

  • Handler function that constructs the Heroku CLI 'apps:info' command with app name and optional json flag, executes it via herokuRepl.executeCommand, and returns processed output using handleCliOutput.
    async (options: GetAppInfoOptions): Promise<McpToolResponse> => {
      const command = new CommandBuilder(TOOL_COMMAND_MAP.GET_APP_INFO)
        .addFlags({
          app: options.app,
          json: options.json
        })
        .build();
    
      const output = await herokuRepl.executeCommand(command);
      return handleCliOutput(output);
    }
  • Zod schema for get_app_info tool options: required 'app' string and optional 'json' boolean flag, with descriptions.
     */
    export const getAppInfoOptionsSchema = z.object({
      app: z.string().describe('Target app name. Requires access permissions'),
      json: z.boolean().optional().describe('JSON output with full metadata. Default: text format')
    });
  • registerGetAppInfoTool function that registers the 'get_app_info' tool on the MCP server using server.tool with name, description, schema, and inline handler.
    export const registerGetAppInfoTool = (server: McpServer, herokuRepl: HerokuREPL): void => {
      server.tool(
        'get_app_info',
        'Get app details: config, dynos, addons, access, domains',
        getAppInfoOptionsSchema.shape,
        async (options: GetAppInfoOptions): Promise<McpToolResponse> => {
          const command = new CommandBuilder(TOOL_COMMAND_MAP.GET_APP_INFO)
            .addFlags({
              app: options.app,
              json: options.json
            })
            .build();
    
          const output = await herokuRepl.executeCommand(command);
          return handleCliOutput(output);
        }
      );
    };
  • src/index.ts:51-51 (registration)
    Invocation of registerGetAppInfoTool(server, herokuRepl) to register the tool during server setup.
    apps.registerGetAppInfoTool(server, herokuRepl);
  • TOOL_COMMAND_MAP.GET_APP_INFO constant, mapped to Heroku CLI command 'apps:info'.
    GET_APP_INFO: 'apps:info',
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 mentions the tool returns 'detailed app status and configuration' and output format options, but lacks details on permissions required, rate limits, error handling, or whether it's read-only (implied by 'Get' but not explicit). It adds some behavioral context but is incomplete for a tool with no annotations.

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 front-loaded with the core purpose, followed by a bulleted list of use cases and parameter/output details. Every sentence adds value with no redundancy, making it efficient and well-structured for quick comprehension.

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 no annotations and no output schema, the description provides good context on what the tool does, when to use it, and output behavior. However, it lacks explicit safety disclosures (e.g., read-only nature) and detailed return format examples, leaving some gaps for a tool with no structured metadata.

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 both parameters (app name and json format). The description mentions 'Accepts app name and optional JSON format' but doesn't add meaning beyond the schema's detailed descriptions. Baseline 3 is appropriate when schema does the heavy lifting.

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 verb 'Get' and resource 'comprehensive information about a Heroku application,' with specific details about what information is included (configuration, dynos, add-ons, etc.). It distinguishes from siblings like get_app_logs (logs only) or list_apps (list of apps without details).

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?

The description explicitly lists five use cases (e.g., 'View app configuration and settings,' 'Check dyno formation and scaling'), providing clear guidance on when to use this tool. It implicitly distinguishes from alternatives like get_app_logs for logs or list_apps for listing apps without details.

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

Related 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/heroku/heroku-mcp-server'

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