GEO Analysis for AI SEO
Analizador GEO
Análisis de contenido para la visibilidad en búsquedas de IA. Mide lo que realmente importa para ser citado por ChatGPT, Claude, Perplexity y Google AI Overviews.
Navegación rápida
Qué hace | Instalación | Ejemplos de uso | Salida | Herramientas | Solución de problemas | Fundamentos de investigación
Qué hace
El Analizador GEO examina el contenido en busca de las señales que utilizan los sistemas de IA al seleccionar fuentes para citar:
Densidad de afirmaciones - Hechos extraíbles por cada 100 palabras
Densidad de información - Recuento de palabras frente a la cobertura de IA prevista
Anticipación de respuestas (Frontloading) - Qué tan rápido aparece la información clave
Triples semánticos - Relaciones estructuradas (sujeto, predicado, objeto)
Reconocimiento de entidades - Entidades nombradas que la IA puede referenciar
Estructura de oraciones - Longitud óptima para el análisis de IA
El análisis se ejecuta localmente utilizando Claude Sonnet 4.5 para la extracción semántica. Sin servicios externos, sin datos que salgan de su máquina.
Related MCP server: agentaeo-mcp-server
Instalación
Claude Desktop
Añada esto a su claude_desktop_config.json:
{
"mcpServers": {
"geo-analyzer": {
"command": "npx",
"args": ["-y", "@houtini/geo-analyzer@latest"],
"env": {
"ANTHROPIC_API_KEY": "sk-ant-..."
}
}
}
}Ubicaciones de configuración:
Windows:
%APPDATA%\Claude\claude_desktop_config.jsonmacOS:
~/Library/Application Support/Claude/claude_desktop_config.jsonLinux:
~/.config/Claude/claude_desktop_config.json
Reinicie Claude Desktop después de guardar.
Claude Code (CLI)
Claude Code utiliza un mecanismo de registro diferente; no lee claude_desktop_config.json. Utilice claude mcp add en su lugar:
claude mcp add -e ANTHROPIC_API_KEY=sk-ant-... -s user geo-analyzer -- npx -y @houtini/geo-analyzer@latestVerifique con:
claude mcp get geo-analyzerDebería ver Status: Connected.
Requisitos
Node.js 20+
Clave de API de Anthropic (console.anthropic.com)
Ejemplos de uso
Analizar una URL publicada
Analyse https://example.com/article for "topic keywords"El contexto del tema ayuda a puntuar la relevancia, pero no es obligatorio:
Analyse https://example.com/articleAnalizar texto directamente
Pegue el contenido para su análisis (mínimo 500 caracteres):
Analyse this content for "sim racing wheels":
[Your content here]Modo resumen
Obtenga una salida condensada sin recomendaciones detalladas:
Analyse https://example.com/article with output_format=summarySalida
Puntuaciones (0-10)
Puntuación | Medidas |
General | Promedio ponderado de todos los factores |
Capacidad de extracción | Qué tan fácilmente puede la IA extraer hechos |
Legibilidad | Calidad de la estructura para el análisis de IA |
Citabilidad | Qué tan citable y atribuible es |
Métricas clave
Densidad de información:
Recuento de palabras con predicción de cobertura
Rango óptimo: 800-1.500 palabras
Páginas de menos de 1.000 palabras: ~61% de cobertura de IA
Páginas de más de 3.000 palabras: ~13% de cobertura de IA
Anticipación de respuestas (Frontloading):
Afirmaciones y entidades en las primeras 100/300 palabras
Posición de la primera afirmación
Puntuación que indica la inmediatez de la respuesta
Densidad de afirmaciones:
Objetivo: 4+ afirmaciones por cada 100 palabras
Hechos, estadísticas y mediciones extraíbles
Longitud de oraciones:
Objetivo: 15-20 palabras de promedio
Coincide con la extracción de fragmentos de ~15,5 palabras de Google
Recomendaciones
Sugerencias priorizadas con:
Ubicaciones específicas en el contenido
Ejemplos de antes/después
Justificación basada en la investigación
Herramientas
analyze_url
Recupera y analiza páginas web publicadas.
Parámetro | Requerido | Descripción |
| Sí | URL a analizar |
| No | Contexto del tema para la puntuación de relevancia |
| No |
|
analyze_text
Analiza el contenido pegado directamente.
Parámetro | Requerido | Descripción |
| Sí | Texto a analizar (mín. 500 caracteres) |
| No | Contexto del tema para la puntuación de relevancia |
| No |
|
Solución de problemas
"ANTHROPIC_API_KEY is required"
Añada su clave de API a la sección env en la configuración.
"Cannot find module" después de un cambio de configuración Reinicie Claude Desktop por completo.
"Content too short" Se requieren al menos 500 caracteres para un análisis significativo.
El contenido tras un muro de pago devuelve errores El analizador solo puede acceder a páginas disponibles públicamente.
Rendimiento
Análisis de URL: ~8-10 segundos
Análisis de texto: ~5-7 segundos
Coste: ~$0,14 por análisis (Sonnet 4.5)
Migración desde v1.x
La v2.0 eliminó las dependencias externas. Actualice su configuración:
Antigua (v1.x):
{
"env": {
"GEO_WORKER_URL": "https://...",
"JINA_API_KEY": "jina_..."
}
}Nueva (v2.x):
{
"env": {
"ANTHROPIC_API_KEY": "sk-ant-..."
}
}Desarrollo
git clone https://github.com/houtini-ai/geo-analyzer.git
cd geo-analyzer
npm install
npm run buildFundamentos de investigación
La metodología de análisis se basa en investigaciones revisadas por pares y estudios empíricos:
Documento GEO del MIT (2024)
Aggarwal et al., "GEO: Generative Engine Optimization" - ACM SIGKDD
Hallazgos clave aplicados:
Objetivo de densidad de afirmaciones de 4+ por cada 100 palabras
Longitud óptima de oración de 15-20 palabras
Mejora del 40% en las tasas de citación de IA con enfoque en la capacidad de extracción
Investigación de fundamentación de Dejan AI (2025)
Análisis empírico de 7.060 consultas y 2.275 páginas
Hallazgos clave aplicados:
~2.000 palabras de presupuesto total de fundamentación por consulta
La fuente en el puesto #1 obtiene 531 palabras (28% del presupuesto)
La fuente en el puesto #5 obtiene 266 palabras (13% del presupuesto)
Fragmento de extracción promedio: 15,5 palabras
Páginas <1K palabras: 61% de cobertura
Páginas 3K+ palabras: 13% de cobertura
dejan.ai/blog/how-big-are-googles-grounding-chunks
dejan.ai/blog/googles-ranking-signals
Licencia MIT - Houtini.ai
Available Tools
2 toolsanalyze_textB
Analyze pasted text content for AI search optimization. Performs comprehensive content quality analysis including AI slop detection, writing quality, E-E-A-T signals, data points, originality, and actionability.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | The text content to analyze (markdown, plain text, or HTML) | |
| query | No | Optional context string describing the content topic (e.g., "sim racing equipment", "SEO guide"). Used for relevance scoring only. Defaults to "general content analysis". | |
| output_format | No | Output verbosity: "detailed" (default) includes all suggestions and recommendations; "summary" provides condensed results | detailed |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. While it mentions the analysis dimensions and output format options, it lacks critical behavioral details: no information about rate limits, authentication requirements, processing time, error conditions, or what constitutes 'comprehensive' analysis. The description doesn't contradict annotations (none exist), but fails to provide sufficient behavioral context for a tool with no 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?
The description is appropriately concise with two sentences that efficiently convey the tool's purpose and scope. The first sentence states the core function, and the second elaborates on analysis dimensions. No redundant or unnecessary information is included. However, it could be slightly more front-loaded by mentioning the key parameters or output options earlier.
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 3 parameters with 100% schema coverage but no annotations and no output schema, the description is moderately complete. It covers the tool's purpose and analysis dimensions adequately but lacks important contextual information about behavioral characteristics (rate limits, auth needs, processing behavior) and doesn't describe the output format or structure. For a text analysis tool with no output schema, more detail about return values would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds minimal parameter semantics beyond the schema - it mentions 'pasted text content' which aligns with the 'content' parameter, and 'AI search optimization' context which relates to the 'query' parameter's purpose. However, it doesn't provide additional meaning or usage examples beyond what's already in the schema 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 states the tool's purpose: 'Analyze pasted text content for AI search optimization' with specific analysis dimensions listed (AI slop detection, writing quality, E-E-A-T signals, etc.). It distinguishes from the sibling tool 'analyze_url' by specifying 'pasted text content' rather than URL analysis. However, it doesn't explicitly contrast with the sibling tool's functionality.
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 context through 'pasted text content' and 'AI search optimization,' suggesting when this tool is appropriate. It mentions the sibling tool 'analyze_url' exists but provides no explicit guidance on when to use this tool versus that alternative. No exclusion criteria or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
analyze_urlC
Analyze a published URL for AI search optimization. Performs comprehensive content quality analysis including AI slop detection, writing quality, E-E-A-T signals, and actionability.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL to analyze | |
| query | No | Optional context string describing the content topic (e.g., "sim racing wheels", "content optimization"). Used for relevance scoring only. Defaults to "general content analysis". | |
| output_format | No | Output verbosity: "detailed" (default) includes all suggestions and recommendations; "summary" provides condensed results | detailed |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'comprehensive content quality analysis' but doesn't describe what the analysis returns, potential limitations (e.g., rate limits, authentication needs, or what 'AI slop detection' entails), or side effects. For a tool with no annotations and no output schema, this leaves significant gaps in understanding how the tool behaves.
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 highly concise and front-loaded: a single sentence that efficiently states the tool's purpose and key analysis components without unnecessary words. Every phrase ('AI search optimization', 'comprehensive content quality analysis', specific detection types) adds value, making it zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (analyzing URLs for multiple quality signals) and lack of annotations and output schema, the description is incomplete. It doesn't explain what the analysis returns, potential errors, or behavioral traits like rate limits or permissions. The agent is left guessing about the output format and operational constraints, which is inadequate for a tool with no structured output information.
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 description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't explain how 'query' affects 'relevance scoring' in more detail or what 'output_format' choices imply beyond the schema's enum). Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Analyze a published URL for AI search optimization' with specific components like 'content quality analysis', 'AI slop detection', 'writing quality', 'E-E-A-T signals', and 'actionability'. It distinguishes from the sibling 'analyze_text' by specifying URL analysis rather than text analysis. However, it doesn't explicitly contrast with the sibling tool in the description text itself.
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 no guidance on when to use this tool versus alternatives. While it implies usage for URL analysis (versus text analysis for the sibling), there's no explicit mention of the sibling tool, prerequisites, or scenarios where this tool is preferred over others. The agent must infer usage context from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
v3.0.3- First observed
analyze_text - First observed
analyze_url
TDQS
Scored across 2 tools
The two tools have clearly distinct purposes: analyze_text for pasted text content and analyze_url for published URLs. While their analysis components overlap significantly (both include AI slop detection, writing quality, E-E-A-T signals, and actionability), the input type distinction prevents confusion. The only minor ambiguity is that analyze_text mentions additional features like data points and originality not listed for analyze_url.
Both tools follow a perfect verb_noun pattern with consistent snake_case naming: analyze_text and analyze_url. The naming is completely predictable and readable, with no deviations in style or convention across the tool set.
With only 2 tools for a server named 'GEO Analysis for AI SEO' that suggests geographical and SEO analysis capabilities, the tool count feels too thin. The server's name implies broader functionality (potentially geographical data analysis, keyword research, competitor analysis, etc.), but the tools only cover content analysis of text and URLs, leaving significant gaps in the apparent domain scope.
The tool set is severely incomplete for the server's stated purpose of 'GEO Analysis for AI SEO'. While the two tools provide content quality analysis, there are obvious gaps: no geographical analysis tools (e.g., location-based SEO, regional keyword analysis), no SEO-specific tools (e.g., keyword research, backlink analysis, ranking tracking), and no AI SEO optimization beyond content assessment. This will likely cause agent failures when trying to perform comprehensive GEO or SEO tasks.
Maintenance
Related MCP Connectors
SEO, GEO & AI Visibility — research, write, optimize, publish & monitor content. 121 tools.
Track AI visibility (ChatGPT, Gemini, AI Overviews), research SEO keywords, write, publish, prove.
Free AI visibility (GEO/AEO) audit: can ChatGPT, Claude and Perplexity find and cite your website?
Measure how AI engines cite your brand. Cross-engine GEO visibility, as agent tools.
Related MCP Servers
- AlicenseBqualityDmaintenanceAdvanced content gap analysis using Query Decomposition and Keyword Fan-Out (Google's patented methodology). Tells you exactly what user queries your content covers - and what it misses. Built on academic research because I needed to understand how AI search engines actually evaluate content.1221 npm12Apache 2.0
- AlicenseAqualityDmaintenanceAudit your brand's visibility across ChatGPT, Perplexity, Claude, and Google AI - get citation rates, AEO health scores, content gap analysis, and a 9-page content suite to rank in AI-generated answers.598 npmMIT
- AlicenseAqualityCmaintenanceUnifies traditional SEO and Generative Engine Optimization (GEO) for Google, Bing, Yandex, and major LLMs, providing tools for search performance analysis, citation tracking, on-page audits, and internal link graph analysis.363MIT
- -licenseNot gradedqualityCmaintenanceEnables AI assistants to perform comprehensive SEO and GEO measurements, including site audits, keyword research, ranking tracking, and brand visibility analysis across search engines and generative AI platforms.-