Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Provision Stack MCP Suggest infrastructure tiers for a web app on AWS"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Cloud infrastructure provisioning via natural language. Deploy production-ready infrastructure on your own AWS, GCP, Azure, or Oracle account with a single prompt.
Point your MCP client directly at the hosted API — no local process needed:
{
"mcpServers": {
"provision-stack": {
"url": "https://api.provision-stack.com/mcp",
"headers": {
"Authorization": "Bearer YOUR_TOKEN"
}
}
}
}Get a token: curl -X POST https://api.provision-stack.com/auth/tokens -H 'Content-Type: application/json' -d '{"agentId":"your-agent","scopes":[]}'
npx @provision-stack/mcpOr add to your MCP client config:
{
"mcpServers": {
"provision-stack": {
"command": "npx",
"args": ["-y", "@provision-stack/mcp"],
"env": {
"PROVISION_STACK_API_TOKEN": "YOUR_TOKEN"
}
}
}
}npm install -g @provision-stack/mcp
provision-stack-mcpRelated MCP server: Cloud Pilot MCP
Tool | Purpose |
| Get 4 tier options (Starter/MVP/Startup/Enterprise) with monthly costs |
| Detailed cost breakdown for individual cloud resources |
| Detect configured AWS/GCP/Azure/Oracle region |
| Detect all configured cloud providers |
| Check cloud credential configuration |
| Provision infrastructure via the Execution API |
| Check deployment progress |
| Tear down a specific deployment |
| List all tracked deployments |
| Destroy most recent active deployment |
| Check account credit balance |
| Add credits (XRP or Stripe) |
1. region.detect → Get your AWS region
2. suggestions.generate → Get 4 tier options with costs
3. Present options → Show costs, resources, tradeoffs
4. WAIT for user choice → Never proceed without explicit selection
5. deploy.run → Provision infrastructure
6. Report results → Deployment ID, resources, costsVariable | Description | Default |
| API base URL |
|
| Bearer token | (none — read-only tools work without) |
| AWS region override |
|
| AWS profile name |
|
This package is a thin client — it defines MCP tools and forwards calls to the hosted Execution API. All business logic (pattern matching, pricing, Terraform generation, verification) runs server-side.
Your AI Client → MCP stdio/HTTP → This Package → Execution API → Your AWS AccountThe API endpoint requires authentication for write operations (deploy.run, deploy.destroy, billing.top_up). Read operations (suggestions.generate, pricing.get, region.detect) work without a token.
Pre-0.5.0 underscore names still work on tools/call (e.g. generate_suggestions → suggestions.generate); tools/list advertises only the dotted names.
Website: https://provision-stack.com
Issues: https://github.com/TravisLinkey/provision-stack-mcp/issues
MIT
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| heldUsd | Yes | |
| accountId | Yes | |
| balanceUsd | Yes | |
| availableUsd | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds value beyond annotations by specifying returned fields, confirming no charges or holds created, and linking behavior to deploy.run workflow. Aligns with readOnlyHint and idempotentHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: purpose, usage scenarios, and exclusions. Front-loaded with action and resource. No superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Completes understanding by tying to deploy.run errors, output fields summary, and clarifying no side effects. Output schema exists for details, description covers usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so description doesn't need to explain them. Baseline 4 for 0 params, and description provides useful context about the tool's purpose and output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Return' with specific resources (total, held, available USD) and explicit read-only nature. Distinguishes from sibling billing.top_up by stating 'Do not use this to add funds'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to call (after HTTP 402 or before deploy.run to check holds) and when not to (to add funds), providing alternative tool (billing.top_up) and retry guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| rail | No | Payment rail: xrp (agent-native) or stripe (human) | xrp |
| amountUsd | Yes | Amount to add, in USD (e.g. 20) |
| Name | Required | Description |
|---|---|---|
| memo | No | |
| topupId | Yes | |
| amountUsd | No | |
| amountXrp | No | |
| expiresAt | No | |
| creditedOn | No | |
| checkoutUrl | No | |
| rateUsdPerXrp | No | |
| depositAddress | No | |
| destinationTag | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses side effects ('opens a payment/deposit flow'), non-idempotency ('each call creates a new top-up'), and explains that balance is not immediately increased. Annotations already hint at open world and non-idempotent, but description adds concrete behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences cover purpose, usage, and side effects without redundancy. Information is front-loaded and every sentence serves a distinct purpose. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the explicit usage guidelines, behavioral transparency, and presence of an output schema, the description fully prepares an AI agent to select and invoke the tool correctly. Covers when, how, and what happens, including side effects and retry logic.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds meaning by explaining the rail choices: xrp for agent with destination tag requirements, stripe for human checkout. This augments the parameter descriptions beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a credit top-up intent') and the resource (account balance). It distinguishes from sibling tools like billing.balance (for inspection) and deploy.run (for deployment), specifying that this tool does not immediately increase balance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to call (deploy.run failure with 402 or low balance in billing.balance) and when not to call (for balance inspection, use billing.balance). Provides precise guidance on rail selection and post-call steps (retry deploy.run after funds confirm).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | No | Cloud provider to check (defaults to checking all) |
| Name | Required | Description |
|---|---|---|
| aws | No | |
| gcp | No | |
| azure | No | |
| oracle | No | |
| cloudflare | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that it never returns secret values, reinforcing safety. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. Front-loaded with purpose and actionable guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (1 param, no nested objects, output schema exists), the description covers purpose, usage, and behavioral context completely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter (provider enum). Description adds meaning by stating defaults to checking all providers, complementing the schema's description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Check cloud provider credential configuration without exposing secrets.' It uses a specific verb (check) and resource (cloud provider credential configuration), distinguishing itself from siblings like deploy.run.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use context: 'Call before deploy.run to confirm AWS/GCP/Azure/Oracle/Cloudflare are ready.' It also describes what is returned (configured=true/false plus guidance). Could mention when not to use, but is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| reason | No | Optional audit reason for the destroy | |
| deploymentId | Yes | Deployment id whose resources should be destroyed |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| destroyedAt | Yes | |
| deploymentId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint=true, but description adds crucial context: irreversible, user confirmation needed, and audit logging via reason parameter. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with 'DESTRUCTIVE' warning. Every sentence adds value with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists and annotations cover safety, description adequately covers usage and behavior. Minor gap: no details on immediate effects or system state after destruction, but sufficient for tool's destructive nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. Description adds limited extra value beyond schema, only noting 'Optional reason is stored for audit' for the reason parameter. No additional semantics for deploymentId.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool destroys all cloud resources of a deployment and is irreversible. It distinguishes from the sibling deploy.teardown_latest by specifying the scope and alternative use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to confirm deploymentId with user first and advises preferring deploy.teardown_latest only for intentionally removing the newest active deployment, providing clear when-to-use and alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| count | Yes | Number of deployments returned |
| deployments | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds that it is 'read-only' and does not create, modify, or destroy resources, reinforcing annotations. It also discloses return field structure, adding value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with purpose. Every sentence provides essential information: return fields, use cases, exclusions. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and existence of output schema, description is nearly complete. It covers purpose, usage, and limitations. Slight gap: no mention of possible empty results or pagination, but not critical for a list-all tool with no params.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters (0), schema coverage 100%. Baseline is 4. Description does not need to add parameter info; it correctly omits any. No gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it returns tracked deployments with specific fields (deploymentId, status, category, createdAt), using a specific verb ('Return'). It distinguishes from sibling tools like deploy.destroy, deploy.teardown_latest, and deploy.status by indicating when to use each, avoiding ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: when a deploymentId is needed or to inventory active work before teardown. Also states when not to use: for monitoring a known deployment, recommending deploy.status instead. This provides clear guidance for agent decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| tier | No | Selected suggestion tier; defaults to MVP | |
| region | No | Target region; defaults via region.detect for provider | |
| outcome | Yes | Natural language deployment objective | |
| provider | No | Cloud provider (auto-detected from resources if omitted) | |
| projectId | No | Optional project id to group related deployments | |
| resources | Yes | Resources from the selected suggestion; used as selection evidence | |
| maxMonthlyCostUsd | No | Customer max monthly cost cap in USD — deploy is rejected when the estimate exceeds the cap |
| Name | Required | Description |
|---|---|---|
| tier | Yes | |
| quote | Yes | |
| region | Yes | |
| status | Yes | |
| message | Yes | |
| category | No | |
| provider | Yes | |
| createdAt | Yes | |
| deploymentId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds significant behavioral context beyond annotations: fee held from credit balance, captured only after verification (failed free), automatic DNS creation conditional on CLOUDFLARE_API_TOKEN, and polling. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
6 sentences, each earning its place: purpose, preconditions, parameter usage, billing behavior, error handling, DNS setup, and post-call action. Front-loaded with core purpose, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, 2 required, 100% schema coverage, output schema present, and a detailed description covering error recovery, billing, DNS, and lifecycle, the tool definition is fully actionable for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, establishing a baseline of 3. The description adds workflow context for parameters like 'resources' (selection evidence) and 'outcome' (deployment objective), enhancing their purpose beyond basic schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('provision') and resource ('the explicitly selected suggestion'), clearly stating the tool's role in deploying after user approval. It distinguishes itself from sibling tools like suggestions.generate by being the deployment step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to call ('Never call before presenting options and receiving user approval') and provides detailed guidance on handling HTTP 402 (call billing.top_up and retry), referencing related tools, and instructing to poll deploy.status after accept.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| deploymentId | Yes | Deployment id returned by deploy.run |
| Name | Required | Description |
|---|---|---|
| result | No | |
| status | Yes | |
| agentId | Yes | |
| category | No | |
| createdAt | Yes | |
| projectId | Yes | |
| updatedAt | Yes | |
| deploymentId | Yes | |
| desiredOutcome | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare `readOnlyHint: true`, `idempotentHint: true`, and `destructiveHint: false`. The description adds valuable behavioral context about polling behavior and the structure of results (endpoints, verificationResults), without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first sentence front-loads the main purpose, and the second provides actionable details. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only one parameter and an existing output schema, the description fully covers when to use the tool (polling after deploy.run) and what to expect in the response (endpoints and verificationResults). No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter. The description adds 'Deployment id returned by deploy.run' which provides source context but does not fundamentally add beyond the schema's own description. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Check deployment progress and retrieve verification evidence when complete', which is a specific verb+resource. It clearly distinguishes from sibling tools like `deploy.run` and `deploy.destroy` by focusing on status checking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: 'Poll after deploy.run until status is verified/failed/destroyed' and explains what information is available on success. It does not explicitly mention when not to use or list alternatives, but the polling guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| all | No | When true, destroy every active deployment; otherwise only the newest |
| Name | Required | Description |
|---|---|---|
| results | Yes | |
| destroyed | Yes | How many deployments were destroyed |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds valuable context: it skips already destroyed/failed entries and reiterates destructiveness with 'DESTRUCTIVE' prefix. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with 'DESTRUCTIVE:' warning and key behavior. Every sentence adds value: destructiveness, conditional behavior, confirmation requirement, and alternative suggestion. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (not shown), the description fully covers usage intent, behavioral nuances (skip destroyed), safety warnings, and tool selection guidance. No gaps given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'all' has a clear schema description. The tool description adds context about 'newest active deployment' and 'skips already destroyed/failed', which complements the schema well. Schema coverage is 100%, so high baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool destroys the newest active deployment, or all when all=true. It distinguishes from sibling deploy.destroy by specifying that teardown_latest targets the latest deployment without needing an explicit ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to confirm with user before calling, especially with all=true, and recommends using deploy.destroy for specific deployments. This provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| zone | No | GCP/Azure availability zone when required | |
| ocpus | No | Oracle OCPU count for flexible shapes | |
| shape | No | Oracle compute shape (e.g. VM.Standard.E4.Flex) | |
| region | No | Cloud region; defaults via region.detect for the provider | |
| sizeGb | No | Disk/volume size in GiB (EBS, etc.) | |
| vmSize | No | Azure VM size (e.g. Standard_B1s) | |
| provider | No | Cloud provider (auto-detected from resourceType if omitted) | |
| storageGb | No | Object/database storage size in GiB | |
| volumeType | No | Volume type (e.g. gp3, io2) | |
| machineType | No | GCP machine type (e.g. e2-medium) | |
| memoryInGbs | No | Oracle memory in GiB for flexible shapes | |
| instanceType | No | AWS instance type (e.g. t3.micro) for compute/RDS | |
| resourceType | Yes | Cloud resource type to price (prefix gcp_/azure_/oracle_ selects provider) | |
| instanceCount | No | Number of instances to price (default 1) |
| Name | Required | Description |
|---|---|---|
| region | Yes | |
| provider | Yes | |
| components | Yes | |
| estimateId | Yes | |
| description | Yes | |
| resourceType | Yes | |
| hourlyCostUsd | Yes | |
| monthlyCostUsd | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description confirms it does not create resources or hold credits, aligning with annotations readOnlyHint=true, idempotentHint=true, destructiveHint=false. It also explains provider inference from resourceType prefixes, adding behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is five sentences, front-loaded with purpose, then usage order, provider inference, exclusions, and safety confirmation. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (14 params, 1 required), annotations, and presence of output schema, the description provides all necessary context: purpose, usage sequence, provider inference, and what it does not do. It is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for each parameter. The description adds overall usage context like provider auto-detection and region defaults, but does not elaborate on individual parameters. This is adequate given the schema richness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it estimates monthly/hourly USD cost for one cloud resource type. It specifies the verb 'estimate' and resource 'cloud resource type', and distinguishes from siblings like suggestions.generate by noting it's not for full-stack comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use after suggestions.generate' and 'prefer region from region.detect'. It also states not to use for full-stack option comparison, naming the alternative sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| providers | Yes | Detected region for each supported cloud provider |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as read-only and idempotent. The description adds value by detailing the return structure (providers array with source and guidance) and the scope of detection.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states purpose, second gives usage guidance and return shape. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and presence of output schema, the description fully covers what the tool does and what it returns. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, schema coverage is 100%, so baseline is 4. The description succinctly conveys that no input is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool detects all configured cloud providers and regions in one call, names specific providers (AWS/GCP/Azure/Oracle), and distinguishes itself from the sibling tool 'region.detect'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises preferring this tool over repeated region.detect when comparing multiple providers, providing direct usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | No | Cloud provider to detect region for (defaults to aws) |
| Name | Required | Description |
|---|---|---|
| region | Yes | Detected or default region |
| source | Yes | Where the region value came from |
| message | Yes | Human-readable detection summary |
| provider | Yes | Cloud provider id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint, and the description adds 'Read-only; does not change cloud config' and mentions it resolves from env/config or default, providing useful behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each adding essential information: purpose, usage guidelines, and behavioral trait. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one enumerated parameter and output schema, the description covers purpose, usage, behavioral traits, and sibling differentiation completely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter is well-described in the schema. The description does not add new parameter details but is consistent. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'resolve' and resource 'active region', and explicitly distinguishes from sibling 'providers.detect' by saying 'for one cloud provider' versus comparing multiple providers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to call ('before suggestions.generate/deploy.run when targeting a single provider') and when to use an alternative ('Prefer providers.detect instead when comparing...'). Also gives rationale about pricing and placement matching.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| region | No | Cloud provider region | |
| outcome | Yes | Natural language description of the desired outcome | |
| provider | No | Filter to specific cloud provider | |
| requirements | No | Requirements to rank patterns — use this when responding to a clarificationRequest | |
| crossProvider | No | Include cross-provider suggestions (default: true) | |
| maxMonthlyCostUsd | No | Customer max monthly cost cap in USD — options above the cap are filtered out |
| Name | Required | Description |
|---|---|---|
| options | Yes | |
| outcome | Yes | |
| resultId | Yes | |
| infraType | Yes | |
| providers | Yes | Providers covered by the options |
| optionCount | Yes | Number of suggestion options returned |
| clarificationRequest | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which are consistent with the description's portrayal of a non-destructive suggestion generator. The description adds behavioral context: it handles clarification requests, requires explicit choice before deployment, and has auto-DNS behavior. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively long but well-structured with step numbers and conditional logic. It front-loads the key message 'START HERE' and uses imperative sentences. Every sentence serves a purpose, though it could be slightly streamlined without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 params, nested objects, output schema exists), the description fully covers the tool's role in the workflow, interaction pattern (clarification request), and special cases (auto-DNS). It is complete enough for an agent to use correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema parameter coverage, the schema already details each parameter. The description adds value by explaining how to use region (detected from step 1), requirements (when responding to clarificationRequest), and maxMonthlyCostUsd (filters options). This is above the baseline of 3 for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'START HERE for any deployment' and outlines a clear two-step process: first detect region/provider then call this tool. It specifies the output as 'Starter/MVP/Startup/Enterprise options with monthly costs' and distinguishes from siblings by positioning itself as the second step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: after region.detect or providers.detect. It also covers conditional scenarios like handling clarificationRequest, waiting for explicit choice before deploy.run, and auto-DNS when domain and CLOUDFLARE_API_TOKEN are set. This differentiates it from sibling tools like deploy.run and region.detect.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.5.0billing.balancebilling.top_upcredentials.listdeploy.destroydeploy.listdeploy.rundeploy.statusdeploy.teardown_latestpricing.getproviders.detectregion.detectsuggestions.generateEach 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Designs, prices, and deploys AWS/GCP cloud infrastructure from plain-English requirements.
Your AI Agent's Infrastructure Layer. Connect Claude, Copilot, Codex, or ChatGPT to 200+ managed open source services. Start databases, pipelines, and applications through natural language.
Compare, estimate, and deploy cloud infrastructure across AWS, GCP, and Azure for AI agents.
Unified API to query AWS, GCP, Azure and generate Terraform/CLI execution kits for AI agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/TravisLinkey/provision-stack-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
