Scan a website for vulnerabilities: OWASP Top 10, CVEs, SSL, headers - with plain-English fixes
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.
Average 4.2/5 across 8 of 8 tools scored.
Tools are mostly distinct: billing, scanning websites, scanning AI agents, CVE lookup, and remediation guidance all serve clear separate purposes. The main overlap is between compliance_report and scan_website, both assessing sites but from different angles; however descriptions clarify the distinction.
Most tools follow verb_noun pattern (buy_credits, check_credits, get_fix_guidance, get_pricing, lookup_cves, scan_agent, scan_website). 'compliance_report' is a noun phrase rather than a verb action, slight deviation but not confusing.
8 tools is well-scoped for a security scanning service. Each tool covers a necessary function: billing, pricing, scanning, compliance, CVE lookup, and remediation guidance, without unnecessary bloat.
The surface provides core lifecycle coverage for the domain: scanning (web and AI agent), compliance assessment, vulnerability intelligence, fix guidance, and credit management. Minor gaps exist like scan history or saved reports, but the tools handle real-time needs without dead ends.
buy_creditsAInspectGet a secure Stripe checkout link to buy an AI credit pack for the signed-in account. Requires a ScanLabsAI API key in the MCP connection. Credits are added automatically once payment completes. Packs: starter (5), pro (15), agency (50).
| Name | Required | Description | Default |
|---|---|---|---|
| pack | No | Pack id: starter, pro, or agency. Defaults to pro. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes on the burden of disclosing side effects. It explicitly states 'Credits are added automatically once payment completes', indicating a mutation, and notes the API key requirement. This is transparent enough, though it doesn't detail failure modes or full payment flow, which are less critical in this 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, front-loaded, and every sentence carries meaningful information: what it does, prerequisites, side effects, and pack options. No filler or 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?
For a simple tool with one optional parameter and no output schema, the description covers the essential aspects: purpose, prerequisites, behavioral outcome, and pack definitions. It would benefit from a note about the return value (the checkout link), but that is evident from the first sentence.
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 input schema describes the 'pack' parameter only as 'Pack id: starter, pro, or agency'. The description adds crucial semantics by enumerating the packs and their credit amounts ('starter (5), pro (15), agency (50)'), going beyond the schema. Since schema coverage is already 100%, this extra context earns a 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?
The description clearly states a specific action: 'Get a secure Stripe checkout link to buy an AI credit pack'. This distinguishes the tool from siblings like check_credits and get_pricing. It also lists concrete pack options with credit amounts, further clarifying the tool's scope.
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 gives clear context for when to use the tool (when purchasing credits) and notes a prerequisite ('Requires a ScanLabsAI API key in the MCP connection'). However, it doesn't explicitly mention alternatives or when not to use this tool, though siblings make the use case obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_creditsAInspectCheck the signed-in account's AI credit balance. Requires a ScanLabsAI API key in the MCP connection (Authorization: Bearer slai_...). Create one at https://scanlabsai.com/mcp.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the authentication requirement (ScanLabsAI API key) and that it operates on the signed-in account, which is useful behavioral context. It does not mention return format or rate limits, but for a simple read-only balance check this is acceptable.
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: the first states the purpose, the second covers authentication setup. It is front-loaded, concise, and every sentence serves a purpose.
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 zero-parameter, read-only tool with no output schema, the description covers the essential information: what it does, the account context, and the required auth. The expected return value (credit balance) is implied by the description. Missing explicit return format, but not critical for such a simple 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?
The tool has zero parameters, so the baseline is 4. The description adds no parameter-specific details, but there are no parameters to describe, so this 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 tool 'check the signed-in account's AI credit balance' with a specific verb and resource. This distinguishes it from sibling tools like buy_credits, which is about purchasing credits.
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 (checking balance before scanning), but it does not explicitly mention when to use this tool versus alternatives or provide any exclusion criteria. No reference is made to sibling tools like scan_agent or buy_credits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compliance_reportAInspectGenerate a website compliance report — the same automated assessment the ScanLabsAI agency portal runs — covering GDPR/CCPA privacy, WCAG 2.1 AA accessibility, PCI DSS 4.0 payment security and general standards. Returns an overall score, per-category scores and the failing/at-risk checks with recommendations, as Markdown. Requires a ScanLabsAI API key in the connection; costs 1 AI credit per report. Only run against sites you are authorised to assess.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The website URL to assess for compliance, e.g. https://example.com |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the API key requirement, credit cost, Markdown output format, and authorization constraint. It does not mention potential side effects or rate limits, but for a report-generation tool this is reasonably 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?
The description is concise yet complete, covering scope, output, cost, and usage constraint in a few sentences. Each sentence provides necessary information without redundancy, and it is front-loaded with the purpose.
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 standards assessed, the output format and categories, the API key requirement, the credit cost, and authorization. Given the tool's moderate complexity and lack of output schema, this is a thorough and self-contained description.
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 extra parameter details beyond the schema's URL description. The tool's single parameter is well-defined in the schema, so the description provides minimal additional semantic value.
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 generates a website compliance report covering specific standards (GDPR/CCPA, WCAG 2.1 AA, PCI DSS 4.0). This is a specific verb+resource+scope and distinguishes it from sibling tools like scan_website or scan_agent by focusing on compliance assessment.
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: it's for compliance reporting, requires an API key, costs credits, and should only be used on authorized sites. However, it does not explicitly mention alternatives or when not to use it compared to sibling tools like scan_website.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_fix_guidanceAInspectGet detailed, step-by-step remediation guidance for a specific vulnerability or security issue (e.g. "missing Content-Security-Policy header", "SQL injection", a CVE id). Returns actionable fixes.
| Name | Required | Description | Default |
|---|---|---|---|
| issue | Yes | The vulnerability, finding title, or CVE id to fix. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It only states 'Returns actionable fixes,' but does not confirm read-only safety, authorization requirements, or potential side effects, leaving a significant gap for agents.
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, front-loaded with the main purpose, and contains no redundant words. Every element—the verb, resource, examples, and return statement—contributes meaning.
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 tool is simple (one parameter) and the description covers its purpose well. However, with no output schema, the vague 'Returns actionable fixes' does not specify output format or structure, and there is no mention of edge cases or prerequisites, leaving some ambiguity.
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 the schema already documents the 'issue' parameter. The description adds value by providing concrete examples (e.g., 'missing Content-Security-Policy header', 'SQL injection', 'CVE id'), which enrich the schema's generic description and help agents understand valid inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and a clear resource ('detailed, step-by-step remediation guidance'), with concrete examples of issue types. It clearly distinguishes from siblings like lookup_cves or scan_website, which focus on identification rather than remediation.
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 appropriate usage—when a specific vulnerability or security issue needs remediation steps—but does not explicitly state when not to use it or mention alternatives. The context is clear but lacks direct exclusions or comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_pricingAInspectGet ScanLabsAI pricing: the free-first-scan policy and AI credit packs.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the content of the pricing data but does not explicitly confirm this is a read-only operation or mention any authentication needs or side effects. However, the verb 'get' suggests a safe lookup, and no concerning behaviors are indicated.
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, front-loaded sentence that efficiently communicates the tool's purpose. Every word adds value, with no filler or repetition.
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 no parameters and no output schema, the description adequately conveys what the user receives: pricing details including the free-first-scan and credit packs. It could explicitly note that no input is required, but overall it is 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?
The input schema has zero parameters, so the baseline is 4. The description appropriately omits parameter details, as there are none to explain.
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 retrieves ScanLabsAI pricing, specifying the free-first-scan policy and AI credit packs. The verb 'get' and specific resource distinguish it from sibling tools like buy_credits and check_credits.
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 this tool is for viewing pricing information but does not explicitly contrast it with alternatives. It doesn't mention when to use this instead of buy_credits or check_credits, leaving usage context implied rather than direct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_cvesAInspectLook up recent CVEs from the NIST NVD feed, optionally filtered by keyword. Returns id, severity, score and summary.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (1-25). Defaults to 10. | |
| keyword | No | Optional keyword, e.g. "wordpress" or "openssl". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses return fields (id, severity, score, summary) and the 'recent' scope, but does not address potential side effects (e.g., network calls, rate limits, data freshness) or explicitly state that it is read-only. However, the behavior is inherently non-mutating and simple enough for a baseline score.
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 sentence that immediately states the action, resource, and expected output. No extraneous words or repetition—every word 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?
For a simple read-only lookup with two optional parameters and no output schema, the description adequately covers purpose, optional filtering, and return fields. It does not over-explain, leaving trivial details to the schema. Minor omission: no mention of default limit or pagination behavior, but these are present in the schema.
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% for both parameters (limit and keyword), so the description adds little beyond restating the keyword filter. It does imply 'recent' relates to the data source but not parameter details. Baseline 3 is appropriate given the schema already fully documents them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Look up' and clearly identifies the resource ('recent CVEs from the NIST NVD feed') with an optional filter. It distinguishes itself from sibling tools like scan_website or get_fix_guidance by focusing solely on CVE lookup.
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 clearly conveys the tool's purpose and context: fetch recent CVEs with optional keyword filtering. Sibling tools are unrelated, so no explicit exclusion is necessary; the usage context is obvious and unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scan_agentAInspectRed-team an AI agent for security weaknesses — prompt injection, system-prompt leakage, sensitive-data disclosure, unsafe output handling and excessive agency — mapped to the OWASP LLM Top 10, and return a Markdown report. This is agent-to-agent scanning: use it to assess another agent from here. Two target kinds are supported: kind="openai" for an OpenAI-compatible chat-completions endpoint, or kind="mcp" for an MCP server (its tool manifest is audited for tool-poisoning and over-broad capabilities). Requires a ScanLabsAI API key in the connection; each agent scan uses 5 AI credits. Probing is active and adversarial — only scan agents you own or are authorised to test.
| Name | Required | Description | Default |
|---|---|---|---|
| deep | No | Run deeper probes (jailbreak + resource-exhaustion). Defaults to false. | |
| kind | Yes | Target type: "openai" for a chat-completions endpoint, "mcp" for an MCP server. | |
| model | No | Model name for OpenAI-compatible endpoints, e.g. gpt-4o-mini. | |
| apiKey | No | Optional bearer token / API key the target agent requires. Sent to the target only; not stored. | |
| endpoint | Yes | The agent endpoint URL (chat-completions URL, or MCP server URL). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the transparency burden. It discloses active adversarial probing, per-scan credit consumption, output format (Markdown report), and the specific audit behavior for MCP targets (tool-poisoning and over-broad capabilities). While it could also mention potential side effects on the target (e.g., resource exhaustion from deep probes), the 'active and adversarial' warning is sufficient for an agent to understand the tool's impact.
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 efficient and front-loaded, beginning with the primary purpose and then providing essential context (target kinds, prerequisites, authorization). It is slightly long (4 sentences) but every sentence carries unique information: purpose, scope, supported kinds, cost, and safety. No redundancy with the schema is evident.
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, lack of annotations, and absence of an output schema, the description is remarkably complete. It covers the purpose, supported target types (with behavior for each), API key and credit prerequisites, output format, and authorization constraints. It provides enough detail for an agent to correctly select and invoke the tool without needing further clarification.
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 the baseline is 3, but the description adds meaning beyond the schema. It clarifies that kind='mcp' triggers a tool-manifest audit, and it explains the API key distinction (the user's ScanLabsAI key vs. the optional target apiKey). It also contextualizes the 'deep' parameter with 'jailbreak + resource-exhaustion' via the schema, which the description reinforces. This adds actionable nuance to the parameters.
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 a specific action ('Red-team an AI agent for security weaknesses'), enumerates the exact vulnerabilities it targets (prompt injection, system-prompt leakage, sensitive-data disclosure, unsafe output handling, excessive agency), and explicitly distinguishes itself from siblings by noting it is 'agent-to-agent scanning' versus other scan tools. This fully differentiates it from scan_website and compliance_report.
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 when-to-use context: 'use it to assess another agent from here.' It also specifies supported target kinds, prerequisites (ScanLabsAI API key, credits), and an explicit authorization boundary ('only scan agents you own or are authorised to test'). It does not explicitly name alternative tools for non-agent targets, but the agent-to-agent framing makes the usage context unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scan_websiteAInspectRun a ScanLabsAI security scan against a website and return a full Markdown vulnerability report (grouped by severity, with descriptions and remediation) that you can analyse, act on, and the user can save as security-report.md. Checks OWASP Top 10, CVEs, SSL/TLS, security headers and DNS. Use deep=true for a comprehensive scan (40,000+ vectors, slower). Only scan sites the user is authorised to test.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The website URL to scan, e.g. https://example.com | |
| deep | No | Run a deep scan (comprehensive, slower). Defaults to false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the output format, grouping by severity, the deep scan behavior with performance implications, and the authorization requirement. It does not mention potential side effects like network traffic, but for a read-only scan this is adequate.
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 and front-loaded, stating the core purpose and output in the first sentence. Every sentence earns its place, covering output, scope, deep option, and authorization 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 no output schema, the description fully explains the return format (Markdown report with severity grouping, descriptions, remediation). It also covers scope, deep mode, and authorization, making it complete for a two-parameter 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?
The schema covers 100% of parameters, so baseline is 3. The description adds value by explaining deep=true performs a comprehensive scan with 40,000+ vectors and is slower, which enriches beyond the schema's simple 'comprehensive, slower' description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs a ScanLabsAI security scan against a website and returns a full Markdown vulnerability report. It specifies the verb, resource, and output, and distinguishes itself from siblings like lookup_cves and compliance_report by focusing on a comprehensive website scan.
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 provides clear context on when to use the tool (for full security scans covering OWASP, CVEs, SSL/TLS, headers, DNS) and includes the important authorization constraint. It does not explicitly contrast with alternatives, but the use cases are well implied.
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.
No comments yet. Be the first to start the discussion!
