Auditorías instantáneas de SEO, rendimiento y seguridad para agentes de IA — analiza cualquier URL con una sola llamada de herramienta a través del Protocolo de Contexto de Modelo (MCP).
SiteAudit es un servidor MCP que otorga a Claude Code, Cursor, Windsurf y a cualquier agente de IA la capacidad de auditar cualquier sitio web al instante. Sin claves API, sin configuración, sin coste. El kit de herramientas de auditoría de sitios web completo para el desarrollo impulsado por IA.
Pruébalo ahora — no requiere instalación: Abre SiteAudit en el Playground de MCPize — se ejecuta en tu navegador, plan gratuito (100 auditorías/mes)
Aquí tienes ejemplos concretos de lo que puedes pedirle a tu agente de IA una vez instalado SiteAudit:
"Audita example.com y dame una lista priorizada de correcciones de SEO" — Auditoría SEO completa con etiquetas de título, meta descripciones, encabezados, datos estructurados, Open Graph y recomendaciones accionables
"Comprueba las cabeceras de seguridad en mi sitio de producción" — HTTPS, HSTS, CSP, X-Frame-Options, flags de cookies, validez del certificado SSL y divulgación del servidor
"Compara mi sitio frente a 3 competidores lado a lado" — Comparación multisitio con puntuaciones de SEO, rendimiento y seguridad en todos los sitios
"Ejecuta una auditoría Lighthouse en mi página de inicio" — Puntuaciones de rendimiento, accesibilidad, mejores prácticas y SEO de Google PageSpeed Insights
"Encuentra todos los enlaces rotos en mi sitio" — Rastrea enlaces internos y externos, informa de errores 404, redirecciones y URLs inalcanzables
"Comprueba si mi robots.txt está bloqueando algo importante" — Analiza las reglas de robots.txt, encuentra referencias de sitemap e identifica posibles problemas de rastreo
Related MCP server: Seonix SEO MCP
Característica | SiteAudit MCP | Ahrefs | Screaming Frog | Google Lighthouse |
Funciona con Claude Code / Cursor | Sí | No | No | Solo CLI |
No requiere clave API | Sí | No ($99/mes) | Gratis (limitado) | Sí |
SEO + Seguridad + Rendimiento | Los tres | Solo SEO | Solo SEO | Solo rendimiento |
Nativo de IA (protocolo MCP) | Sí | API REST | App de escritorio | CLI / API |
Comprobador de enlaces rotos | Sí | Sí | Sí | No |
Integración con Lighthouse | Sí | No | No | Es Lighthouse |
Comparación multisitio | Sí | Manual | Manual | Manual |
Gratis | Sí | $99+/mes | Gratis (500 URLs) | Sí |
Herramienta | Descripción |
| Auditoría integral de SEO + rendimiento + seguridad con puntuación unificada (0-100) |
| Análisis SEO: título, meta, encabezados, imágenes, enlaces, datos estructurados, Open Graph |
| Cabeceras de seguridad, HTTPS, HSTS, CSP, comprobación de certificado SSL, flags de cookies |
| Tiempo de respuesta, tamaño de página, compresión, caché, redirecciones |
| Comparación lado a lado de múltiples sitios web |
| Google PageSpeed Insights: rendimiento, accesibilidad, mejores prácticas, SEO |
| Rastrea y valida todos los enlaces en una página — encuentra enlaces rotos, redirecciones, tiempos de espera |
| Analiza las reglas, directivas y sitemaps de robots.txt |
La forma más rápida de empezar. Sin terminal, sin archivos de configuración, sin configuración de Python — funciona en cualquier cliente MCP:
👉 Instalar SiteAudit en MCPize — Plan gratuito disponible (100 auditorías/mes)
O añádelo directamente a tu configuración de MCP:
{
"mcpServers": {
"siteaudit": {
"url": "https://siteaudit-mcp.mcpize.run/mcp"
}
}
}¿Por qué MCPize?
✅ Configuración cero — funciona inmediatamente en Claude Desktop, Cursor, Windsurf, Claude Code
✅ Siempre actualizado — nuevas comprobaciones de SEO y funciones añadidas continuamente
✅ Escala contigo — actualiza a Pro ($19/mes) para 10,000 auditorías + Lighthouse completo + prioridad
✅ Sin límites de tasa en la API de PageSpeed — nosotros gestionamos la cuota de Google por ti
✅ Tiempo de actividad fiable — infraestructura en la nube gestionada
Consulta los precios a continuación para todos los niveles, incluidos Agencia y Empresa.
Para aquellos que prefieren ejecutar el servidor localmente:
claude mcp add siteaudit -- uvx --from siteaudit-mcp siteaudit{
"mcpServers": {
"siteaudit": {
"command": "uvx",
"args": ["--from", "siteaudit-mcp", "siteaudit"]
}
}
}pip install siteaudit-mcp
siteauditgit clone https://github.com/vdalhambra/siteaudit-mcp.git
cd siteaudit-mcp
uv sync
uv run siteauditnpx -y @smithery/cli install @vdalhambra/siteaudit --client claudeNota: Autoalojado = acceso completo a funciones, pero tú gestionas las actualizaciones, el tiempo de actividad y las cuotas de Google PageSpeed. Para la mayoría de los usuarios, MCPize es la mejor opción.
Nivel | Precio | Auditorías/mes | Incluye |
Gratis | $0 | 100 | Auditoría básica (sin Lighthouse) |
Hobby | $7/mes | 2,500 | Auditoría completa sin comparación de sitios |
Pro ⭐ | $19/mes | 10,000 | Las 8 herramientas + Lighthouse completo + prioridad |
Agencia | $49/mes | 50,000 | Pro + 10 sitios guardados + auditorías programadas |
Agencia Plus | $119/mes | 200,000 | Agencia + informes PDF de marca blanca + 25 asientos |
Empresa | $349/mes | Ilimitado | Agencia Plus + on-prem + integraciones personalizadas + SLA |
Planes anuales: Obtén 2 meses gratis (paga por 10, usa 12).
Paquete: Combínalo con FinanceKit MCP por $39/mes (Pro Combo — ahorra un 19%).
👉 Ver todos los precios en MCPize
Etiqueta de título (presencia, optimización de longitud)
Meta descripción (presencia, longitud)
Etiqueta H1 (recuento, contenido)
Jerarquía de encabezados (H1-H6)
Cobertura de texto alternativo de imágenes
Recuento de enlaces internos/externos
URL canónica
Etiquetas Open Graph
Etiquetas Twitter Card
Ventana gráfica móvil
Datos estructurados (JSON-LD)
Favicon
Atributo de idioma
Directivas meta robots
Longitud del contenido (recuento de palabras)
Aplicación de HTTPS
Cabecera HSTS (con subdominios y precarga)
Content-Security-Policy
X-Content-Type-Options
X-Frame-Options
Referrer-Policy
Permissions-Policy
Divulgación de Server/X-Powered-By
Flags de seguridad de cookies (Secure, HttpOnly, SameSite)
Validez y caducidad del certificado SSL
Tiempo de respuesta del servidor (ms)
Tamaño de página (KB)
Compresión (gzip/brotli)
Cabeceras Cache-Control
Análisis de cadena de redirección
Código de estado HTTP
Puntuación de rendimiento
Puntuación de accesibilidad
Puntuación de mejores prácticas
Puntuación SEO
Core Web Vitals (FCP, LCP, TBT, CLS)
URL: https://github.com
Overall Score: 90/100 (Grade: A)
Scores:
SEO: 85/100
Performance: 95/100
Security: 90/100
Issues: 0
Warnings: 3
[SEO] No JSON-LD structured data
[Security] Missing Content-Security-Policy header
[Security] Server header discloses: 'GitHub.com'SiteAudit funciona completamente analizando el HTML y las cabeceras HTTP de la URL de destino. No se necesitan claves API de terceros. Utiliza:
requests para la obtención de HTTP
BeautifulSoup para el análisis de HTML
ssl de Python para la comprobación de certificados
API de Google PageSpeed Insights (gratuita, no se requiere clave para uso básico)
SiteAudit funciona con cualquier agente de IA o IDE que admita el Protocolo de Contexto de Modelo:
Claude Code (CLI) — claude mcp add
Claude Desktop — claude_desktop_config.json
Cursor — .cursor/mcp.json
Windsurf — Configuración de MCP
Copilot — Configuración de MCP
Cualquier cliente MCP — transporte stdio o HTTP
Si SiteAudit te resulta útil, considera apoyar el desarrollo continuo:
💎 Actualiza a Pro en MCPize — La mejor forma de apoyar + obtener acceso prioritario
⭐ Pon una estrella a este repositorio — Ayuda a otros desarrolladores a encontrarlo
💖 Patrocina en GitHub — Apoyo único o recurrente
🐦 Comparte en Twitter/X — Etiqueta a @ElAgenteRayo
MIT
Run WCAG accessibility checks on a URL.
Returns a score (0-100) and detailed findings on:
Missing alt text on images
Form inputs without labels
Heading hierarchy issues
Color contrast hints (limited without rendering)
ARIA attribute usage
Language declaration
Skip links
Focus indicators (heuristic)
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to audit (e.g., 'example.com') |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds context beyond annotations by listing specific checks and noting limitations (e.g., 'limited without rendering', 'heuristic'). Annotations already declare readOnlyHint=true, consistent with audit. No contradictions.
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 with a bullet list, front-loaded with main action, no wasted words. Efficient and scannable.
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 output schema exists, description covers return types adequately. Could mention single-page scope, but overall complete for a simple tool with good 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?
Single parameter with 100% schema coverage; description does not add meaning beyond schema's 'URL to audit'. 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?
Description specifies verb 'Run WCAG accessibility checks' and resource 'URL', clearly distinguishing from sibling tools like lighthouse_audit or seo_audit.
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?
Description implies usage for accessibility checks but does not explicitly state when to use or not use this tool versus alternatives, nor mention any prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan a page for broken links — find 404s, redirects, timeouts, and server errors.
Extracts all links (internal + external) from the page, checks each with a HEAD request, and groups results by status: working (2xx), redirects (3xx), client errors (4xx), server errors (5xx), and timeouts. Checks up to 50 links concurrently for speed. Results cached for 5 minutes.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to scan for broken links (e.g., 'example.com' or 'https://example.com') |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by detailing the check method (HEAD requests), concurrency (50 links), caching (5 minutes), and result grouping (by status codes). This adds significant behavioral context that the readOnlyHint annotation alone does not convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the key purpose, and provides efficient details in a second paragraph. 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?
Given the tool has a single well-documented parameter and an output schema, the description fully covers the behavioral aspects (concurrency, caching, grouping) and does not need to explain return values. It is complete for effective tool usage.
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?
With 100% schema coverage, the schema already documents the 'url' parameter clearly. The description adds only minor clarifications (e.g., URL format examples), which are helpful but not essential. Therefore, 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 tool scans a page for broken links, specifying the actions (find 404s, redirects, timeouts, server errors) and resources (page). It is specific and distinct from sibling tools like 'seo_audit' or 'lighthouse_audit'.
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 guidance on when to use this tool versus alternatives (e.g., when to choose check_links over accessibility_audit or seo_audit). It lacks explicit context or exclusions, leaving the agent to infer from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check and analyze a site's robots.txt file.
Shows which paths are allowed/disallowed, sitemaps referenced, and crawl-delay settings.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Website URL or domain to check robots.txt |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only (readOnlyHint: true). Description confirms this with 'check and analyze' and lists outputs, but does not disclose additional traits like rate limits or error handling.
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 concise sentences, front-loaded with purpose. No 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 simple tool (1 param, no enums, output schema exists), the description adequately covers what the tool does and what it returns. No 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?
Only one parameter (url) with 100% schema coverage; description adds no new meaning beyond 'Website URL or domain to check robots.txt'. 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?
Clearly states verb 'check and analyze' and resource 'robots.txt', listing specific outputs (allowed/disallowed paths, sitemaps, crawl-delay). However, does not explicitly differentiate from sibling tools like seo_audit which may also analyze robots.txt.
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?
No guidance on when to use this tool versus alternatives like seo_audit. No mention of prerequisites or context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare SEO and performance scores of multiple websites side by side.
Useful for competitive analysis — see how your site stacks up against competitors across SEO, performance, and security.
| Name | Required | Description | Default |
|---|---|---|---|
| urls | Yes | Comma-separated URLs to compare (e.g., 'example.com,competitor.com') |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint: true, so the description does not need to disclose read-only behavior. The description adds no additional behavioral traits beyond what annotations convey, such as rate limits or scope limitations, so it meets the baseline with annotations present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences with no fluff. The first sentence directly states the function, and the second adds context for usage. Every word earns its place.
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 the tool has only one well-documented parameter and an output schema exists, the description is complete enough. It clarifies the comparison scope (SEO, performance, and security) and aligns with the tool's purpose, leaving no obvious 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 has 100% description coverage for the single 'urls' parameter, so the schema already provides clear semantics (comma-separated URLs, example). The tool description does not add extra meaning beyond the schema, resulting in a baseline score 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 the tool compares SEO and performance scores of multiple websites side by side. It uses a specific verb ('compare') and resource ('scores'), and distinguishes itself from sibling tools like seo_audit and performance_audit by focusing on side-by-side comparison rather than single-site auditing.
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 'Useful for competitive analysis — see how your site stacks up against competitors', providing clear context for when to use the tool. However, it does not explicitly mention when not to use it or suggest alternative tools, which prevents a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze SEO/security/performance gaps vs competitors.
Returns areas where competitors outperform your site, with specific recommendations for improvement.
| Name | Required | Description | Default |
|---|---|---|---|
| your_url | Yes | Your website URL | |
| competitor_urls | Yes | Comma-separated competitor URLs (up to 5) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is consistent with the readOnlyHint annotation, describing a read-only analysis. It adds context about returning recommendations, which is sufficient given the annotation coverage.
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-load the purpose and output, with no unnecessary words. Highly concise and well-structured.
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 adequately covers input and output despite an existing output schema. It mentions specific recommendations, providing useful context, though the competitor count limit is not explicitly stated (covered by schema).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters described. The description adds minimal extra meaning beyond 'your_url' and 'competitor_urls', so a 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 it analyzes SEO/security/performance gaps versus competitors and returns areas of outperformance with recommendations. This distinguishes it from sibling audit tools that focus on single aspects without comparison.
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 competitive analysis across multiple dimensions but provides no explicit guidance on when to use this tool instead of individual siblings like seo_audit or performance_audit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a comprehensive audit on a URL — SEO, performance, and security in one call.
Returns a unified score (0-100) plus detailed results for each category. This is the most complete analysis available.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to audit (e.g., 'example.com' or 'https://example.com') |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, indicating no side effects. The description adds that it returns a unified score and detailed results, but does not disclose further behavioral traits (e.g., rate limits, data freshness). With annotations covering safety, the description provides sufficient but not extensive behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the main action and categories, followed by output details and a strong closing. 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?
The description fully covers the tool's purpose, output structure (unified score + detailed results), and its position among siblings. With one simple parameter and an output schema, no additional details are necessary.
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?
Input schema has 100% coverage with a description for 'url.' The tool description does not add additional meaning beyond the schema—it mentions categories but not parameter specifics. 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 'Run a comprehensive audit on a URL — SEO, performance, and security in one call.' It specifies the resource (URL) and categories, and implicitly distinguishes from specialized siblings like seo_audit, performance_audit, and security_audit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: this tool is for a holistic audit covering SEO, performance, and security. It states 'This is the most complete analysis available,' implying use when a comprehensive view is needed. However, it does not explicitly mention when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run Google Lighthouse via PageSpeed Insights API — get performance, accessibility, SEO, and best-practices scores plus Core Web Vitals (LCP, INP, CLS).
Returns Lighthouse scores (0-100), Core Web Vitals with ratings, and the top 5 performance optimization opportunities ranked by potential time savings. This uses Google's real Lighthouse engine — the same tool Chrome DevTools uses. Takes 15-30 seconds to complete.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to audit with Google Lighthouse | |
| strategy | No | 'mobile' or 'desktop' (default: mobile) | mobile |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true, and the description adds value by disclosing runtime (15-30 seconds), the underlying engine (real Google Lighthouse), and core metrics (scores, Core Web Vitals, top opportunities). 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 concise (3-4 sentences) and front-loaded with the core purpose. Every sentence adds useful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description appropriately summarizes return values (scores, vitals, opportunities) without excessive detail. It covers key behavioral aspects (time cost) and is complete for a read-only audit tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters (url, strategy) described in the schema. The description does not add additional semantics beyond what the schema already 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 it runs Google Lighthouse via PageSpeed Insights API and returns performance, accessibility, SEO, and best-practices scores. It is specific about the resource (URL) and the verb (run/audit), but does not explicitly distinguish from sibling tools like accessibility_audit or performance_audit.
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 comprehensive web page auditing, but does not provide guidance on when to use this tool versus more focused siblings (e.g., seo_audit, security_audit). No when-not-to-use or alternative conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check page performance — response time, page size, compression, caching.
Returns server response time, page size, compression status, redirect chain analysis, and caching header review.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to check for performance |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds behavioral context by listing specific return values (response time, page size, compression status, redirect chain, caching headers). No contradictions.
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 concise sentences with front-loaded purpose and clear enumeration of return data. 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?
The tool has a single well-documented parameter and an output schema. The description adequately explains what is returned, making it complete for selection and 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 description coverage is 100% for the required URL parameter. The description does not add additional semantic meaning beyond what the schema provides, so baseline 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 the tool checks page performance and lists specific metrics (response time, page size, compression, caching). This distinguishes it from sibling audit tools like accessibility_audit or seo_audit.
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 performance checking but does not explicitly state when to use this tool over alternatives like lighthouse_audit or full_audit. No exclusions or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract and validate Schema.org structured data (JSON-LD, microdata).
Returns all structured data found on the page with validation hints and a breakdown by schema type. Critical for rich snippets in SERPs.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to check for structured data (Schema.org) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description aligns with readOnlyHint annotation, explaining non-destructive extraction and validation. Adds detail on output structure (validation hints, type breakdown) beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with action and resource. Every word serves a purpose; no 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?
With output schema present, description covers intent and result structure adequately. No missing critical information for a single-parameter read-only 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?
Single parameter 'url' is well-described in schema ('URL to check for structured data (Schema.org)'). Description adds value by clarifying the tool processes the URL and returns structured data results.
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 extracts and validates Schema.org structured data, specifying formats (JSON-LD, microdata) and outcome (validation hints, breakdown by type). Distinct from sibling tools like seo_audit.
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 mentions relevance for rich snippets in SERPs, providing clear context. Does not specify when to avoid or name alternatives, but purpose is single and obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a security audit on a URL.
Checks HTTPS, HSTS, CSP, X-Frame-Options, cookie flags, SSL certificate validity and expiration, server disclosure, and other security headers. Returns score + fixes needed.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to check for security |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true indicates no side effects, which is consistent. The description adds value by enumerating the specific security checks performed and the nature of the output (score + fixes), going beyond the 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 concise, listing checks in a bullet-like format and summarizing the output in one line. It is front-loaded and avoids unnecessary words, though it could be slightly more structured.
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 one parameter, an output schema, and annotations, the description provides sufficient context about what the audit covers and its output format. It could include possible prerequisites or limitations, but is complete for a simple audit 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?
There is only one parameter 'url' with a schema description of 'URL to check for security'. The tool description does not add additional meaning beyond this; schema coverage is 100%, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it runs a security audit on a URL, listing specific checks (HTTPS, HSTS, CSP, etc.) and output (score + fixes). This distinguishes it from sibling tools like accessibility_audit or seo_audit.
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 by detailing what the audit checks, but does not explicitly state when to use this tool over alternatives or when not to use it. It provides clear context for when security headers are the focus.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run an SEO-focused audit on a URL.
Checks title tags, meta descriptions, headings, images alt text, internal/external links, canonical URLs, Open Graph, structured data, mobile viewport, and content length. Returns score + actionable recommendations.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to analyze for SEO |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true. Description confirms it's a read operation returning score and recommendations. Does not mention rate limits or caching, but acceptable given annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-loading purpose and details. 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?
With one parameter and an output schema (present), description covers all necessary details: URL input, checks performed, and return type. No 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?
Only one parameter 'url' with schema description 'URL to analyze for SEO'. Description adds no extra meaning beyond schema. Baseline 3 due to 100% schema coverage.
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?
Explicitly states it runs an SEO-focused audit on a URL, listing specific checks and return type. Clearly distinguishes from sibling tools like performance_audit and security_audit.
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?
Describes when to use (SEO audit) but lacks explicit guidance on when not to use or comparison with alternatives like full_audit or competitor_gap_analysis. Still clear enough for typical use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Most tools target distinct audit areas, but 'full_audit' overlaps with individual audits like 'seo_audit', 'performance_audit', and 'security_audit'. Also, 'compare_sites' and 'competitor_gap_analysis' serve similar competitive analysis purposes, causing potential confusion.
All tool names use snake_case and are descriptive. However, some follow a 'verb_noun' pattern (check_links, check_robots_txt) while others use 'noun_verb' (accessibility_audit, security_audit), which is a minor inconsistency.
With 11 tools, the server covers a comprehensive set of site auditing capabilities without being bloated. Each tool addresses a specific need, and the count is appropriate for the domain.
The server covers major audit areas like accessibility, performance, SEO, security, links, and structure. Minor gaps exist, such as no dedicated mobile-friendliness check or sitemap validation, but Lighthouse and other tools partially fill these gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
SEO research, audits, backlinks, GSC, and content workflow tools for AI agents.
Scan any website's AI readiness: AI search visibility and AI agent usability. Free, no auth.
SEO & marketing toolkit for AI agents: GA4, Search Console, AdSense, GTM, PageSpeed, Trends.
Website QA for your coding agent: audit SEO, performance, security, accessibility over MCP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/vdalhambra/siteaudit-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
