Provision Stack MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PROVISION_STACK_API_TOKEN | No | Provision Stack API token (Bearer). Optional for initialize and tools/list; required for deploy and billing calls. Create via POST https://api.provision-stack.com/auth/tokens | |
| PROVISION_STACK_EXECUTION_API_URL | No | Base URL for the Provision Stack Execution API | https://api.provision-stack.com |
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": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| suggestions.generateA | START HERE for any deployment. STEP 1: Call region.detect or providers.detect. STEP 2: Call this tool with the detected region. Returns Starter/MVP/Startup/Enterprise options with monthly costs. When the response includes a clarificationRequest, answer the suggested questions and call again with requirements. Present all options and wait for an explicit choice before deploy.run. When the outcome mentions a custom domain (e.g. 'deploy to api.example.com') and CLOUDFLARE_API_TOKEN is set, DNS records are auto-detected and will be created during deployment. |
| pricing.getA | Estimate monthly and hourly USD cost for one cloud resource type (e.g. ec2_instance, rds_instance, gcp_cloud_run) without provisioning anything. Use after suggestions.generate when the user wants a component-level breakdown for a single resource; prefer region from region.detect. Provider is inferred from resourceType prefixes (gcp_*, azure_*, oracle_*) when omitted. Do not use for full-stack option comparison — that is suggestions.generate. Does not create resources or hold credits. |
| credentials.listA | Check cloud provider credential configuration without exposing secrets. Call before deploy.run to confirm AWS/GCP/Azure/Oracle/Cloudflare are ready. Returns configured=true/false plus guidance — never returns secret values. |
| region.detectA | Resolve the active region for one cloud provider from env/config, or a documented default when unset. Call before suggestions.generate/deploy.run when targeting a single provider so pricing and placement match local config. Prefer providers.detect instead when comparing AWS/GCP/Azure/Oracle in one step. Read-only; does not change cloud config. |
| providers.detectA | Detect all configured cloud providers and their regions in one call. Prefer this over repeated region.detect when comparing AWS/GCP/Azure/Oracle. Returns { providers: [...] } with source (env|config|default) and a guidance message per provider. |
| deploy.runA | Provision the explicitly selected suggestion through the Execution API. Never call before presenting options and receiving user approval. Pass resources from the chosen suggestions.generate option as selection evidence. The deploy fee is held from the account credit balance and captured only after verification passes (failed deployments are free). On HTTP 402, call billing.top_up and retry. When the outcome includes a custom domain and CLOUDFLARE_API_TOKEN is set, DNS records are automatically created pointing the domain at the deployed endpoint. After accept, poll deploy.status. |
| deploy.statusA | Check deployment progress and retrieve verification evidence when complete. Poll after deploy.run until status is verified/failed/destroyed. On success, result.endpoints and result.verificationResults contain live URLs and check outcomes. |
| deploy.destroyA | DESTRUCTIVE: permanently destroy all cloud resources owned by a deployment. Irreversible — confirm the deploymentId with the user first. Prefer deploy.teardown_latest only when intentionally removing the newest active deployment. Optional reason is stored for audit. |
| deploy.listA | Return the Execution API’s tracked deployments (deploymentId, status, category, createdAt) so you can select a target for status checks or teardown. Call when you need a deploymentId and do not already have one from deploy.run, or to inventory active work before deploy.destroy/deploy.teardown_latest. Do not use this to monitor a known deployment — poll deploy.status with that id instead. Read-only; does not create, modify, or destroy resources. |
| deploy.teardown_latestA | DESTRUCTIVE: destroy the newest active deployment, or all active deployments when all=true. Skips already destroyed/failed entries. Confirm with the user before calling — especially with all=true. Prefer deploy.destroy with an explicit deploymentId when targeting a specific deployment. |
| billing.balanceA | Return the account credit position as total, held, and available USD without modifying the balance. Call when deploy.run returns HTTP 402 insufficient_credits, or before deploy.run when you need to confirm availableUsd covers the hold. Do not use this to add funds — call billing.top_up when availableUsd is insufficient, then retry deploy.run. Read-only; does not create charges or hold credits. |
| billing.top_upA | Create a credit top-up intent for the account (does not immediately increase balance). Call when deploy.run fails with HTTP 402 or billing.balance shows availableUsd below the required hold; choose rail=xrp (agent pays on-ledger with REQUIRED destination tag + exact amount) or rail=stripe (human Checkout URL). Do not call to inspect balance — use billing.balance. After funds confirm, retry the failed deploy.run. Side effects: opens a payment/deposit flow (open world); not idempotent — each call creates a new top-up. |
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 12 tools
Each tool has a clearly distinct purpose. Suggestions.generate for options, providers.detect for provider discovery, pricing.get for component costs, credentials.list for credential checks, region.detect for region resolution, and deploy.* tools cover the full lifecycle with clear differentiation (e.g., deploy.destroy vs deploy.teardown_latest). Billing tools are separate. No overlap.
All tools follow a consistent category.action pattern (noun.verb) using snake_case in the verb part (e.g., suggestions.generate, deploy.teardown_latest, billing.top_up). The pattern is uniform across the set, making it predictable for agents.
With 12 tools, the surface is well-scoped. It covers discovery (detect, list), pricing (get, generate), deployment (run, status, destroy, list, teardown_latest), and billing (balance, top_up). No tool is extraneous, and the count feels appropriate for a provisioning domain.
The tool set appears complete for the domain of provisioning cloud stacks. It covers the full workflow: initial discovery, pricing, deployment, monitoring, teardown, and billing. No obvious gaps like missing deployment modification or log retrieval, given the stated purpose.