Scan/purge hidden text & score web domains: TLS, DNS, headers, speed. Free scans, $0.01 actions.
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.6/5 across 6 of 6 tools scored.
Each tool has a distinct purpose: domain_check_v1 vs domain_check_batch_v1 differ by number of domains, domain_check_score_v1 vs domain_check_v1 differ by detail level, and the batch variants mirror this. text_scan_v1 and text_purge_v1 are clearly complementary (detect vs fix). No two tools overlap in function.
All tool names follow the pattern <noun>_<verb>_v1, with optional _score and _batch modifiers. The naming is perfectly consistent and predictable, making it easy to infer the tool's behavior from its name.
Six tools is within the ideal range, but the server mixes two unrelated domains (domain resilience and text sanitization). While each sub-domain is well-covered, the combined focus makes the server feel slightly less coherent than a single-purpose toolkit.
The domain tools cover single/batch and score/detailed variants, providing a complete workflow for resilience assessment. The text tools cover scanning and fixing, which is a complete workflow for that sub-domain. No obvious gaps exist in either area.
domain_check_batch_v1Domain Resilience Check, BatchARuns the full resilience check on up to 100 domains in a single call and returns the same scored report for each one: TLS certificate, security headers, DNS redundancy, response time, with every individual finding. Use it to audit a portfolio, to rank a list of vendors, or to re-check a fleet after a config rollout. A domain that cannot be reached is returned with its own error rather than failing the batch, and it is still charged, because the crawl was attempted. Do not use it for a single domain: domain_check_v1 is simpler and costs the same for one. Private, internal and localhost hostnames and IP addresses are rejected. Price: $0.01 per domain, dropping to $0.005 from 100 domains, up to 100 per call. One payment covers the whole batch (x402, USDC on Base). No signup, no API key.
| Name | Required | Description | Default |
|---|---|---|---|
| domains | Yes | Bare domain names, apex or subdomain, for example ['example.com', 'www.example.org']. Between 1 and 100 entries. Scheme, path, port and query string are ignored if present. Duplicates are removed before billing. |
| Name | Required | Description |
|---|---|---|
| results | No | One entry per distinct domain, in no guaranteed order. |
| evaluated | No | Number of distinct domains actually evaluated. This is the billed quantity. |
| requested | No | Number of domains in the request, before de-duplication. |
| succeeded | No | How many produced a full report. The rest carry an error field. |
| evaluatedAt | No | UTC timestamp of the batch. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the safe read-only annotations, the description discloses important behaviors: unreachable domains return their own error but are still charged, private/internal/localhost hostnames are rejected, and pricing/payment details. No contradiction 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 efficient and well-structured: first the core action, then example use cases, then edge cases, then pricing/payment. Every sentence conveys necessary information without 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?
With an output schema present, the description doesn't need to spell out return values. It covers error handling, restrictions, pricing, and usage guidance, making it complete for a batch tool of this 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 documents the domains parameter thoroughly (bare domain names, 1-100 entries, scheme/path ignored, duplicates removed). The description adds billing cost per domain and clarifies batch behavior, adding value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs a full resilience check on up to 100 domains, listing the specific checks (TLS certificate, security headers, DNS redundancy, response time) and explicitly distinguishes itself from the single-domain sibling domain_check_v1.
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 gives use cases (audit a portfolio, rank vendors, re-check after config rollout) and an explicit exclusion: 'Do not use it for a single domain: domain_check_v1 is simpler and costs the same for one.' This provides clear when-to-use and alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
domain_check_score_batch_v1Domain Resilience Score, BatchAFree. Returns the overall resilience score out of 100 for up to 100 public web domains, plus the score of each category and how many findings each one raised. Use it to triage a portfolio: rank a list of domains, confirm which ones are healthy, or decide which ones are worth pulling the full report on. It tells you which categories are weak and how many issues they hold, but not what the issues are. A domain that cannot be reached is returned with its own error rather than failing the batch. Duplicates are removed. For the individual findings and the prioritised remediation list on a whole list, use domain_check_batch_v1. For a single domain, use domain_check_score_v1. Free, no payment required.
| Name | Required | Description | Default |
|---|---|---|---|
| domains | Yes | Bare domain names, apex or subdomain, for example ['example.com', 'www.example.org']. Between 1 and 100 entries. Scheme, path, port and query string are ignored if present. |
| Name | Required | Description |
|---|---|---|
| results | No | One entry per distinct domain, in no guaranteed order. |
| evaluated | No | Number of distinct domains actually evaluated. This is the billed quantity. |
| requested | No | Number of domains in the request, before de-duplication. |
| succeeded | No | How many produced a full report. The rest carry an error field. |
| evaluatedAt | No | UTC timestamp of the batch. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnlyHint, openWorldHint, idempotentHint, destructiveHint), but the description adds rich behavioral context: it says what is NOT returned ('not what the issues are'), how unreachable domains are handled ('returned with its own error rather than failing the batch'), that duplicates are removed, and that it is free. This goes well beyond the annotations, giving the agent confidence about side effects and edge cases.
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 well-structured and front-loaded, with the main functionality stated first, followed by use case, exclusions, error handling, and alternatives. It is slightly redundant with 'Free' appearing at both the beginning and end ('Free.' and 'Free, no payment required.'), which prevents a perfect score. Otherwise, every sentence adds useful 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?
Given the tool's simple one-parameter schema and the presence of an output schema, the description covers all essential context: what the output includes, error behavior, deduplication, and alternative tools. It fully enables an agent to decide when and how to invoke this tool without 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?
The schema already provides 100% coverage for the 'domains' parameter, including format, limits, and ignored components. The description reinforces the batch nature but does not add new parameter-level meaning beyond the schema. Since schema coverage is high, the baseline 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 tool's function: 'Returns the overall resilience score out of 100 for up to 100 public web domains, plus the score of each category and how many findings each one raised.' It uses a specific verb ('Returns') and identifies the resource (batch domain scores). It also distinguishes itself from siblings by naming alternative tools for other use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use this tool: 'Use it to triage a portfolio: rank a list of domains, confirm which ones are healthy, or decide which ones are worth pulling the full report on.' It also provides clear alternatives: 'For the individual findings and the prioritised remediation list on a whole list, use domain_check_batch_v1. For a single domain, use domain_check_score_v1.' This is exemplary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
domain_check_score_v1Domain Resilience ScoreAFree. Returns the overall resilience score out of 100 for a public web domain, plus the score of each category and how many findings each one raised. Use it to triage: to rank a list of domains, to confirm a domain is healthy, or to decide whether the detailed report is worth pulling. It tells you which categories are weak and how many issues they hold, but not what the issues are. For the individual findings and the prioritised remediation list, use domain_check_v1. Free, no payment required.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Bare domain name, apex or subdomain, for example 'example.com' or 'www.example.com'. Scheme, path, port and query string are ignored if present. IP addresses and private or localhost hostnames are rejected. |
| Name | Required | Description |
|---|---|---|
| error | No | |
| score | No | Weighted resilience score out of 100. |
| domain | No | Domain that was actually evaluated, after normalisation. |
| success | No | |
| categories | No | Per-category score and finding count. Finding details are not included. |
| evaluatedAt | No | UTC timestamp of the evaluation. |
| measuredCategories | No | Number of categories that could actually be measured. Compare two domains only when this matches. |
| detailsAvailableVia | No | Name of the tool returning the full findings behind these scores. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the bar is lower. The description adds useful behavioral context: it returns scores and findings counts but not the actual issues, and states it's free. This goes beyond annotations by clarifying limitations and output scope.
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 well-structured and front-loaded: it starts with 'Free' and the core result, then usage, then limitations, then alternative tool. However, 'Free' appears twice ('Free.' and 'Free, no payment required'), a slight redundancy. Still appropriately sized and organized.
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, output schema exists), and the description fully covers what it returns, when to use it, what it doesn't do, and which alternate tool to use. It is self-sufficient for an agent to select and invoke correctly, with no major gaps given the strong schema and annotations.
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 domain parameter already fully described (accepted formats, rejected IPs). The description adds no new parameter semantics, only uses the word 'domain' without further detail. Baseline 3 applies since schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Returns the overall resilience score out of 100 for a public web domain, plus the score of each category and how many findings each one raised.' It distinguishes itself from sibling domain_check_v1 by noting it doesn't provide individual findings, and the single-domain scope is implicit in contrast to batch siblings.
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 provides when to use: 'Use it to triage: to rank a list of domains, to confirm a domain is healthy, or to decide whether the detailed report is worth pulling.' It also directs to domain_check_v1 for detailed findings, giving clear alternative usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
domain_check_v1Domain Resilience CheckAMeasures how resilient a public web domain is from the outside and returns a weighted score out of 100, a per-category breakdown, and prioritised findings explaining what to fix first. Use it to audit a domain you do not control, to verify a fix after deployment, or to compare several domains on the same scale. Covers TLS certificate validity and protocol version, HTTP to HTTPS redirection, HSTS, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, cache directives, response time, DNS redundancy, IPv6 availability, CDN detection and software version disclosure. Everything is read from the public internet: nothing is authenticated, no ports are scanned, and no credentials are needed. Do not use it for private, internal, or localhost hostnames, for IP addresses, or to test a service you need logged-in access to. For a free score without the detailed findings, use domain_check_score_v1 instead. Price: $0.01 per call (x402, USDC on Base). No signup, no API key.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Bare domain name, apex or subdomain, for example 'example.com' or 'www.example.com'. Scheme, path, port and query string are ignored if present. IP addresses and private or localhost hostnames are rejected. |
| Name | Required | Description |
|---|---|---|
| error | No | |
| score | No | |
| checks | No | |
| domain | No | |
| noIndex | No | |
| success | No | |
| noArchive | No | |
| evaluatedAt | No | |
| requestedDomain | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds valuable context such as 'Everything is read from the public internet: nothing is authenticated, no ports are scanned, and no credentials are needed,' which clarifies the tool's non-intrusive behavior and pricing model. No contradiction 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 longer than average but every sentence provides distinct value: purpose, use cases, coverage details, access method, exclusions, alternative, and pricing. It is front-loaded with the core purpose and avoids filler, though slightly dense.
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 and the tool has modest complexity (one parameter), the description covers all necessary context: what it measures, when to use it, safety profile, exclusions, and how it differs from the sibling. Nothing is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes the single 'domain' parameter with examples and constraints, achieving 100% coverage. The description reinforces the public-only scope but does not add new parameter-level details, so 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 opens with a specific verb and resource: 'Measures how resilient a public web domain is from the outside' and clearly lists outputs (weighted score out of 100, per-category breakdown, prioritised findings). It also distinguishes itself from the sibling tool by noting 'domain_check_score_v1' provides a free score without detailed findings.
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?
Explicit use cases are given: 'audit a domain you do not control, verify a fix after deployment, or compare several domains.' It also states exclusions ('Do not use it for private, internal, or localhost hostnames, for IP addresses...') and points to an alternative tool for a simpler score. This is comprehensive guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
text_purge_v1Watermarked text, PurgeARemoves invisible Unicode characters and replaces homoglyphs in a text string. Returns the cleaned text plus a before-and-after comparison. Use this tool after text_scan_v1 to fix flagged issues. Price: $0.01 per call (x402, USDC on Base). No signup, no API key.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The text to clean of hidden characters and homoglyphs. |
| Name | Required | Description |
|---|---|---|
| purgedText | No | |
| reportAfter | No | |
| charsRemoved | No | |
| reportBefore | No | |
| homoglyphsReplaced | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover idempotency, destructiveness, and read-only hints. The description adds the return behavior (cleaned text plus comparison) and the pricing/access model, which are useful contextual details beyond the annotations. It does not contradict any annotation.
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 extremely concise with three sentences that front-load the core purpose, then cover output and usage guidance. Every sentence serves a distinct informative function with no redundancy 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?
The description covers the essential context: what the tool does, the return value (comparison), when to use it (after text_scan_v1), and cost/access details. With an output schema present and a single well-described parameter, nothing important is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides a full description for the only parameter 'text' (the text to clean), and the tool description repeats the same idea. Since schema coverage is 100%, the description adds no additional semantic value beyond what the schema already provides.
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 removes invisible Unicode characters and replaces homoglyphs, which is a specific verb+resource action. It also mentions the before-and-after comparison output, distinguishing it from the sibling text_scan_v1 which scans rather than purges.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using this tool after text_scan_v1 to fix flagged issues, providing clear when-to-use guidance and a named alternative/sequence. This makes the usage context unambiguous and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
text_scan_v1Watermarked text, ScanAFree. Scans a text string for invisible Unicode characters, homoglyphs, and normalization issues. Returns a risk score and a detailed report. Use this tool before text_purge_v1 to inspect suspicious content. Free, no payment required.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The text to scan for hidden characters and homoglyphs. |
| Name | Required | Description |
|---|---|---|
| notes | No | |
| isClean | No | |
| riskScore | No | |
| flaggedChars | No | |
| isNormalized | No | |
| categoryCounts | No | |
| homoglyphMatches | No | |
| normalizationForm | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description need not restate safety. It adds behavioral context by noting that it returns a risk score and detailed report, which is useful beyond the safety hints. No contradictions exist.
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 only a few lines but contains redundant wording: 'Free' appears twice and 'Free, no payment required' is a duplicate. The core purpose and usage are front-loaded, but the extra repetition prevents a higher score.
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 parameter, output schema, and strong annotations, the description covers purpose, usage context, and return value. No essential information is missing for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'text' is fully described in the schema ('The text to scan for hidden characters and homoglyphs'). The description mentions similar scanning targets but adds no additional syntax, format, or constraint details, so it does not elevate beyond 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 scans text strings for invisible Unicode characters, homoglyphs, and normalization issues, which is specific and distinct from sibling tools like domain_check_v1 and text_purge_v1. The phrase 'Use this tool before text_purge_v1' further differentiates its role in a workflow.
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 provides a usage directive: 'Use this tool before text_purge_v1 to inspect suspicious content.' This tells the agent when to use the tool and names an alternative/successor tool, making selection straightforward. The repeat of 'Free' reinforces cost-related selection criteria.
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!