OctoBoost MCP Server for token-efficient SEO / GEO analysis. Analyze multiple URLs with categorized checks and scored results.
OctoBoost MCP Server demonstrates solid tool definition practices with clear naming, detailed descriptions, and well-structured input schemas. All 4 tools follow verb_noun naming conventions (list_analyzers, scan_domain, analyze, get_stored_analysis). Descriptions are comprehensive and explain WHAT, WHEN, and context (e.g., analyze tool explicitly mentions credit costs and progress reporting). Input schemas use Zod validation with proper types and descriptions. However, output schemas are undocumented in the visible code, responses are constructed as formatted text strings rather than structured typed objects returned to the LLM. Parameter descriptions are thorough and include constraints (e.g., maxPages capped at batch limit, respectRobotsTxt defaults to true). Error handling in client.ts distinguishes between 401 (auth), 402 (credits), and generic API errors with actionable messages. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present despite all tools being READ_ONLY. Minor issue: scan_domain and analyze accept URLs but descriptions could clarify expected format (FQDN vs full URL).
Analyze one or more URLs for SEO issues. Runs all analyzers and returns scores, issues, and a GEO/AEO score measuring AI search visibility (citation likelihood, RAG readiness, and sub-metrics for technical access, content structure, entity clarity, and authority signals). Processes URLs sequentially and reports progress after each. Costs 3 credits per URL.
Retrieve previously stored SEO analysis reports. No credits consumed. Supports filtering by URL, category, or single analyzer key. Returns paginated results (10 per page). Use this to review past analyses without re-crawling.
List all available SEO analyzers with their keys, categories, and weights. Call this first to discover what analyzers and categories are available before running an analysis.
Crawl a domain and return all SEO-relevant page URLs. Use this to discover pages before running analysis.
list_analyzers has NO visible input schema in source code (File: src/tools/list.ts truncated). Tool is registered but schema definition not shown. Per hard scoring rules, schema score must be 0 if not visible.
Output schemas are undocumented. All tools return formatted text strings (lines array) rather than structured typed objects. LLMs cannot plan downstream calls or extract specific fields from responses. Analyze tool constructs human-readable output (e.g., 'URL: {url}', 'Score: {score}') instead of returning {url, score, geoScore, ...} as a typed object.
Tool annotations missing. All four tools are READ_ONLY (no side effects, safe to retry, idempotent), but none declare readOnlyHint in their registration. Current MCP spec (2026-07-28) supports tool annotations; clients and LLMs use these to optimize caching and retry logic.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 55 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 49 | - | v1 |
Pagination in get_stored_analysis lacks total_count or next_cursor in returned response. Tool accepts 'page' parameter (default 1, page size 10) but description does not state how many total results exist or whether more pages are available. LLM cannot efficiently iterate through large result sets.
scan_domain and analyze accept 'domain' and 'urls' parameters but descriptions do not clearly distinguish between FQDN (example.com) and full URL (https://example.com). scan_domain description says 'e.g. example.com or https://example.com' but this is an example in prose, not a constraint. Should use enum or regex pattern in schema description.