devops-status-mcp-server
Server Details
Vendor status pages, TLS cert inspection, DNS propagation checks, and incident-response playbooks.
- 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 4.6/5 across 7 of 7 tools scored.
Each tool has a clearly distinct purpose: cert health, DNS resolution, incident history, vendor listing, status check, action suggestion, and stack monitoring. No two tools overlap in function.
All tools use 'devops_' prefix and mostly follow the verb_noun pattern (e.g., check_certs, get_incidents). However, 'status_check' inverts this to noun_verb, a minor inconsistency.
7 tools is well-scoped for a DevOps monitoring server, covering certificate, DNS, vendor status, incidents, and action suggestions without unnecessary bloat.
The surface covers key monitoring tasks (cert, DNS, vendor health, incidents, stack) but lacks historical trends or more granular component drill-down, leaving minor gaps.
Available Tools
7 toolsdevops_check_certsDevops Check CertsARead-onlyIdempotentInspect
Inspect SSL/TLS certificate health for one or more domains by performing a real TLS handshake. Works for any internet-accessible domain — no vendor registry required. Reports days to expiry (flagged at < 30 days warning and < 7 days critical), certificate subject and SANs, issuer, chain depth, TLS protocol version negotiated (flags TLS 1.0/1.1 as insecure), cipher suite, and HSTS presence.
| Name | Required | Description | Default |
|---|---|---|---|
| port | No | TLS port. Defaults to 443. Use 8443 or custom ports for non-standard HTTPS endpoints. | |
| domains | Yes | Domains to inspect. Do not include "https://" — pass the bare hostname. Up to 10 per call. | |
| timeout_ms | No | Connection timeout per domain in milliseconds. Defaults to the DEVOPS_STATUS_CERT_TIMEOUT_MS env var (5000 when unset). Increase for slow or geographically distant endpoints. |
Output Schema
| Name | Required | Description |
|---|---|---|
| results | Yes | Per-domain certificate inspection results. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint. The description adds value by detailing the handshake process, reported fields (expiry threshold flags, TLS version flags), and no vendor dependency. It does not contradict 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?
The description is a single concise paragraph with four sentences, front-loading purpose and listing reported fields without redundancy. Every sentence adds value.
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 presence of an output schema, the description adequately covers tool purpose, usage context, parameter details, and expected return fields. It is sufficiently complete for agent decision-making.
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 parameter descriptions. The description adds useful context beyond schema: domain limit of 10, prohibition of 'https://', and timeout env var default. This enhances understanding.
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 inspects SSL/TLS certificate health for domains via a real TLS handshake. It distinguishes from siblings like devops_check_dns by focusing on certificate data and emphasizing no vendor registry required.
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: use for certificate health checks on any internet-accessible domain. It implies it won't work for internal domains, but lacks explicit when-not-to-use or direct alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
devops_check_dnsDevops Check DnsARead-onlyIdempotentInspect
Resolve DNS records and verify propagation for one or more domains across multiple public resolvers. Works for any domain — no vendor registry required. Reports records found (A/AAAA/CNAME/MX/TXT/NS), resolution latency per resolver, and discrepancies between resolvers (propagation gaps).
| Name | Required | Description | Default |
|---|---|---|---|
| domains | Yes | Domain names to query. Up to 10 per call. | |
| resolvers | No | Resolver IP addresses to query. Defaults to Google (8.8.8.8), Cloudflare (1.1.1.1), and Quad9 (9.9.9.9). Add custom resolvers to check internal DNS or test resolver-specific behavior. | |
| timeout_ms | No | Query timeout per domain+resolver combination in milliseconds. Defaults to the DEVOPS_STATUS_DNS_TIMEOUT_MS env var (3000 when unset). | |
| record_types | No | DNS record types to resolve. Defaults to A, AAAA, MX, and TXT. Add NS to check nameserver delegation. Add CNAME when investigating redirect chains. |
Output Schema
| Name | Required | Description |
|---|---|---|
| results | Yes | Per-domain DNS resolution results. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only, open-world, and idempotent behavior. The description adds that it reports records, latency, and discrepancies, which is consistent and provides extra context.
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 sentences long, efficient, and front-loaded with the core function. It could be slightly tighter but is well-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?
With an output schema present and all parameters documented, the description fully covers the tool's purpose, inputs, and outputs. 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%, and the description adds value by explaining use cases for record types and resolvers (e.g., 'Add NS to check nameserver delegation'). This goes beyond the schema definitions.
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 resolves DNS records and verifies propagation across multiple resolvers. It distinguishes from siblings by focusing on DNS checks, not certs or incidents.
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 mentions it works for any domain without a vendor registry, but it does not explicitly say when not to use it or provide alternatives among siblings. Context implies DNS troubleshooting usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
devops_get_incidentsDevops Get IncidentsARead-onlyIdempotentInspect
Fetch incident history and scheduled maintenance windows for a vendor. Returns full incident timeline — each investigator update, affected components, and resolution. Filter by status to focus on active incidents (use before deploy), resolved history (for postmortem), or upcoming maintenance windows.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum incidents to return. Vendor status APIs return at most ~50 recent entries per call. Use a lower limit for recent-history queries. | |
| filter | No | all: incidents plus scheduled maintenances. active: only incidents with status investigating/identified/monitoring. resolved: only fully resolved incidents. scheduled: only scheduled maintenance windows. | all |
| vendor | Yes | Vendor slug (e.g., "github", "aws") or raw Atlassian Statuspage base URL. Use devops_list_vendors to find slugs. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | No | The limit that was applied. Present only when truncated. |
| name | Yes | Display name of the vendor. |
| shown | No | Number of incidents returned after applying the limit. Present only when truncated. |
| vendor | Yes | Vendor slug or URL as provided. |
| incidents | Yes | Matching incidents. |
| truncated | No | True when more incidents matched than the limit returned. Absent when the result was not capped. |
| statuspage_url | Yes | Status page base URL used. |
| total_returned | Yes | Number of incidents in the response. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, openWorldHint, and idempotentHint, so the bar is lowered. The description adds behavioral details beyond annotations: it explains the return format (full timeline with updates, components, resolution) and notes that vendor APIs return at most ~50 entries, providing rate limit context. 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?
The description is a single, well-structured paragraph that front-loads the main purpose. Every sentence adds meaningful information without redundancy. It is concise yet comprehensive.
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 simplicity (3 parameters, output schema exists, annotations cover safety), the description is fully complete. It explains input, output structure, usage scenarios, and constraints. No missing information that would hinder correct invocation.
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 extra value: for 'limit', it explains the vendor API limit and suggests lower values; for 'filter', it describes each enum; for 'vendor', it clarifies acceptable inputs and references the sibling tool. This goes beyond the schema alone.
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 that the tool 'Fetch incident history and scheduled maintenance windows for a vendor' using the verb 'Fetch' and specifies the resource. It distinguishes itself from siblings like devops_status_check (current status) and devops_list_vendors (vendor listing) by emphasizing incident history and timeline details.
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 usage guidance: recommends using filter 'active' 'before deploy', 'resolved' for 'postmortem', and 'scheduled' for maintenance. It also directs users to devops_list_vendors for finding vendor slugs, effectively covering when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
devops_list_vendorsDevops List VendorsARead-onlyIdempotentInspect
List vendors in the built-in registry, optionally filtered by category or name search. Returns slug, display name, category, and status page URL for each entry. Use to discover the correct slug to pass to other tools, or to see which vendors are available before configuring a stack.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Free-text search against vendor name and slug. Case-insensitive. E.g., "cloud", "auth", "slack". | |
| category | No | Filter to one category: cloud, cdn-edge, dev-platform, data, comms, auth, monitoring, or ai. |
Output Schema
| Name | Required | Description |
|---|---|---|
| total | Yes | Total number of vendors returned. |
| vendors | Yes | Matching vendors from the built-in registry. |
| categories | Yes | All available category values for use in the category filter. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly=true and idempotent=true, so description doesn't need to repeat that. It adds value by listing return fields (slug, display name, category, status page URL). Minor gap: no mention of pagination or result size, but plausible that the dataset is small.
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, no wasted words. First sentence states purpose and scope; second sentence gives use cases and return fields. Front-loaded and efficient.
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 simplicity (2 optional params, output schema exists, strong annotations), the description covers all essential aspects: purpose, filtered options, return values, and concrete use cases. Nothing important is missing.
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. Description adds context: 'free-text search against vendor name and slug, case-insensitive' and examples for query ('cloud', 'auth', 'slack'). This extra information improves understanding beyond the schema alone.
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 (List), resource (vendors in built-in registry), and scope (optionally filtered by category or name search). It distinguishes from sibling tools, none of which list vendors.
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: 'discover the correct slug to pass to other tools' and 'see which vendors are available before configuring a stack'. No exclusions needed given the tool's simplicity and clear purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
devops_status_checkDevops Status CheckARead-onlyIdempotentInspect
Check the current health status for one or more vendors. Accepts registered vendor slugs (e.g., "github", "aws", "gitlab") or raw Atlassian Statuspage base URLs. Registry entries are served by each vendor's native status API (Statuspage, Status.io, Slack, AWS Health, Firehydrant) and normalized to one shape. Returns per-vendor operational indicator (none = all clear, minor, major, critical), degraded components, and active incidents. Use mode: "detailed" for full component lists and maintenance windows. Batch-friendly — pass a list to check your full stack in one call.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | summary: indicator + degraded components + active incidents only. detailed: adds full component list and scheduled maintenance windows. | summary |
| vendors | Yes | Vendor slugs from the built-in registry (e.g., "github", "aws") or raw Atlassian Statuspage base URLs (non-Statuspage backends are supported via registry slugs only). Mix freely. Use devops_list_vendors to discover available slugs. |
Output Schema
| Name | Required | Description |
|---|---|---|
| results | Yes | Per-vendor status results in the same order as the input vendors list. |
| summary | Yes | Aggregate health counts across all checked vendors. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, idempotentHint, openWorldHint. Description adds context: normalization to one shape, per-vendor indicators, components, incidents. Consistent with annotations; 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?
Three sentences, front-loaded with purpose, then details, then usage tips. No redundant information; every sentence adds value.
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 an output schema present, description covers purpose, parameters, modes, batch usage, and relationship to sibling tools. Complete for the tool's complexity.
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 covers 100% of parameters, but description adds significant meaning: explains slug examples, mixing slugs and URLs, mode behavior (summary vs detailed), and batch limits. Goes beyond 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?
Clearly states the tool checks health status for vendors, distinguishes from siblings like devops_check_certs and devops_check_dns by focusing on overall health. Provides specific examples of vendor slugs and URL types.
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?
Explains batch-friendly usage, modes (summary/detailed), and references devops_list_vendors for discovery. Lacks explicit when-not-to-use but gives clear context for typical use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
devops_suggest_actionDevops Suggest ActionARead-onlyIdempotentInspect
Return an incident-response playbook tailored to a vendor degradation, with pre-filled follow-up tool calls. Synthesizes category-specific guidance (cloud, CDN, dev-platform, auth, etc.) from built-in incident knowledge and the provided context. Use after devops_status_check or devops_get_incidents surfaces a problem to determine what to investigate next.
| Name | Required | Description | Default |
|---|---|---|---|
| vendor | Yes | Vendor slug or display name (e.g., "cloudflare", "github"). Used to tailor category-specific guidance (CDN outage vs. CI/CD outage vs. auth provider outage). | |
| your_domain | No | Your own domain or service URL. When provided, nextToolSuggestions will be pre-filled with your domain for cert and DNS checks. | |
| incident_summary | No | Latest incident description or update body from devops_get_incidents. Paste the most recent update to get more targeted advice. | |
| vendor_indicator | No | Overall vendor status indicator from a prior devops_status_check call (its indicator field). When provided, the playbook leads with severity-tailored urgency guidance. Omit if status has not been checked yet. | |
| affected_components | No | Component names affected (from devops_status_check degraded_components or devops_get_incidents affected_components). Used to tailor suggestions to the impacted subsystem. |
Output Schema
| Name | Required | Description |
|---|---|---|
| vendor | Yes | Vendor as provided. |
| guidance | Yes | Markdown playbook — immediate steps, diagnostic checks, mitigation options, and what to monitor for resolution. Tailored to the vendor category, reported severity, and affected components. |
| vendor_category | Yes | Detected category from registry (e.g., "cdn-edge", "auth"). Null for unrecognized vendors. |
| diagnostics_summary | Yes | Summary of input context used to generate the playbook. |
| nextToolSuggestions | Yes | Recommended follow-up calls with arguments already populated. Execute these in sequence to gather diagnostic data. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and idempotentHint=true. The description adds context that the tool synthesizes category-specific guidance from built-in knowledge and pre-fills follow-up calls. No contradictions. It could mention that no data is modified, but overall transparent.
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: first states main purpose clearly, second adds usage context and built-in knowledge. No wasted words, front-loaded, efficient.
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 5 parameters, 1 required, and existing output schema, the description covers purpose, usage, parameter semantics, and mentions pre-filled follow-up calls. No gaps for this complex 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?
Schema coverage is 100% and the description adds meaning to each parameter: vendor tailors guidance, your_domain pre-fills suggestions, incident_summary provides targeted advice, vendor_indicator adds severity guidance, affected_components tailors to subsystem. Enhances schema definitions.
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 returns an incident-response playbook tailored to vendor degradation with pre-filled follow-up calls. It distinguishes from siblings by specifying use after devops_status_check or devops_get_incidents.
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 says 'Use after devops_status_check or devops_get_incidents surfaces a problem to determine what to investigate next', providing clear context. It does not explicitly state when not to use, but the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
devops_watch_stackDevops Watch StackAIdempotentInspect
Check the health of a named vendor stack — a saved list of vendors representing your infrastructure dependencies. On the first call, provide vendors to define the stack; subsequent calls can omit vendors to reuse the persisted list. Returns a unified health snapshot with an aggregate rollup plus per-vendor detail. Ideal for morning status checks or pre-deploy sweeps. Multiple stacks can coexist (e.g., "production", "staging").
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | summary: indicator + degraded components + active incidents. detailed: adds full component lists and maintenance windows. | summary |
| vendors | No | Vendor slugs (e.g., "github", "aws") or raw Atlassian Statuspage base URLs. When provided, saves this list as the stack. When omitted, uses the previously saved list for stack_name. | |
| stack_name | No | Name for this vendor stack. Defaults to "default". Use distinct names to manage multiple stacks (e.g., "production", "data-layer"). | default |
Output Schema
| Name | Required | Description |
|---|---|---|
| health | Yes | Aggregate health rollup: all_operational = everything clear, degraded = at least one minor issue, partial_outage = at least one major issue, major_outage = at least one critical outage. |
| summary | Yes | Aggregate health counts across all checked vendors. |
| vendors | Yes | Per-vendor status results. |
| checked_at | Yes | ISO 8601 UTC timestamp of this check. |
| stack_name | Yes | Name of the stack checked. |
| stack_persisted | Yes | True when the vendor list was saved to state on this call. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and idempotentHint=true. The description reinforces this by stating that providing vendors saves the list, and subsequent calls reuse it. No contradictions. Provides clear behavioral insight without relying solely on 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?
Four sentences, front-loaded with primary action. Every sentence contributes: purpose, persistence behavior, return content, use cases, and multi-stack support. 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?
Given the tool's complexity (3 params, enums, stateful behavior, output schema exists), the description covers all essential aspects: what it does, how to use it initially and subsequently, what it returns, ideal contexts, and stack management. 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?
Schema description coverage is 100%, so baseline is 3. The description adds value by explaining the vendors parameter's first-call vs later-call behavior and the stack_name parameter's naming purpose, improving semantic understanding 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 tool checks the health of a named vendor stack, distinguishing it from sibling tools that focus on individual checks (e.g., certs, DNS) or generic status. It explains first-call vs subsequent-call behavior, making the purpose unambiguous.
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 suggests use cases: 'morning status checks or pre-deploy sweeps.' Also explains persistence behavior and multiple stacks, guiding when to provide vendors. Lacks explicit exclusion or alternative recommendations, but context is sufficient.
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!