Skip to main content
Glama
heroku

Heroku MCP server

Official
by heroku

create_addon

Provision a new Heroku add-on for your app by specifying the service, plan, and custom naming. Automates add-on setup and returns configuration details for easy integration.

Instructions

Create a new Heroku add-on for an application. Use this tool when you need to: 1) Provision a new add-on for your app, 2) Specify a particular service and plan, 3) Set a custom name for the add-on or attachment. The tool handles the provisioning process and returns the new add-on's details.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
appYesSpecifies the target Heroku app for add-on provisioning. Requirements and behaviors: 1) App must exist and be accessible to you with write permissions, 2) App region may affect which add-on services are available, 3) If app is in a Private Space, only add-ons compliant with the space requirements can be provisioned. The add-on will be provisioned directly to this app and config vars will be set automatically.
asNoSets a custom local name for the add-on attachment in the app. Important details: 1) Must be unique within the app (no other attachment can use the same name), 2) Used as a prefix for config vars (e.g., "CUSTOM_NAME_URL" instead of "HEROKU_POSTGRESQL_URL"), 3) Makes the add-on easier to identify in app context (e.g., "as: DATABASE" is clearer than "postgresql-curved-12345"), 4) When omitted, Heroku generates a default name based on the add-on service. Best practice: Use meaningful names that indicate the add-on's purpose (e.g., "PRIMARY_DB", "CACHE").
nameNoAssigns a custom global identifier for the add-on instance. Key characteristics: 1) Must be unique across all add-ons in Heroku (not just your apps), 2) Can be used to reference the add-on from any app or context, 3) Useful for identifying the add-on in cross-app scenarios or automation, 4) When omitted, Heroku generates a unique name (e.g., "postgresql-curved-12345"). Best practice: Include app name or environment if using custom names (e.g., "myapp-prod-db").
serviceAndPlanYesSpecifies which add-on service and plan to provision. Format and behavior: 1) Required format: "service_slug:plan_slug" (e.g., "heroku-postgresql:essential-0"), 2) If only service slug provided, the default (usually the cheapest or free) plan will be selected, 3) Some plans may have prerequisites (e.g., inside a private space, specific regions). Use list_addon_services and list_addon_plans tools to discover available options.

Implementation Reference

  • The core handler function for the 'create_addon' tool. It constructs a CommandBuilder for 'addons:create', adds flags for app, as, name, positional argument for serviceAndPlan, executes via herokuRepl, and processes output with handleCliOutput.
    async (options: CreateAddonOptions): Promise<McpToolResponse> => {
      const command = new CommandBuilder(TOOL_COMMAND_MAP.CREATE_ADDON)
        .addFlags({
          app: options.app,
          as: options.as,
          name: options.name
        })
        .addPositionalArguments({ 'service:plan': options.serviceAndPlan })
        .build();
    
      const output = await herokuRepl.executeCommand(command);
      return handleCliOutput(output);
    }
  • Zod schema defining and validating the input parameters for the create_addon tool.
    export const createAddonOptionsSchema = z.object({
      app: z.string().describe('Target app for add-on. Must have write access. Region/space affects availability'),
      as: z.string().optional().describe('Custom attachment name. Used for config vars prefix. Must be unique in app'),
      name: z.string().optional().describe('Global add-on identifier. Must be unique across all Heroku add-ons'),
      serviceAndPlan: z.string().describe('Format: service_slug:plan_slug (e.g., heroku-postgresql:essential-0)')
    });
  • Function that registers the 'create_addon' tool with the MCP server, including schema and inline handler.
    export const registerCreateAddonTool = (server: McpServer, herokuRepl: HerokuREPL): void => {
      server.tool(
        'create_addon',
        'Create add-on: specify service, plan, custom names',
        createAddonOptionsSchema.shape,
        async (options: CreateAddonOptions): Promise<McpToolResponse> => {
          const command = new CommandBuilder(TOOL_COMMAND_MAP.CREATE_ADDON)
            .addFlags({
              app: options.app,
              as: options.as,
              name: options.name
            })
            .addPositionalArguments({ 'service:plan': options.serviceAndPlan })
            .build();
    
          const output = await herokuRepl.executeCommand(command);
          return handleCliOutput(output);
        }
      );
    };
  • src/index.ts:71-71 (registration)
    Invocation of the registration function for create_addon tool on the main MCP server instance.
    addons.registerCreateAddonTool(server, herokuRepl);
  • Constant mapping CREATE_ADDON to the Heroku CLI command 'addons:create', referenced in the handler.
    CREATE_ADDON: 'addons:create',
Behavior4/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 effectively describes key behaviors: the provisioning process, automatic config var setting, and return of new add-on details. However, it lacks information on permissions, rate limits, or error conditions, which would be valuable for a creation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear purpose statement followed by bullet-point usage guidelines. Every sentence adds value, though the bullet points could be integrated more smoothly into prose. It's appropriately sized for a tool with four parameters.

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?

For a creation tool with no annotations and no output schema, the description does a good job covering purpose, usage, and high-level behavior. It could improve by detailing error cases or response format, but given the rich parameter schema, it's mostly complete for agent 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?

Schema description coverage is 100%, so the schema already documents all four parameters thoroughly. The description adds minimal value beyond the schema, only mentioning parameters in the usage guidelines without providing additional semantics. This meets the baseline for high schema coverage.

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 ('create'), resource ('Heroku add-on'), and target ('for an application'), making the purpose specific. It distinguishes this tool from siblings like 'list_addons' or 'get_addon_info' by focusing on provisioning new resources rather than querying existing ones.

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 three scenarios for when to use this tool: provisioning a new add-on, specifying service/plan, and setting custom names. It also references sibling tools ('list_addon_services' and 'list_addon_plans') for discovering options, providing clear alternatives and context.

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