security tools for AI agents: URL safety scanning, prompt injection detection (200+ patterns), email/password breach checks via HIBP, domain & IP reputation analysis, and AI skill supply chain scanning. Free tier (3 calls/day) or pay-per-request with USDC micropayments via x402.
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.1/5 across 9 of 9 tools scored.
Each tool has a clearly distinct purpose targeting specific security checks: domain, email, IP, password, password range, prompt injection, URL, full scan, and skill scanning. There is no overlap in functionality, making it easy for an agent to select the correct tool based on the input type and desired check.
All tools follow a consistent verb_noun pattern with the prefix 'shieldapi.check_' or 'shieldapi.scan_' (e.g., check_domain, check_email, scan_skill). The naming is uniform and predictable, using snake_case throughout without any deviations or mixed conventions.
With 9 tools, the server is well-scoped for a security API, covering a broad range of checks (e.g., reputation, breach detection, threat analysis) without being overwhelming. Each tool serves a unique and necessary function, making the count appropriate for the domain.
The tool set provides comprehensive coverage for security checks, including domain, email, IP, password, URL, and specialized scans for prompts and AI skills. A minor gap is the lack of update or delete operations, but this is reasonable for a read-only security assessment API, and agents can work around this by using the appropriate check tools as needed.
shieldapi.check_domainACheck domain reputation: DNS records, blacklists (Spamhaus, SpamCop, SORBS), SPF/DMARC, SSL.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain name to check (e.g. example.com) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the annotations (readOnly, idempotent, non-destructive) by disclosing the actual checks performed: DNS records, specific blacklists, SPF/DMARC, and SSL. This gives the agent a concrete idea of what the tool inspects. It does not mention output format or response fields, but the provided facets are meaningful behavioral 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 a single, tightly packed sentence. It leads with the main action and resource, then enumerates key services using a colon list. Every element adds information; there is no redundant or filler wording.
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, single-parameter tool, the description sufficiently covers its scope. It lists what the tool checks, which implies output categories. It could mention return format or potential limitations (e.g., rate limits), but the overall context is adequate given the annotations and simple 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 coverage is 100% for the single 'domain' parameter, including an example format. The description adds no extra parameter-level details beyond restating 'domain' in the purpose. Since the schema already documents the parameter well, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Check' with a clear resource 'domain reputation' and immediately lists concrete facets: DNS records, blacklists (Spamhaus, SpamCop, SORBS), SPF/DMARC, SSL. This distinguishes it from sibling tools like check_email or check_ip, which target different resource 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?
The context is clear: this tool is for domain reputation checks. It does not explicitly state when not to use it or name alternatives, but the sibling tool names and the resource-specific wording imply the appropriate use case. No exclusion or prerequisite is needed for a single-parameter read-only check.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
shieldapi.check_emailACheck if an email address has been exposed in known data breaches via HIBP.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Email address to check |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds valuable context about the data source (HIBP) and the scope ('known data breaches'), which goes beyond the annotations without contradicting them.
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 states the action and resource efficiently with no redundant words or filler.
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 one-parameter read-only check tool with robust annotations, this description sufficiently covers purpose, data source, and implied boolean result. No output schema is needed, and the description is 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?
The input schema already provides 100% coverage for the single parameter with a clear description ('Email address to check'). The tool description adds no further parameter-level meaning, so the baseline of 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 uses the specific verb 'check' with the resource 'email address' and provides context ('exposed in known data breaches via HIBP'), clearly distinguishing this tool from sibling tools that check domains, IPs, or passwords.
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 use for email breach checking, and sibling tool names make alternatives obvious (e.g., check_domain for domains). However, it does not explicitly state when not to use this tool or mention alternatives by name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
shieldapi.check_ipACheck IP reputation: blacklists, Tor exit node detection, reverse DNS.
| Name | Required | Description | Default |
|---|---|---|---|
| ip | Yes | IPv4 address to check (e.g. 8.8.8.8) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, idempotent behavior. The description adds specific behavioral context by enumerating the checks performed (blacklists, Tor exit, reverse DNS), which is useful beyond the safety 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?
Single sentence, front-loaded with action and resource, zero wasted words. Every part 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 single-parameter IP check, the description conveys the purpose and key checks. Since there is no output schema, it partially explains what the tool will provide (blacklist status, Tor detection, reverse DNS), but could be more explicit about the response format or scoring.
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 fully describes the 'ip' parameter (IPv4 address, example provided), so the description does not need to add param details. Baseline of 3 is appropriate since the schema carries the meaning, and the description adds no extra parameter semantics.
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 IP reputation and lists specific checks (blacklists, Tor exit node detection, reverse DNS). The verb 'Check' plus resource 'IP' distinguishes it from sibling tools like check_domain and check_url.
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: use for checking IP reputation. It does not explicitly mention alternatives or exclusions, but the scope is unambiguous given the checked resource (IP) and sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
shieldapi.check_passwordACheck if a password hash (SHA-1) has been exposed in known data breaches via HIBP.
| Name | Required | Description | Default |
|---|---|---|---|
| hash | Yes | SHA-1 hash of the password (40 hex chars) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds the HIBP external service context, which is useful, but does not disclose details like return format or rate limits. No contradiction with annotations is present.
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, precise sentence with no unnecessary words. It front-loads the key action and resource, making it immediately understandable and earning its place 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?
The tool is simple with one parameter and good annotations, but it lacks an output schema and the description does not specify what the tool returns (e.g., boolean, breach count). This gap in return-value transparency means the agent may be uncertain about the result format, so completeness is adequate but not strong.
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 fully describes the single 'hash' parameter with format constraints (SHA-1, 40 hex chars), and the description reiterates this. Since schema coverage is 100%, the description adds no extra meaning beyond the schema, placing it at the baseline.
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 checks if a SHA-1 password hash has been exposed in known data breaches via HIBP, using a specific verb and resource. It does not explicitly distinguish itself from the sibling check_password_range, which likely uses a different method (e.g., range query), so it lacks full sibling differentiation.
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 for password breach checks but does not explicitly state when to choose this tool over alternatives like check_password_range or other check tools. There is no mention of exclusions or preferred contexts, leaving the guidance implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
shieldapi.check_password_rangeALook up a SHA-1 hash prefix in the HIBP k-Anonymity database.
| Name | Required | Description | Default |
|---|---|---|---|
| prefix | Yes | First 5 characters of the SHA-1 password hash |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds the specific backend (HIBP k-Anonymity) and prefix semantics, but does not disclose additional behavioral aspects like response format or privacy attributes beyond what the schema already provides.
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?
A single, focused sentence that immediately conveys the tool's purpose. No filler, fluff, or redundant phrasing. It is front-loaded with the key action and object.
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 one-parameter lookup tool with clear schema and annotations, the description is sufficiently complete. It identifies the resource and operation, but lacks detail about the response format or how to interpret results; still, given the simplicity, it is mostly complete.
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% ('First 5 characters of the SHA-1 password hash') and thoroughly explains the parameter. The description merely restates 'SHA-1 hash prefix' without adding extra meaning or usage details, so it stays at the baseline.
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 ('Look up') and a specific resource ('SHA-1 hash prefix in the HIBP k-Anonymity database'). The inclusion of 'prefix' distinguishes it from sibling tools like check_password, which likely handles full hashes.
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 the tool is used for prefix-based HIBP lookups but does not explicitly contrast it with alternative tools or state when NOT to use it. No alternatives are mentioned, so the context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
shieldapi.check_promptADetect prompt injection in text. Analyzes across 4 categories (direct injection, encoding tricks, exfiltration, indirect injection) with 200+ detection patterns. Designed for real-time inline usage before processing untrusted user input. Returns boolean verdict, confidence score (0-1), matched patterns with evidence, and decoded content if encoding obfuscation was detected. Response time <100ms p95.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | The text to analyze for prompt injection | |
| context | No | Context hint for sensitivity: user-input (default), skill-prompt (higher tolerance), system-prompt (highest sensitivity) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by detailing the return structure (boolean verdict, confidence, matched patterns, decoded content), the detection scope (4 categories, 200+ patterns), and performance (<100ms p95). This is rich behavioral context not provided by the readOnly/idempotent 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 efficiently written sentences front-load the purpose, then pack concrete details about categories, return values, and performance. No redundant or vague wording.
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?
Even without an output schema, the description fully covers return fields, performance expectations, and usage context, making the tool's behavior completely understandable for a real-time content moderation 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 description coverage is 100%, with both prompt and context well-described in the schema. The description adds no parameter-specific details beyond what the schema already provides, so the 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?
The description starts with a specific verb and resource: 'Detect prompt injection in text'. It further distinguishes itself from sibling check_* tools by naming the detection categories and target input type, making its scope 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?
It explicitly states the intended use case: 'Designed for real-time inline usage before processing untrusted user input'. This gives clear context for when to use it, though it doesn't explicitly contrast with alternatives like full_scan.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
shieldapi.check_urlACheck a URL for malware, phishing, and other threats. Uses URLhaus + heuristic analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL to check (e.g. https://example.com) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by disclosing the underlying analysis sources (URLhaus + heuristic analysis) and the specific threat categories (malware, phishing, other threats), which provides behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the core action ('Check a URL...') and a short secondary sentence on methodology. No unnecessary words 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 read-only tool with one parameter, the description covers purpose, method, and threat scope. There is no output schema, so the description could theoretically mention the return format, but the tool is simple enough that this omission is not a major gap.
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% with the 'url' parameter well-described ('The URL to check (e.g. https://example.com)'). The tool description adds minimal extra parameter meaning—it only repeats 'URL'—so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Check a URL' and the specific purpose 'for malware, phishing, and other threats'. This distinguishes it from sibling tools like check_domain, check_email, or check_ip by explicitly targeting URLs.
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 sets the context by specifying a URL as the input type, and mentions the analysis method (URLhaus + heuristics). It does not explicitly name alternatives or state when not to use it, but the scope is clear enough for an agent to select this tool for URL checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
shieldapi.full_scanARun all security checks on a target (URL, domain, IP, or email). Most comprehensive scan.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target to scan — URL, domain, IP address, or email |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, fully establishing the safety profile. The description adds minimal behavioral context beyond confirming it runs all checks, omitting details like output format or potential runtime, but it does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two clear sentences, with the core action front-loaded in the first sentence. The second sentence adds impactful emphasis ('Most comprehensive scan') without unnecessary detail.
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 has a simple one-parameter schema and full annotations, but there is no output schema. The description explains what the tool does but not what the scan returns, leaving the return-value context incomplete. It is minimally viable but could be improved by stating the output format.
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 already provides 100% coverage with a detailed description for the 'target' parameter. The description's mention of accepted target types merely repeats the schema content, adding no 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 'Run all security checks on a target (URL, domain, IP, or email)' specifies a clear action and resource, and 'Most comprehensive scan' explicitly differentiates it from the specialized sibling tools like check_url and check_domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is the comprehensive option for multi-type targets, but it does not explicitly state when to use it instead of the individual check_* tools or provide exclusions. The sibling context helps, but the description itself lacks explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
shieldapi.scan_skillAScan an AI agent skill/plugin for security issues across 8 risk categories (Snyk ToxicSkills taxonomy). Checks for prompt injection, malicious code, suspicious downloads, credential handling, secret detection, third-party content, unverifiable dependencies, and financial access patterns. Static analysis only — no code execution. Returns risk score (0-100), severity-ranked findings with file locations, and human-readable summary.
| Name | Required | Description | Default |
|---|---|---|---|
| files | No | Additional code files to analyze (max 20 files) | |
| skill | No | Raw SKILL.md content or skill name from ClawHub |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint, etc.), the description adds meaningful behavior: static analysis only, no code execution, and a specific return format with risk score and severity-ranked findings. This gives the agent a concrete understanding of what the tool does without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: the first sentence states purpose, the second lists the checks, the third defines behavioral constraints, and the fourth summarizes the output. Every sentence adds distinct value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though there is no output schema, the description names the return components (risk score 0-100, findings with file locations, summary). It also covers the tool's scope, methodology, and limitations, making it sufficiently complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already well-documented in the schema. The description does not add parameter-specific guidance, but it does clarify the overall purpose and output. Baseline 3 is appropriate since the schema carries the parameter documentation load.
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 opens with a specific verb ('Scan'), identifies the resource ('AI agent skill/plugin'), and enumerates the exact risk categories and taxonomy. This clearly distinguishes it from sibling tools that check single entities like domains, emails, or URLs.
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 intended use case: scanning AI agent skills/plugins. It also adds the important constraint that it is static analysis only, which signals when it is appropriate. It does not explicitly name alternative tools or state exclusions, but the context is clear enough.
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!
