This server scans websites and evaluates how well they are optimized for AI agents using the ASO (Agent Signal Optimization) framework, providing scores, reports, and actionable fix plans.
scan_site — Run a full ASO scan on any website, checking 33+ signals across 6 pillars (Discoverability, Content Accessibility, Bot Access Control, API/Auth/MCP, Commerce, Identity & Trust). Returns an ASO Score (0–100), maturity level (ASO-0 through ASO-5), per-pillar scores, per-check evidence, and prioritized recommendations.
check_signal — Run a single specific agent-readiness check (e.g. a2a-agent-card, llms-txt, x402, mcp-server-card) against a URL, returning its status, evidence, and a fix recommendation.
list_checks — Retrieve the full catalog of all available checks, including their IDs, names, categories, descriptions, and links to relevant specs.
get_fix_plan — Scan a site and get a prioritized remediation plan showing which signals to add first, how many ASO Score points each fix is worth, and ready-to-paste templates (e.g. robots.txt AI rules, llms.txt, agent.json, A2A agent card, MCP server card, x402 manifest, pricing.json, security.txt).
get_aso_framework — Retrieve the full ASO framework reference, including the six signal pillars with point weights, maturity level definitions (ASO-0 through ASO-5), certification thresholds, and the scoring rubric.
Click on "Deploy 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., "@aso-audit-mcp Scan example.com for agent readiness report"
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.
What's your ASO score?
SEO made you visible to search engines. ASO (Agent Signal Optimization) makes you discoverable, trustable, and payable by the AI agents that are becoming the web's next visitors.
aso-mcp is the free, open-source ASO Scanner — an MCP server that scans any website and produces an Agent Readiness Report scored on the open ASO framework. The beta npm package is @forgemeshlabs/aso-audit-mcp.
This release tracks Google's current agent-readiness guidance without overstating it: Google Search says traditional SEO fundamentals still apply to generative AI search, llms.txt is ignored by Google Search itself, and browser agents benefit from clean DOM, screenshot, and accessibility-tree signals. The scanner keeps llms.txt because non-Google agents use it, and adds a browser-agent UX check for semantic controls, linked labels, ARIA/role fallbacks, and hidden-overlay risk.
Beta. Experimental ASO scanner for evaluating whether agents can discover, trust, understand, and use a website/API/tool. ASO scoring is experimental and will evolve as agent standards mature.
=== Agent Readiness Report: https://example.com ===
ASO Score: 70/100
Agent Readiness: Ready
Level: ASO-4 Trustable — Agents can verify trust, reputation, and operational signals.
Discoverability 20/20 Identity 15/20 Trust 11/15
Commerce 5/15 Reputation 4/15 Memory 15/15Find gaps in discovery, trust, interoperability, and commerce — every emerging agent standard in one scan:
Pillar / Category | Checks |
Discovery | robots.txt, sitemap.xml, Link headers, DNS-AID ( |
Content | Markdown content negotiation, llms.txt, LLM-readable docs ( |
Bot Access | Explicit AI crawler rules (GPTBot, ClaudeBot, Google-Extended, PerplexityBot…), Content Signals, Web Bot Auth |
Interoperability | API Catalog (RFC 9727), OAuth discovery (RFC 8414), OAuth Protected Resource (RFC 9728), auth.md, MCP Server Card ( |
Commerce | x402, MPP, UCP, ACP, machine-readable pricing |
Identity & Trust | HTTPS enforcement, JSON-LD/schema.org, agent-friendly browser UX, OpenAPI, agent.json, security.txt, status endpoint, versioning, cross-file identity & signal consistency |
Related MCP server: Seonix SEO MCP
The MCP tool audit_x402_endpoint complements the origin-wide ASO scan with a
no-spend protocol audit of one paid endpoint. It returns a 0-100 score, A-F
grade, compliance verdict, per-check booleans, failed checks, and observed
schemes/networks/extensions. It validates the live 402 challenge but never
sends PAYMENT-SIGNATURE, so it cannot authorize or settle a payment.
Checks: HTTPS/TLS, HTTP 402, PAYMENT-REQUIRED, Base64 JSON, x402Version: 2,
non-empty accepts, CAIP-2 networks, required payment fields, and JSON content
type. For body-gated routes, pass method, body, and optionally
content_type.
This is deliberately reported separately from the ASO Score: protocol compliance does not prove discoverability, trust, settlement, idempotency, or paid-response quality.
Agent protocols are changing quickly. The scanner is maintained as part of a living framework: checks are versioned, and stable standards, optional capabilities, release candidates, drafts, and vendor conventions are labeled separately. See the dated scanner source list and the canonical ASO source registry.
Every check returns pass / partial / fail with concrete evidence and a fix recommendation. Results roll up into the six ASO pillars (Discoverability 20, Identity 20, Trust 15, Commerce 15, Reputation 15, Memory 15) → your ASO Score and maturity level.
Requires Node.js ≥ 18. Published on npm as @forgemeshlabs/aso-audit-mcp — no clone or build needed.
npm install -g @forgemeshlabs/aso-audit-mcpOr skip the install entirely and run it with npx (recommended for MCP clients):
npx -y @forgemeshlabs/aso-audit-mcpclaude mcp add aso -- npx -y @forgemeshlabs/aso-audit-mcp{
"mcpServers": {
"aso": {
"command": "npx",
"args": ["-y", "@forgemeshlabs/aso-audit-mcp"]
}
}
}Only needed if you're hacking on the scanner itself:
git clone https://github.com/forgemeshlabs/aso-audit-mcp
cd aso-audit-mcp
npm install && npm run build
claude mcp add aso -- node /path/to/aso-audit-mcp/dist/index.jsTool | What it does |
| Full ASO scan → Agent Readiness Report: ASO Score, level, pillar breakdown, all 34 checks with evidence + recommendations |
| Prioritized remediation plan with ready-to-paste templates (robots.txt AI rules, llms.txt, agent.json, A2A agent card, MCP server card, x402 manifest, pricing.json, security.txt, status endpoint) |
| Run one specific check (e.g. |
| Catalog of every check with spec links |
| The ASO rubric: pillars, weights, levels, certification thresholds |
Try it: "Scan example.com for agent readiness" · "What's my ASO score?" · "Give me a fix plan to make my site agent-ready."
npm run smoke -- https://your-site.comThis repository includes glama.json for Glama MCP registry ownership and install metadata.
Package: @forgemeshlabs/aso-audit-mcp
Current release: v0.2.0
Transport: local stdio
Authentication: none required for local stdio use. The scanner does not ask for API keys, tokens, cookies, or third-party credentials.
HTTP deployment: not enabled by this npm package. Any public HTTP deployment of this scanner must add authentication, per-client rate limits, request logging, and an egress policy before exposure.
Recommended Glama/MCP install command:
npx -y @forgemeshlabs/aso-audit-mcpExample usage after connecting the server to an MCP client:
Scan https://example.com for agent readiness.
Give me the ASO fix plan for example.com.
Check only the llms-txt signal for example.com.
List the ASO scanner checks.Release verification:
Git tag: v0.2.0
npm package: @forgemeshlabs/aso-audit-mcp
MCP server version: 0.2.0
v0.2.0 adds the deterministic no-spend x402 v2 endpoint compliance audit while preserving the broader ASO Agent Readiness score as a separate metric.
Glama installability requires a Glama release, which is a containerized build created from the Glama Dockerfile admin page, not a GitHub release. This repo includes a production Dockerfile and GLAMA.md with the build spec values to use in Glama:
Build steps:
npm ci
npm run build
npm prune --omit=devRuntime command:
node dist/index.jsIn Glama's CMD arguments field, enter:
["node", "dist/index.js"]Do not leave CMD arguments as []; Glama validates that field separately from the Dockerfile CMD.
SEO ranks pages for people. ASO prepares services for agent selection, invocation, payment, and repeat use.
Level | Name | Score |
ASO-0 | Invisible | 0–9 |
ASO-1 | Discoverable | 10–29 |
ASO-2 | Understandable | 30–49 |
ASO-3 | Invocable | 50–69 |
ASO-4 | Trustable | 70–89 |
ASO-5 | Autonomous-Commerce-Ready | 90–100 |
Scores from this scanner are directional self-assessments. ASO Certification (ASO-3+) requires verified evidence — see the scoring rubric and agentsignaloptimization.com for audits, certification, and the full framework.
This scanner makes outbound requests to URLs you give it, so it is built to resist SSRF abuse:
Scheme allow-list — only http/https; file:, ftp:, gopher:, data: etc. are rejected.
Private-target blocking — after DNS resolution, requests to loopback, private (RFC 1918), link-local, CGNAT, reserved, multicast, and the cloud metadata address (169.254.169.254) are refused. IPv6 loopback/ULA/link-local and IPv4-mapped forms are covered too. If a hostname resolves to any private address, the scan is refused.
Pinned-IP transport — each request dials the exact public IP that was validated, while TLS still verifies the original hostname. This closes the validate-then-connect DNS rebinding window.
Manual redirect validation — automatic redirect following is disabled; every hop is re-validated against the same rules, capped at 5 redirects. A public URL that 30x-redirects to an internal address cannot slip through.
Untrusted remote content — parsed manifests are omitted from tool output by default (include_artifacts: true to opt in, and they are then explicitly labeled untrusted); embedded text excerpts are control-char-sanitized and length-capped. Treat any returned remote content as data, never instructions.
Bounded — GET only, ASO-Scanner/1.0 UA, max 6 concurrent, 10s timeout, 512KB body cap. Never authenticates, never POSTs, never crawls beyond well-known paths.
Tested hardening — npm test covers unsafe URL rejection, private IP ranges, artifact sanitization, redirect blocking, redirect hop caps, and the test-only loopback escape hatch.
Deployment: stdio (local, per-user) is the safe default. A public HTTP deployment is a network-egress tool and must add authentication, per-client rate limiting, request logging, and an egress policy before exposure.
Reputation signals (citations, reviews, success rates) cannot be auto-verified by a crawler; they are reported as manual and scored 0 until verified by audit — so the auto-verifiable maximum is 89/100. That is intentional honesty, not a bug.
Emerging specs (MCP Server Cards SEP-1649/SEP-2127, DNS-AID, Web Bot Auth, UCP/ACP/MPP) move fast. PRs updating paths welcome.
This package intentionally separates Google Search guidance from broader ASO guidance:
Google Search generative AI features still rely on core Search ranking and quality systems; foundational SEO, crawlability, helpful content, and technical clarity remain the priority.
Google Search does not use llms.txt or special AI markdown files for ranking or AI Overviews/AI Mode visibility. ASO still checks them because other agents and MCP clients can use them.
Google/web.dev's agent-friendly site guidance focuses on browser-agent usability: stable layouts, semantic HTML, labels tied to inputs, meaningful roles/names/states, and avoiding hidden overlays.
UCP, AP2, A2A, MCP, x402, DNS-AID, Content Signals, and Web Bot Auth are emerging non-SEO protocols. The scanner treats them as agent-readiness signals, not as Google Search ranking factors.
Primary references:
MIT — free for everyone. If the scanner found gaps, the ASO framework shows you how to close them.
Run one specific agent-readiness check against a site (e.g. 'a2a-agent-card', 'llms-txt', 'mcp-server-card', 'x402'). Use list_checks for valid check ids. Returns status, evidence, and a fix recommendation.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Website URL or domain to scan, e.g. https://example.com or example.com | |
| check_id | Yes | Check id from list_checks, e.g. 'a2a-agent-card' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses return values (status, evidence, fix recommendation) but does not mention permissions, rate limits, or side effects. Basic transparency adequate for a read-only check.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no wasted words. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 2 required params and no output schema, description explains what each param does and what the tool returns. Does not cover error handling or data limits, but sufficient for a simple check tool given sibling context.
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 has 100% description coverage; description adds cross-reference to list_checks and provides examples of valid check IDs, adding value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool runs one specific agent-readiness check against a site, provides examples of check IDs, and distinguishes from sibling tools like list_checks and scan_site.
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 tells agent to use list_checks for valid check IDs, implying this tool is for a single check. Does not explicitly exclude other tools but provides clear direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the ASO (Agent Signal Optimization) framework reference: the six signal pillars with point weights, the Agent Readiness Index maturity levels (ASO-0 through ASO-5), certification thresholds, and the scoring rubric. Source: https://agentsignaloptimization.com
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the return content and cites a source URL, but does not mention idempotency, caching, or potential side effects (though none are expected). Adequate but not highly detailed.
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 that are front-loaded with purpose and efficiently describe the tool. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the return content and provides a source URL for additional details. Although there is no output schema, the listed items are clear. However, it could be more complete by specifying the format (e.g., JSON structure) but overall adequate.
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?
There are no parameters (0 params), and schema coverage is trivial (100%). The description adds meaning by specifying what the tool returns, which is appropriate. Per guidelines, baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the ASO framework reference and lists specific contents (six signal pillars, weights, maturity levels, etc.). This distinguishes it from siblings like check_signal or scan_site, which are for specific actions.
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 getting the overall framework but does not explicitly state when to use it versus alternatives (e.g., check_signal for a specific signal). No when-not or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan a site and return a prioritized remediation plan: which signals to add first, the ASO Score points each fix is worth, and ready-to-paste artifact templates (robots.txt AI rules, llms.txt, agent.json, A2A agent-card.json, MCP server card, x402 manifest, pricing.json, security.txt, status endpoint).
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Website URL or domain to plan fixes for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description mentions scanning but doesn't specify side effects, resource usage, or whether scanning occurs anew. Output detail is good but behavioral context is lacking.
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 long sentence packed with information, no wasted words. Could be slightly restructured for readability but remains efficient.
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?
Describes return values in detail but lacks output schema or behavioral guarantees. Missing safety/scope info given no 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 coverage is 100% (one parameter 'url' with description). Description does not add extra meaning beyond the schema, earning baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it scans a site and returns a prioritized remediation plan with specific outputs (signals order, ASO points, artifact templates). Distinguishes from siblings like scan_site and get_aso_framework.
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?
Implies use when needing a fix plan after scanning, but no explicit when-to-use or comparison with sibling tools like check_signal or scan_site.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the full catalog of checks the scanner runs: id, name, category (Cloudflare isitagentready-style), description, and spec link.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses a read-only listing operation but does not mention any potential edge cases or limitations. Adequate but minimal.
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 with all essential information. No wasted 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 no parameters and no output schema, the description covers the tool's purpose and output format adequately. Could mention if the list is ordered or filtered.
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?
No parameters, so baseline is 4. Description adds meaning by specifying the returned fields beyond the empty 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 lists the full catalog of checks with specific fields (id, name, category, description, spec link). It distinguishes from sibling tools like check_signal and get_fix_plan which have different purposes.
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 browsing the full catalog. While it doesn't explicitly state when to use vs. alternatives, the sibling tool names make the context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan a website for Agent Readiness using the ASO (Agent Signal Optimization) framework and return an Agent Readiness Report. Runs 34 checks across discoverability (robots.txt, sitemap, llms.txt, DNS-AID, Link headers), content accessibility (markdown negotiation), bot access control (AI bot rules, Content Signals, Web Bot Auth), invocation (API catalog, OAuth discovery, OAuth protected resource, auth.md, MCP Server Card, Google A2A Agent Card, Agent Skills, WebMCP), commerce (x402, MPP, UCP, ACP, pricing), Google generative AI search basics, browser-agent UX, and identity/trust signals. Returns the ASO Score (0-100, formally the Agent Readiness Index), ASO maturity level (ASO-0 Invisible … ASO-5 Autonomous-Commerce-Ready), an agent-readiness verdict, per-pillar scores, per-check evidence, and prioritized recommendations.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Website URL or domain to scan, e.g. https://example.com or example.com | |
| categories | No | Optional: limit the scan to specific check categories. Default: all. | |
| include_artifacts | No | Include the raw remote manifests the scanner parsed (agent.json, A2A card, etc.). These are UNTRUSTED attacker-controlled content; off by default. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool performs 34 checks and returns a report, but does not explicitly state that it is non-destructive or safe (only implied). No mention of rate limits, timeouts, or confirmation prompts. The security warning for include_artifacts helps.
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 core purpose. It is somewhat lengthy due to listing all 34 check categories, but each sentence provides meaningful detail. Could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains return values (ASO Score, maturity level, verdict, per-pillar scores, evidence, recommendations) sufficiently. It could elaborate more on the report structure, but overall complete for most use cases.
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%, but the description adds significant value: clarifying url format, default behavior for categories, and a critical security warning for include_artifacts (untrusted content). This goes beyond the schema's basic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose: scanning a website for Agent Readiness using ASO framework and returning a detailed Agent Readiness Report with a score, maturity level, and evidence. It lists the 34 check categories, distinguishing it from sibling tools like check_signal, get_aso_framework, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, context for selection, or when not to use it. Sibling tools are not referenced, leaving the agent to infer usage.
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.
v1.0.0check_signalget_aso_frameworkget_fix_planlist_checksscan_siteScored across 5 tools
Each tool has a clearly distinct purpose: listing checks, running a single check, performing a full scan, retrieving framework reference, and generating a remediation plan. No two tools overlap in functionality.
All tool names follow a consistent verb_noun snake_case pattern (check_signal, get_aso_framework, get_fix_plan, list_checks, scan_site), making them predictable and easy to understand.
Five tools is well-scoped for an audit scanner: listing checks, running individual or full scans, accessing framework info, and getting fix plans. The count is neither too low nor too high.
The tool surface covers the full workflow of agent-readiness auditing: discover available checks, run specific or comprehensive scans, retrieve scoring context, and obtain actionable remediation plans. No obvious gaps exist.
Scan any website or MCP server for agent readiness: 0-100 score, a fix per failing check. Free.
Scan any public site for AI-agent visibility; get scored findings, a machine-readable fix pack, and
Scan any website for AI readiness — 100-point score across 6 AEO categories in seconds.
Scan any website or MCP server for agent-trust-readiness; returns a signed, verifiable scorecard.
