The AcuityScan MCP Server lets AI clients run comprehensive website scans covering security, accessibility, performance, SEO, and more via ten specialized tools:
acuityscan_full_scan – Run 350+ checks across all 8 modules (email, DNS, SSL, performance, SEO, accessibility, privacy, mobile) in a single request.
acuityscan_latest_scan – Retrieve the most recent saved scan for a domain without re-running it.
acuityscan_email – Check SPF, DKIM, DMARC, MX, BIMI, MTA-STS, TLSRPT, reverse DNS, 77 blacklists, and Google/Yahoo bulk-sender compliance.
acuityscan_dns – Inspect all DNS record types (A, AAAA, MX, TXT, NS, SOA, CAA, DS), DNSSEC validation, TTL, nameserver redundancy, and propagation across 20 global resolvers.
acuityscan_ssl – Audit certificate chain, expiry, SANs, TLS protocols, cipher suites, security headers (HSTS, CSP, XFO), Google Safe Browsing status, and exposed sensitive files.
acuityscan_performance – Run Google PageSpeed/Lighthouse at desktop and mobile, measure Core Web Vitals (LCP, CLS, INP, FCP, TTFB), detect CDN usage, and identify 60+ tech-stack technologies.
acuityscan_seo – Evaluate title/meta tags, heading hierarchy, canonical URLs, Open Graph/Twitter cards, robots.txt, sitemap.xml, schema.org/JSON-LD, alt-text, and www/non-www consistency.
acuityscan_accessibility – Perform a full axe-core WCAG 2.1 AA audit at desktop and mobile viewports plus 38+ custom HTML checks, with severity-ranked violations and selectors.
acuityscan_privacy – Detect 28+ trackers, cookie consent banners, pre-consent tracking violations, CCPA "Do Not Sell" links, Google Consent Mode v2, and mixed-content issues.
acuityscan_mobile – Check viewport settings, tap target sizing, font sizes, PWA features, intrusive interstitials, responsive images, and horizontal overflow.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@AcuityScan MCP Server Check the SSL configuration of example.com"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Run AcuityScan website security, accessibility, performance, and SEO scans directly from your AI client via the Model Context Protocol.
Compatible with Claude Desktop, Cursor, Continue, and any other MCP client.
You: Is acme.com missing any email-auth records?
Claude: [calls acuityscan_email] → Your DMARC policy is "none" (monitor
only). SPF is configured. DKIM selectors not found at the 16
common locations — confirm with your mail provider…Ten tools, each wrapping one AcuityScan REST endpoint:
Tool | What it does |
| Full Site+ Scan — 350+ checks across all 8 modules (30s–5min) |
| Fetch your last saved scan without re-running |
| SPF, DKIM, DMARC, MX, BIMI, MTA-STS, 77 blacklists, Google/Yahoo bulk compliance |
| All records, DNSSEC, 20-resolver propagation |
| TLS protocol + cipher, cert chain, security headers, Google Safe Browsing |
| Desktop + mobile Lighthouse, Core Web Vitals, tech-stack detection |
| Title/meta/headings/canonical/OG/sitemap/schema.org |
| Full axe-core WCAG 2.1 AA at desktop + mobile viewports + 38 custom checks |
| 28+ trackers, consent banner, CCPA link, Consent Mode v2 |
| Viewport, tap targets, font size, PWA features, intrusive interstitials |
Related MCP server: Sekrd Security Scanner
AcuityScan API access requires the Agency plan.
Sign up or sign in at acuityscan.com
Upgrade to Agency on the pricing page
Open /settings → API keys and create a key
Copy the token — it's shown once
Edit ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"acuityscan": {
"command": "npx",
"args": ["-y", "@acuityscan/mcp"],
"env": {
"ACUITYSCAN_API_KEY": "asc_live_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
}
}
}
}Quit and reopen Claude Desktop. You'll see acuityscan in the tools menu.
Open Cursor settings → MCP → add a new server. Same command, args, and env as the Claude Desktop config above.
In .continue/config.json:
{
"experimental": {
"modelContextProtocolServers": [
{
"transport": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@acuityscan/mcp"]
},
"env": {
"ACUITYSCAN_API_KEY": "asc_live_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
}
}
]
}
}Once configured, just ask:
"Run a full AcuityScan on stripe.com"
"What email-auth records is acme.com missing?"
"Check the accessibility of vercel.com"
"Is example.com's SSL configured correctly?"
"Get my last scan for clientsite.com"
Your AI client will pick the right tool, send the request to AcuityScan with your API key, and explain the results in plain English.
The Agency plan ships with 250 API requests / 24 hours per account, shared across all your keys. Each MCP tool call counts as one request. Need more? Email support@acuityscan.com.
Your MCP client isn't passing the env var. Double-check the env block in your client config and restart the client.
You're signed in but on Free or Pro. Upgrade at acuityscan.com/pricing. API access auto-activates within seconds of upgrading — no key re-issue needed.
Some heavy WordPress sites push the performance / accessibility scanners to their ceiling. Retry, or run individual tools (acuityscan_dns, acuityscan_ssl, etc.) instead of acuityscan_full_scan.
git clone https://github.com/acuityscan/mcp
cd mcp
npm install
ACUITYSCAN_API_KEY=asc_live_xxx npm run devThen in your MCP client config, swap the npx command for an absolute path to your local clone:
"command": "node",
"args": ["/path/to/mcp/dist/index.js"]MIT — see LICENSE.
WCAG 2.1 AA accessibility audit — full axe-core run at desktop (1280×800) and mobile (375×812) viewports, merged + deduped, plus 38+ custom HTML checks. Returns severity-ranked violations with selectors. Use for accessibility audits, ADA compliance questions, or WCAG conformance.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to scan, e.g. 'example.com'. Don't include protocol or path. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses full scope: axe-core runs at desktop (1280×800) and mobile (375×812), merged and deduped, plus 38+ custom HTML checks. Returns severity-ranked violations with selectors. No annotations exist, so description carries full burden, and it does well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences only, front-loaded with technical details then use cases. 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?
Given no output schema and one parameter, the description fully explains tool behavior, scope, and output format. No gaps for intended purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers parameter domain with format instructions (no protocol/path). Description does not add meaning beyond schema, which has 100% coverage. 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 clearly states it is a WCAG 2.1 AA accessibility audit using axe-core at two viewports plus custom checks, providing severity-ranked violations with selectors. This specific verb+resource distinguishes it from siblings like performance or SEO scans.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states use cases: 'accessibility audits, ADA compliance questions, or WCAG conformance.' No exclusions or alternatives mentioned, but the context is clear given sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
DNS health — A/AAAA/MX/TXT/NS/SOA/CAA/DS records, DNSSEC validation, TTL analysis, nameserver redundancy, propagation across 20 global resolvers. Use for DNS troubleshooting, propagation checks, or DNSSEC questions.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to scan, e.g. 'example.com'. Don't include protocol or path. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It lists what the tool checks (records, DNSSEC, TTL) but does not explicitly state it is read-only or non-destructive. However, the nature of DNS scanning implies no modifications, so it is fairly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first lists capabilities, second gives use cases. No filler words. Front-loaded with core 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?
Description covers what the tool scans but does not mention output format or any error states. Since no output schema exists, the description could benefit from specifying what the agent receives (e.g., JSON report). Missing details on propagation specifics or result structure.
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 the single 'domain' parameter, which already describes it well. Description adds example format ('e.g. example.com') but does not significantly enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description starts with 'DNS health' and lists specific record types (A/AAAA/MX/etc.) and features like DNSSEC validation, TTL analysis, nameserver redundancy, and propagation. It clearly distinguishes from sibling tools (e.g., acuityscan_email, acuityscan_ssl) which cover different aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states usage contexts: 'Use for DNS troubleshooting, propagation checks, or DNSSEC questions.' Does not explicitly mention when not to use, but sibling tools provide alternatives for other domains.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Email deliverability deep check — SPF, DKIM (16 selectors), DMARC, MX, BIMI, MTA-STS, TLSRPT, reverse DNS, 77 RBL blacklists, and Google/Yahoo bulk-sender compliance. Use when the user asks about email auth, deliverability, blacklists, or 'why aren't my emails getting through'.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to scan, e.g. 'example.com'. Don't include protocol or path. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the burden of behavioral disclosure. It lists a comprehensive set of checks (SPF, DKIM with 16 selectors, DMARC, etc.), giving the agent a clear picture of what the tool does. It does not explicitly state that it is read-only and non-destructive, but the nature of the checks implies that.
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 sentence that front-loads the main function and lists many checks concisely, followed by a usage guideline. It is efficient but could be slightly more readable with splitting, hence a 4.
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 has only one parameter, no output schema, and no annotations, the description provides a very complete picture of what the tool checks and when to use it. It leaves no significant gaps for the agent to interpret.
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 100% coverage with a clear description for the single 'domain' parameter. The tool description adds usage context but does not further clarify the parameter beyond the schema. Thus, it meets the baseline of 3.
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 'Email deliverability deep check' and enumerates specific checks (SPF, DKIM, DMARC, etc.), making the tool's purpose unmistakable. It distinguishes from sibling tools like acuityscan_dns by focusing exclusively on email deliverability.
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 mentions when to use: 'when the user asks about email auth, deliverability, blacklists, or "why aren't my emails getting through".' This provides clear guidance on usage scenarios, though it does not mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a complete AcuityScan Site+ Scan — 350+ checks across email deliverability, DNS, SSL/threat, performance, SEO, accessibility, privacy, and mobile. Synchronous; takes 30s–5min depending on the domain. Use this when the user wants 'a full audit' or 'everything about this site'.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to scan, e.g. 'example.com'. Don't include protocol or path. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full weight. It discloses that the scan is synchronous and takes 30s–5min, plus the breadth of checks. It does not mention authorization needs or rate limits, but for a scanning tool, this is reasonable. Could improve by stating if it's read-only or costs credits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: first states the core function, second provides timing, third gives usage advice. No redundant words, front-loaded with purpose. Excellent conciseness.
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 what the tool does, how long it takes, and when to use it. However, it lacks information about what the output looks like (no output schema exists), which would help the agent set expectations. Overall, it is fairly complete for decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the domain parameter with example and formatting rule (no protocol/path), achieving 100% coverage. The description adds no additional parameter meaning, 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 clearly states the verb 'Run a complete AcuityScan Site+ Scan' and specifies the resource 'AcuityScan Site+ Scan' with a detailed list of 350+ checks across multiple categories, effectively distinguishing it from sibling tools like acuityscan_accessibility or acuityscan_dns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this when the user wants a full audit or everything about this site', providing clear context for when to invoke. The presence of sibling tools for specific checks implies when not to use it, but no explicit exclusion or alternative is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch your most recent saved scan for a domain without re-running it. Use this first if the user asks 'how did my last scan go?' or wants results from a prior audit. Returns 404 if no scan exists yet — fall through to acuityscan_full_scan in that case.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to scan, e.g. 'example.com'. Don't include protocol or path. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions returning 404 if no scan exists, which is important. However, it lacks details on response format or confirmation of read-only nature beyond 'without re-running it.' Still good but not top tier.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with main purpose, no wasted words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple lookup tool with 1 parameter, no output schema, and several siblings, the description covers purpose, usage, and fallback. It is complete enough for correct agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description for the 'domain' parameter. The description does not add additional parameter semantics beyond what the schema provides, 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 clearly states 'Fetch your most recent saved scan for a domain without re-running it,' which specifies the verb and resource. It distinguishes from siblings like acuityscan_full_scan by noting it returns a saved scan without re-running.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this first if the user asks "how did my last scan go?" or wants results from a prior audit.' Also provides fallback: 'Returns 404 if no scan exists yet — fall through to acuityscan_full_scan.' This is excellent guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mobile + UX audit — viewport meta, zoom-disabled detection, tap target sizing heuristics, form input type checks (email/tel keyboards), font-size iOS zoom bug, PWA features (touch icon, manifest, theme-color), intrusive interstitials, responsive images, table wrappers, horizontal overflow. Use for mobile UX reviews.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to scan, e.g. 'example.com'. Don't include protocol or path. |
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 lists a comprehensive range of checks, giving agents a good understanding of what the tool analyzes, but lacks behavioral details like read-only nature or output format.
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 front-loaded with the core purpose and is concise, but the dense list of checks could be better structured (e.g., bullet points) for readability.
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 single-parameter tool with no output schema, the description is adequate in listing scan areas but does not explain output format or behavior, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% coverage with a clear description of the 'domain' parameter. The tool description adds no additional parameter meaning 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 performs a 'Mobile + UX audit' and lists specific checks (viewport meta, tap target sizing, etc.), distinguishing it from siblings like accessibility or performance audits.
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 says 'Use for mobile UX reviews,' providing a clear when-to-use context. However, it does not explicitly state when not to use it or compare with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Performance audit — real Google PageSpeed Insights (Lighthouse) at desktop AND mobile viewports, Core Web Vitals (LCP, CLS, INP, FCP, TBT, TTFB), compression, CDN detection, 60+ tech-stack detections. Heavy — can take 2–4 minutes on slow sites. Use for speed/Lighthouse/Core Web Vitals questions.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to scan, e.g. 'example.com'. Don't include protocol or path. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the tool's heavy nature, expected runtime, and the scope of checks (60+ detections). While it doesn't mention side effects or authentication needs, it provides sufficient behavioral context for a read-only scan.
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 purpose and key details. Every sentence adds value: first sentence defines the tool, second sentence provides usage guidance and expectations. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description covers purpose, metrics, runtime, and usage context. It could mention whether results are returned as a report or raw data, but it's largely complete for an agent to decide when to invoke.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The lone parameter 'domain' has 100% schema coverage. The description adds valuable context beyond the schema by specifying not to include protocol or path, which helps avoid common mistakes.
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 performs a performance audit using real Google PageSpeed Insights, listing specific metrics (Core Web Vitals, compression, CDN detection, tech stack). It distinguishes itself from sibling tools like acuityscan_accessibility by focusing solely on performance.
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 recommends using this tool for speed, Lighthouse, or Core Web Vitals questions. It also warns about the heavy nature and 2–4 minute runtime, implying it's not for quick checks. It does not mention when not to use or alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Privacy + cookie audit — 28+ tracker detection, cookie consent banner detection, pre-consent tracking violations, privacy policy + CCPA 'Do Not Sell' link presence, Google Consent Mode v2 detection, mixed-content scans. Use for GDPR/CCPA prep or privacy reviews.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to scan, e.g. 'example.com'. Don't include protocol or path. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description conveys the tool's behavior well by listing what it detects (trackers, cookie consent, policies, etc.). However, it does not disclose whether the scan is destructive or if any permissions are required, which is a minor gap.
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 leads with the core purpose, lists key features concisely, and ends with a usage suggestion. No redundancy or unnecessary words.
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 low complexity (one parameter, no output schema or annotations), the description covers the tool's capabilities thoroughly. It could mention the nature of the output (e.g., a report), but the information provided is sufficient for an agent to select and invoke the 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 single parameter 'domain' is fully described in the input schema. The description does not add extra meaning beyond the schema, so the baseline score 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 clearly states it performs a privacy and cookie audit with a specific list of checks (tracker detection, consent banner, violations, etc.) and distinct use cases (GDPR/CCPA prep). This distinguishes it from sibling tools like accessibility or SEO scans.
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 suggests using it for GDPR/CCPA preparation or privacy reviews. It does not mention when not to use it or name alternative tools, but the context of sibling tools makes the intended usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Technical SEO audit — title + meta description, heading hierarchy, canonical URL, Open Graph + Twitter cards, robots.txt, sitemap.xml, schema.org / JSON-LD validation, viewport meta, alt-text coverage, internal link count, language attribute, www/non-www consistency. Use for SEO troubleshooting or pre-publish audits.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to scan, e.g. 'example.com'. Don't include protocol or path. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It lists audit checks but does not state whether the scan is read-only, any side effects, rate limits, or authentication needs. This omission leaves the agent uncertain about tool behavior.
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 informative but somewhat lengthy with a list of checks. It is front-loaded with 'Technical SEO audit,' but the list could be more concise. Still, it avoids unnecessary 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?
Given the simple input schema (1 param) and no output schema, the description covers what the audit includes. However, it does not describe the return format or what the agent should expect after the scan, which is important for a scanning 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 single parameter 'domain' is fully described in the schema with 100% coverage. The description adds value by specifying 'Don't include protocol or path,' which helps correct usage beyond the schema's definition.
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 begins with 'Technical SEO audit' and lists specific checks (title, meta description, heading hierarchy, etc.), clearly stating what the tool does. It distinguishes from sibling audit tools like accessibility or DNS scans.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use for SEO troubleshooting or pre-publish audits,' providing clear guidance. However, it does not mention when not to use or name alternative siblings, though the context of sibling tools implies differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
SSL/TLS + security audit — certificate chain + expiry + SANs, TLS protocol versions, cipher suite negotiation, Google Safe Browsing, security headers (HSTS, CSP, XFO, etc.), HSTS preload status, exposed sensitive files. Use for SSL questions, security headers, or 'is this site safe to visit'.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to scan, e.g. 'example.com'. Don't include protocol or path. |
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 a detailed list of what the tool checks (certificate, TLS, security headers, etc.), implying it is a read-only scan. It does not mention side effects, authentication needs, or rate limits, but given the nature of a scan tool, the disclosure 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 two sentences, front-loading the core checks in the first sentence and usage context in the second. Every word adds value, with no redundancy or 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?
The tool has no output schema, so the description should help the agent understand return values. While it lists what is checked, it does not explicitly state the output format (e.g., a report with results). However, the list of checks is comprehensive enough for an agent to infer typical outputs. The description could be slightly more complete by mentioning the return structure.
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 100% coverage with a description for the 'domain' parameter. The tool description does not add additional meaning beyond the schema's guidance (e.g., 'Don't include protocol or path'), so the minimum viable 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 it performs an SSL/TLS and security audit, listing specific checks like certificate chain, expiry, SANs, TLS protocols, cipher suites, Google Safe Browsing, security headers, HSTS preload, and exposed sensitive files. It distinguishes from sibling tools by specifying use cases for SSL questions, security headers, and site safety.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage contexts: 'Use for SSL questions, security headers, or is this site safe to visit.' This guides the agent on when to use this tool. However, it does not explicitly state when not to use it or compare to sibling tools beyond the listed checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0acuityscan_accessibilityacuityscan_dnsacuityscan_emailacuityscan_full_scanacuityscan_latest_scanacuityscan_mobileacuityscan_performanceacuityscan_privacyacuityscan_seoacuityscan_sslEach tool targets a distinct domain (accessibility, DNS, email, full scan, latest scan, mobile, performance, privacy, SEO, SSL) with no overlap in purpose or functionality. An agent can clearly differentiate them.
All tools follow a consistent 'acuityscan_<domain>' pattern using snake_case and descriptive nouns, making it easy to predict tool names from domain names.
Ten tools cover the major aspects of a site audit without being overwhelming or sparse. Each tool has a clear role, and the count is well-scoped for the service's purpose.
The tool set covers all major site audit areas (accessibility, DNS, email, performance, SEO, SSL, mobile, privacy) plus a full scan aggregator and a retrieval tool. No obvious gaps for typical audit needs.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Scan URLs for WCAG 2.1 violations, generate AI fixes, and produce VPAT 2.5 compliance reports.
Scan any public site for AI-agent visibility; get scored findings, a machine-readable fix pack, and
AI website audit: security, SEO, performance, UX and accessibility checks with actionable fixes.
Deterministic axe-core accessibility scans (WCAG 2.1 AA, EN 301 549, PDF/UA) via your account.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/AcuityScan/mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
