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.4/5 across 7 of 7 tools scored.
Each tool targets a distinct type of resource (certs, DNS, vendor status, incidents, vendors list, action suggestions, stack health). There is some conceptual overlap among the 'check' tools, but descriptions clarify the different domains, making it unlikely an agent would confuse them.
All tools share the 'devops_' prefix, but verb patterns vary: 'check' is used twice, and 'status_check' breaks the verb_noun pattern. The mix is still readable, but inconsistent naming may slow tool selection.
Seven tools cover core devops monitoring workflows without bloat: health checks, DNS, certificates, incident history, vendor listing, and a stack feature. The count feels well-scoped for the server's purpose.
The tool set provides a logical pipeline (list vendors → check status → drill into incidents/DNS/certs → suggest action). Minor gaps like missing vendor registry management are acceptable given the built-in registry.
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. 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?
The description goes far beyond the annotations (readOnlyHint, openWorldHint, idempotentHint) by detailing the exact checks performed: days to expiry with thresholds (30-day warning, 7-day critical), subject/SANs, issuer, chain depth, TLS protocol version (flagging 1.0/1.1), cipher suite, and HSTS presence. 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?
The description is a single, well-structured paragraph. Every sentence contributes necessary information without redundancy. It is appropriately sized given the tool's complexity.
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 (not shown), the description covers all input behavior and result details (expiry, issuer, protocol, etc.). Thresholds and flags are clearly documented, making it complete for an agent to understand what to expect.
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. The description adds value by explaining usage nuances: port defaults to 443 and suggests 8443 for non-standard, domains must be bare hostnames without protocol, timeout_ms can be increased for slow endpoints. This enhances understanding but schema already documents base meanings.
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 (inspect SSL/TLS certificate health), the resource (certificates for one or more domains), and the method (real TLS handshake). It distinguishes itself from siblings like devops_check_dns by focusing on certificates.
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?
It specifies that the tool works for any internet-accessible domain without a vendor registry, implying universal applicability. While it doesn't explicitly list when not to use or name alternatives, the context is clear and siblings cover different domains (e.g., DNS, incidents).
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. | |
| 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 already indicate read-only, open-world, and idempotent behavior. The description adds context about reporting latency and discrepancies across resolvers, which is not covered by annotations, enriching transparency.
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 concise, with two dense sentences that front-load the core purpose and outputs. Every sentence adds value 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?
Given four parameters and an output schema (not shown but referenced), the description adequately covers purpose, scope, and reporting details. It could be slightly more explicit about the output schema format, but overall sufficient.
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 the baseline is 3. The description does not add detailed parameter information beyond the schema, but the schema already provides clear descriptions with defaults and examples.
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 resolves DNS records and verifies propagation across multiple resolvers, listing record types and outputs. It distinguishes itself from sibling tools focused on certificates, incidents, etc.
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 vendor registry, providing usage context. However, it does not explicitly state when not to use it or compare to alternatives like devops_check_certs, though the differentiation is implied.
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. Statuspage returns at most 50 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") or raw Statuspage base URL. Use devops_list_vendors to find slugs. |
Output Schema
| Name | Required | Description |
|---|---|---|
| name | Yes | Display name of the vendor. |
| vendor | Yes | Vendor slug or URL as provided. |
| incidents | Yes | Matching incidents. |
| statuspage_url | Yes | Statuspage 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 read-only, idempotent, and open-world. Description adds detail on return content: full timeline, investigator updates, affected components, resolution. 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 sentences, front-loaded with purpose, no wasted words. Efficient and clear.
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, the description is complete: it explains purpose, return content, filtering, and use cases. 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 covers 100% of parameters with descriptions. Description reinforces the filter usage but doesn't add significant new meaning 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 verb 'Fetch' and the resources 'incident history and scheduled maintenance windows'. It distinguishes itself from sibling tools like devops_check_certs, devops_check_dns, etc., which cover different domains.
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 usage scenarios: 'use before deploy' for active incidents, 'for postmortem' for resolved history, and mentions upcoming maintenance windows. It doesn't explicitly exclude alternatives but context is clear.
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 Statuspage base 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 declare read-only and idempotent; description adds that it returns slug, display name, category, and Statuspage URL, which is sufficient and non-contradictory.
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 action and filters, no redundant information.
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?
Output schema exists, description covers return fields and use cases; complete for a simple list 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%; description adds value by stating query is case-insensitive and providing examples, going 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?
Description states 'List vendors in the built-in registry' with specific filters, clearly distinguishing it from sibling tools like devops_check_certs and devops_status_check.
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 to discover the correct slug to pass to other tools, or to see which vendors are available before configuring a stack', providing clear context but no exclusion criteria.
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", "cloudflare") or raw Statuspage base URLs. 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", "cloudflare") or raw Statuspage base URLs. 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 already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=true. The description adds details about returned data (indicators, degraded components, incidents) and batch limits, enhancing transparency without 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 three sentences, front-loaded with the main purpose. Each sentence adds value: purpose and inputs, mode explanation, batch friendliness and related tool reference. Concise with 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?
Given that an output schema exists, the description does not need to detail return format. It covers input types, mode options, batch limits, and references a sibling tool for discovery. Adequate for a health check 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% with descriptions for both parameters. The description adds meaning by clarifying that vendors can be slugs or raw URLs and by explaining the mode values beyond the schema 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 verb 'Check', the resource 'health status', and the scope 'for one or more vendors'. It distinguishes itself from sibling tools like devops_check_certs and devops_check_dns by focusing on overall health status.
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 acceptable inputs (slugs or raw URLs), mentions a mode option for detail level, and advises using devops_list_vendors to discover slugs. It does not explicitly state when not to use, but provides sufficient context.
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. | |
| 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 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 already indicate read-only and idempotent. The description adds that it returns a playbook with pre-filled tool calls and synthesizes guidance from built-in knowledge and context, 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: first states purpose and function, second gives usage context. No wasted words, front-loaded.
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 4 params, output schema (not needing explanation), and 6 siblings, the description is complete: explains purpose, usage timing, and what it synthesizes. Output schema exempted per rubric.
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 each parameter described. The description does not add new parameter semantics beyond the schema, so baseline 3 applies.
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 with pre-filled follow-up calls, tailored to vendor degradation. It synthesizes category-specific guidance, distinguishing it from siblings like 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?
Explicitly says 'Use after devops_status_check or devops_get_incidents surfaces a problem', providing clear context for when to invoke. Could mention when not to use, but the directive is strong.
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 StackARead-onlyIdempotentInspect
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 or raw Statuspage 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?
Adds value beyond annotations by describing first-call vs. subsequent-call behavior and persistence of vendor list. Annotations already declare readOnly, openWorld, idempotent; description complements with operational nuance.
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 focused sentences covering purpose, usage pattern, return type, and multiplicity. No fluff; front-loaded with verb and resource.
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 3 optional parameters, clear schema, and output schema, the description covers setup, reuse, multiple stacks, and output nature. Fully sufficient for an agent to decide when and how to invoke.
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 description repeats or slightly elaborates on parameter roles (e.g., mode options, vendors as slugs/URLs). No new constraints beyond schema, but 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?
Clearly states it checks health of a named vendor stack, explains stack definition and reuse, and gives concrete use cases. Distinguishes from sibling tools by focusing on aggregate health vs. individual checks.
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 mentions ideal use cases (morning status checks, pre-deploy sweeps) and implies stack management with multiple stacks. Does not explicitly list when not to use or alternatives, 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!