Provision Stack
Server Details
Outcome-based infrastructure for agents — verified AWS deployments, metered billing
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.8/5 across 10 of 12 tools scored. Lowest: 2.3/5.
Each tool targets a distinct aspect of the provisioning workflow. Deploy, destroy, and teardown_latest are clearly differentiated by scope; detect_providers and detect_region serve separate steps; all getters and listers are uniquely identifiable.
All tool names follow a consistent lowercase underscore-separated pattern, predominantly verb_noun (e.g., detect_providers, generate_suggestions) with a few concise verbs (deploy, destroy, top_up). No mix of conventions.
12 tools cover the full deployment cycle without bloat. Each tool serves a necessary function, and the count is well-scoped for a provisioning server.
Core lifecycle actions (deploy, destroy, status, suggestions, pricing, account management) are present. Minor gaps like an update or scale tool are absent, but the set enables complete agent-driven provisioning.
Available Tools
12 toolsdeployAInspect
Provision the explicitly selected suggestion through the Execution API. Never call before presenting options and receiving user approval. The deploy fee is held from the account credit balance and captured only after verification passes (failed deployments are free). On HTTP 402, call top_up and retry.
| Name | Required | Description | Default |
|---|---|---|---|
| tier | No | Selected suggestion tier; defaults to MVP | |
| region | No | ||
| outcome | Yes | Natural language deployment objective | |
| provider | No | Cloud provider (auto-detected from resources if omitted) | |
| projectId | No | ||
| 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses fee handling (held from credit balance, captured after verification, free on failure) and error recovery (HTTP 402). Lacks details on permissions or side effects, but good overall.
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, no wasted words. Front-loaded with main action, then usage constraint, then fee behavior and error handling. Highly efficient and structured.
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 no annotations, no output schema, and 7 parameters with siblings, the description covers core purpose, usage constraints, cost behavior, and error recovery. Missing details on return value or prerequisites, but adequately complete for an 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 description coverage is 71%, so baseline is 3. Description does not add extra meaning beyond the schema; it mainly reiterates context for usage but doesn't clarify individual parameters further.
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 provisions a selected suggestion via the Execution API. It uses a specific verb ('provision') and resource ('selected suggestion'), and distinguishes from siblings like 'destroy' and 'generate_suggestions'.
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 'Never call before presenting options and receiving user approval', providing clear when-to-use guidance. Also specifies handling HTTP 402 by calling 'top_up' and retrying, giving an alternative action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
destroyCInspect
Destroy all resources owned by a deployment.
| Name | Required | Description | Default |
|---|---|---|---|
| reason | No | ||
| deploymentId | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states that the tool destroys all resources, but omits details about reversibility, permission requirements, side effects, or behavior on failure.
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 a single sentence with no wasted words. It is concise, though it could benefit from adding key details without becoming verbose.
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 destructive nature, two parameters, no output schema, and no annotations, the description is incomplete. It lacks information on return value, success/failure indicators, and preconditions.
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 description adds no meaning to parameters beyond the schema. Schema description coverage is 0%, so the description should compensate, but it only mentions 'deployment' without explaining the 'reason' parameter or the format of '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?
The description clearly states the verb 'destroy' and the resource 'resources owned by a deployment', making the purpose unambiguous. It also helps distinguish from sibling tools like 'teardown_latest' which likely targets only the latest deployment.
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?
No guidance is provided on when to use this tool versus alternatives (e.g., 'teardown_latest'). There is no mention of prerequisites, warnings, or conditions under which the tool should or should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
detect_providersAInspect
Detect all configured cloud providers and their regions. Returns a list of providers with their detected regions and configuration status.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden, stating it returns a list of providers with regions and config status, indicating a read-only operation without side effects.
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 redundancy; front-loaded with purpose and return value, every word 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?
Given zero parameters and no output schema, the description fully explains the expected return value and behavior, leaving 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, so baseline of 4 applies; description adds no further parameter info as none are 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 verb 'detect' and the resource 'configured cloud providers and their regions', distinguishing it from sibling tools like detect_region.
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?
While no explicit when-to-use or alternatives are mentioned, the tool's zero-parameter nature and straightforward purpose make usage clear; implicit context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
detect_regionInspect
Detect the configured region for a cloud provider. Call this before generate_suggestions.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | No | Cloud provider to detect region for (defaults to aws) |
generate_suggestionsAInspect
START HERE for any deployment. STEP 1: Call detect_region or detect_providers. 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.
| 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description transparently explains the call flow and clarification mechanism. It could mention that no deployment occurs, but the context implies it.
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?
Well-structured with step numbering and front-loaded key information. Every sentence serves a purpose without 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?
Despite no output schema, the description covers the workflow end-to-end, including prerequisites and post-conditions, making it complete for a complex tool with 6 parameters.
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?
Adds significant meaning beyond schema by explaining how parameters like 'requirements' are used in response to clarificationRequest and how 'maxMonthlyCostUsd' filters options.
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 it returns deployment options with monthly costs and positions it as the starting step for deployment, distinguishing it from sibling tools like detect_region and detect_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?
Provides explicit step-by-step instructions: call detection tools first, then this tool, handle clarification requests by answering and recalling, and present options before deploy.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_balanceAInspect
Get the account credit balance (total, held, available USD). Call this when deploy fails with HTTP 402 insufficient_credits.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description adequately describes a read-only operation with no side effects; no contradictions or missing critical behavior.
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, front-loaded with purpose, 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?
Tool is simple, no parameters, no output schema; description covers return fields and a specific use case, fully adequate.
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?
Zero parameters, so schema coverage is 100%; description adds no extra parameter info, but baseline for zero parameters is 4.
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 'Get the account credit balance' with specific fields (total, held, available USD), distinguishing it from sibling tools like top_up or list_deployments.
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 'Call this when deploy fails with HTTP 402 insufficient_credits', providing a specific trigger scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_deployment_statusInspect
Check deployment progress and retrieve verification evidence when complete.
| Name | Required | Description | Default |
|---|---|---|---|
| deploymentId | Yes |
get_pricingCInspect
Get a detailed monthly estimate for a cloud resource.
| Name | Required | Description | Default |
|---|---|---|---|
| zone | No | ||
| ocpus | No | ||
| shape | No | ||
| region | No | ||
| sizeGb | No | ||
| vmSize | No | ||
| provider | No | Cloud provider (auto-detected from resourceType if omitted) | |
| storageGb | No | ||
| volumeType | No | ||
| machineType | No | ||
| memoryInGbs | No | ||
| instanceType | No | ||
| resourceType | Yes | ||
| instanceCount | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only mentions 'estimate,' implying a read-only operation, but does not explicitly state it is non-destructive or whether it makes any modifications. Lacks detail on side effects or permissions.
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 a single short sentence, but it omits critical information, making it under-specified rather than appropriately concise. Every word is earned, but it fails to provide sufficient 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?
With 14 parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain how to use the tool, what the estimate includes, or how parameters like 'resourceType' affect the estimate. The agent cannot confidently invoke this tool correctly.
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 description coverage is only 7%, and the description adds no parameter semantics. None of the 14 parameters are explained. The agent cannot determine which parameters are relevant for a given resource type.
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's purpose: getting a detailed monthly estimate for a cloud resource. The verb 'get' and resource 'pricing' are specific. However, it does not distinguish from sibling tools beyond the general domain.
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?
No guidance on when to use this tool versus alternatives. No mention of prerequisites or context. The description does not help the agent decide when to invoke this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_credentialsBInspect
Check cloud provider credential configuration without exposing secrets.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | No | Cloud provider to check (defaults to checking all) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. The only behavioral detail is that secrets are not exposed, which is useful but insufficient. No mention of side effects, authentication requirements, or rate limits.
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 a single concise sentence that conveys the core purpose and a key safety 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 optional parameter and no output schema, the description is somewhat complete but does not explain what the check returns (e.g., validity, expiry). The safety note is good, but more detail on output would improve completeness.
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 description adds no additional meaning beyond the schema's parameter description. Baseline score 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 clearly states the action ('Check') and the resource ('cloud provider credential configuration'), and adds a safety aspect ('without exposing secrets'). It distinguishes from sibling tools, none of which are about checking credentials.
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?
No explicit guidance on when to use this tool versus alternatives, nor when not to use it. The description implies a safe check but lacks context on prerequisites or comparisons with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_deploymentsBInspect
List deployments tracked by the Execution API.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden, but it only states 'list deployments' without detailing what that entails (e.g., whether it returns all deployments, only active ones, pagination, or any side effects). This is insufficient for an agent to predict behavior.
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 a single, efficient sentence with no redundancy. It could benefit from additional context, but it wastes no words given the simplicity of the tool.
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 lack of output schema and the presence of multiple sibling tools, the description should clarify the scope (e.g., 'all deployments' vs 'current environment') and what data is returned. It fails to provide sufficient context for the agent to fully understand the tool's role.
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?
There are zero parameters, so schema coverage is 100% by default. The description is not required to add parameter detail, and it appropriately omits it.
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 identifies the action ('List') and the resource ('deployments'), and the context ('tracked by the Execution API'). This differentiates it from sibling tools like deploy or destroy, though it doesn't explicitly compare.
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?
No guidance is provided on when to use this tool versus alternatives like get_deployment_status. The description assumes the agent will infer, but explicit usage context is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
teardown_latestAInspect
Destroy the newest active deployment, or all active deployments when all=true.
| Name | Required | Description | Default |
|---|---|---|---|
| all | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the destructive action and the conditional behavior based on the 'all' parameter, but lacks additional context such as irreversibility or confirmation steps, which would be valuable for a destructive tool.
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?
Single sentence of 12 words conveys the tool's purpose and parameter behavior efficiently with 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?
The description covers the basic functionality and parameter, but given the simplicity and lack of output schema, it could benefit from mentioning prerequisites or differentiation from the sibling 'destroy' tool.
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 0% schema description coverage, the description compensates by explaining that setting 'all=true' destroys all active deployments instead of just the newest, adding meaning beyond the boolean type.
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, which is specific and distinct from siblings like 'destroy' which likely targets a specific deployment.
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 implies usage context (destroy newest or all deployments) but does not explicitly advise when not to use it or compare it to alternatives like 'destroy' or 'deploy'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
top_upAInspect
Add credits to the account. rail=xrp returns an XRP deposit address, REQUIRED destination tag, and exact unique amount to send (credited automatically on ledger confirmation — agent pays). rail=stripe returns a Stripe Checkout URL (human pays).
| 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) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that xrp returns a deposit address, required destination tag, and exact amount for automatic credit, while stripe returns a checkout URL for human payment. This adequately informs the agent of the behavioral differences and outcomes.
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 two concise sentences with no fluff. The first sentence is a high-level summary, and the second provides necessary detail for each rail. Every word 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?
For a tool with no output schema, the description adequately explains what each rail returns. It covers the main behaviors but could mention potential errors or prerequisites (e.g., account existence) for completeness.
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 is 3. The description adds value by explaining the behavioral difference between rail values and the required nature of the destination tag for xrp, going beyond the schema's enum 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 clearly states the tool adds credits to the account using two distinct payment rails, which sets it apart from sibling tools like deploy, destroy, get_balance, etc. The verb 'Add credits' and resource 'account' are specific, and the rail differentiation adds clarity.
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 explains when to use each rail (agent vs human pays) and what each returns, providing clear context. However, it lacks explicit 'when not to use' or comparison with alternatives, but the sibling context makes this implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!