Skip to main content
Glama
TravisLinkey

Provision Stack MCP

by TravisLinkey

region.detect

Read-onlyIdempotent

Detects the configured region for a cloud provider (AWS, GCP, Azure, or Oracle) from environment variables or configuration. Returns a documented default when unset. Run before deployment to match pricing and placement to local settings.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
providerNoCloud provider to detect region for (defaults to aws)

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
regionYesDetected or default region
sourceYesWhere the region value came from
messageYesHuman-readable detection summary
providerYesCloud provider id
Behavior4/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Install Server

Other 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/TravisLinkey/provision-stack-mcp'

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