aptible-mcp
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| listAccountsA | List all accounts/environments. |
| getAccountB | Get account/environment by handle. |
| getAccountsByStackA | Get all accounts/environments in a stack by stack name. |
| createAccountC | Create a new account/environment. |
| listAppsA | List all apps. |
| getAppA | Get app by handle. Because app names are only unique within an account/environment, an account handle can also be provided. |
| createAppC | Create a new app. |
| configureAppC | Configure app environment variables. |
| deleteAppC | Delete an app. |
| listAvailableDatabaseTypesA | List all available database types. When creating a database, the image id provided via this method is needed. |
| listDatabasesA | List all databases. |
| getDatabaseA | Get database by handle and optionally account handle. |
| createDatabaseA | Create a new database. The image_id should be the ID found via listAvailableDatabaseTypes. |
| deleteDatabaseC | Delete a database. |
| listStacksB | List all stacks. |
| getStackC | Get stack by name. |
| listVhostsB | List all vhosts/endpoints). |
| getVhostB | Get vhost by ID. |
| createVhostA | Create a new vhost/endpoint for a Service. Service handle is a bit weird, since it's auto-assigned by Aptible and not set by the user. The user assigns with process_type in the procfile. Since this is being used by AI, that shouldn't matter, though. TODO: Add support for database endpoints and custom endpoints. Currently, since there's no tools for handling DNS, we only support creating the default on-aptible.com domains for Services. |
| deleteVhostB | Delete a vhost/endpoint. |
| listServicesA | List all services for a specific app. |
| getServiceB | Get a service by handle within a specific app. |
| scaleServiceB | Scale a service by changing container count or size. |
| listServiceVhostsB | List all vhosts for a specific service. |
| getOperationsForAppC | Get recent operations for a specific app. |
| getOperationsForDatabaseB | Get recent operations for a specific database. |
| getOperationsForVhostB | Get recent operations for a specific vhost/endpoint. |
| getOperationLogsB | Get logs for a specific operation. |
| getProcfileExampleA | Gets an example Procfile for defining app processes. Keep in mind that 1-off tasks like running migrations are better suited for processes run via .aptible.yml, and do not belong in the Procfile. The finalized Procfile file should be located in /.aptible/Procfile in the build Docker image. |
| getAptibleYamlExampleA | Gets an example aptible.yml configuration file for deploy hooks. The finalized .aptible.yml file should be located in /.aptible/.aptible.yml in the build Docker image. |
| getEndpointProvisionExampleA | Gets an example of a GitHub Action for provisioning an endpoint. |
| getAppProvisionExampleA | Gets an example of a GitHub Action for provisioning an app. |
| getAppDeprovisionExampleA | Gets an example of a GitHub Action for deprovisioning an app. |
| getAppConfigureExampleA | Gets an example of a GitHub Action for configuring an app. |
| getDatabaseProvisionExampleA | Gets an example of a GitHub Action for provisioning a database. |
| getDatabaseDeprovisionExampleA | Gets an example of a GitHub Action for deprovisioning a database. |
| getDatabaseRestoreExampleA | Gets an example of a GitHub Action for restoring a database from backup. |
| getBuildDeployExampleA | Gets an example of a GitHub Action for building, publishing, and deploying an app. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 38 tools
Most tools are clearly distinct by resource and action, such as createApp, deleteDatabase, and listStacks. The only minor overlap is between listVhosts and listServiceVhosts, and getAccountsByStack vs listAccounts, but descriptions clarify the intended scope.
All tool names follow a consistent verb_noun pattern (list, get, create, delete, configure, scale) with no mixed conventions or vague verbs. Examples like getAppProvisionExample still fit the pattern as get + resource + Example.
With 38 tools, the surface is quite large and exceeds the 25+ threshold. While the domain is broad (accounts, apps, databases, vhosts, services, operations, examples), the sheer number feels heavy and could overwhelm agents, especially with 10 example template tools.
Core resources have CRUD coverage, but there are notable gaps: no update/delete for accounts, no database backup or restore operations, and no app logs. The example tools provide templates but don't fill operational dead ends, so agents may need to work around missing lifecycle features.