DigestSEO MCP Suite: production AI search infrastructure
Four related open-source systems behind DigestSEO: AI visibility tracking, Google Search Console access, technical web validation, and live news and search-trend research. Built as local and remote MCP surfaces with explicit security boundaries, deployment paths, and human-readable outputs.
Explore DigestSEOOne product ecosystem, four deliberately different data and tooling surfaces.
Why these systems belong together
DigestSEO needs more than one API wrapper. AI-search work spans several evidence sources: what answer engines say about a brand, what Google Search Console reports, whether the underlying website is technically sound, and what demand is changing now. I built each concern as its own bounded MCP server so it can be used independently, while the product can compose them when a broader investigation needs more than one source.
That separation also keeps permissions honest. Search Console requires Google account access; public-page validation should not inherit those credentials; AI-visibility scans spend model or search-provider quota; and trend/news retrieval has a different network and browser threat surface. One monolithic agent would make those boundaries harder to reason about.
Four focused MCP systems
Each repository has a narrow job and its own runtime constraints. The links below point to the source and, where a hosted DigestSEO surface is public, the corresponding product page.
AI visibility and citation tracking
Tracks brand visibility and citations across answer engines, with local SQLite and Cloudflare/D1 implementations, scheduled refreshes, competitor comparisons, citation evidence, and content-gap analysis. The same core can run locally with user-supplied provider keys or behind a managed remote surface.
Key concerns: provider fan-out, quota-aware execution, citation matching, persisted history, prompt generation, and separating local brand-management capabilities from hosted admin operations.
Google Search Console through MCP
Turns Search Console analytics, URL inspection, sitemap operations, indexing eligibility checks, and higher-level SEO analyses into a typed MCP surface. OAuth onboarding replaces copied service-account credentials, while read-only and read-write modes keep requested Google scopes aligned with the deployment.
Key concerns: OAuth token handling, least-privilege modes, pagination and comparison logic, safe write operations, and turning raw GSC rows into useful quick-win, decay, cannibalization, and weekly-digest workflows.
Technical web validation and bounded site audits
Combines HTML/CSS validation, on-page SEO and accessibility signals, JSON-LD syntax checks, broken-link checks, and responsive screenshots locally. The hosted surface is intentionally narrower: it can audit authorized public pages or a bounded sitemap-first site sample without gaining local-file or arbitrary crawling access.
Key concerns: SSRF-resistant URL handling, redirect validation, robots and sitemap boundaries, request caps, external validator integration, and keeping local filesystem capabilities out of the hosted app.
Live news and search-demand intelligence
A Python MCP server that combines Google News discovery and article extraction with Google Trends research: interest over time, growth, geographic interest, related demand, suggestions, and search-property comparisons. Difficult articles can use a guarded Playwright fallback.
Key concerns: untrusted outbound retrieval, redirect and private-network blocking, browser fallback, provider rate limits, reproducible trend windows, and a smaller goal-oriented remote tool surface. The community server is usable today; the managed DigestSEO/OpenAI-facing layer is still being productized.
Shared engineering pattern, separate trust boundaries
The common layer is MCP: typed tools give AI clients a discoverable contract instead of forcing prompts to scrape dashboards or invent API calls. Beyond that contract, the implementations stay deliberately different. TypeScript/Cloudflare Workers suits the hosted SEO services and edge storage; Python suits TrendPulse's news extraction, trends providers, and Playwright path.
Remote surfaces are treated as internet-facing applications rather than local scripts. Inputs are bounded, outbound targets are validated, privileged operations are separated, and hosted tools expose fewer capabilities when a local-only capability would create unnecessary risk. CI, package metadata, deployment manifests, and client-specific installation paths are part of the product, not afterthoughts.
Distribution is part of the system
The suite is designed to meet users where they already work: npm or other local runners for self-hosting, remote MCP endpoints for cloud clients, registry and marketplace metadata where appropriate, and DigestSEO product pages for managed use. The repositories remain useful on their own instead of existing only as thin marketing shells for the hosted product.
What this project demonstrates
- A multi-repository product can share one protocol without collapsing distinct security and permission models into one server.
- Hosted and local agent tooling need different capability surfaces: convenience is not a reason to expose filesystem, browser, credential, or write access remotely.
- LLM-facing tools still need deterministic boundaries around authentication, URL access, quotas, validation, and side effects.
- Open-source distribution, documentation, manifests, CI, and hosted product integration can be treated as one engineering lifecycle.