What upkeep-mcp MCP server does
upkeep-mcp MCP server provides recurring maintenance checks for websites and domain portfolios. Its checks cover registration and DNS details, TLS certificates, HTTP availability, technical SEO, accessibility, and portfolio-wide prioritization. The intended workflow is ongoing site maintenance, especially when one operator looks after several client domains and needs to identify the most urgent work.
The server reports both readable findings and structured data. Structured output can be sorted, filtered, and used to build follow-up reports. Individual checks can be run for a single domain or URL, while portfolio_report combines the available checks across a portfolio and orders results by urgency.
How it works
Checks use publicly available information rather than authenticated site data. Domain inspection includes registration expiry, registrar information, DNS records, DNSSEC, nameserver behavior, and SPF and DMARC observations. Each authoritative nameserver can also be queried directly over TCP with recursion disabled to identify delegation or zone-consistency problems. That nameserver inspection can be disabled with checkNameservers: false.
TLS inspection examines certificates even when they are expired, self-signed, or otherwise untrusted. It reports certificate validity, issuer, covered hostnames, negotiated TLS details, and revocation status. Revocation checks use stapled OCSP data when available or query the certificate’s responder directly. Some certificates cannot be checked because their authorities do not publish an OCSP responder; that condition is reported as unavailable rather than treated as a site finding.
Website checks follow redirects, test HTTPS behavior, inspect security headers, and review page metadata and internal links. SEO crawling can identify duplicate titles, broken links, and stray noindex directives across a site. Accessibility auditing uses axe-core in a real browser.
Setup and configuration
The upkeep-mcp MCP server is published on npm and can be installed through the project’s documented installation process.
The main inputs are a domain or URL, with optional values where supported. ssl_check accepts an optional port and defaults to 443. seo_audit accepts checkLinks, which defaults to true, and maxLinks, which defaults to 25. Portfolio checks can skip direct nameserver testing with checkNameservers: false.
Tools and capabilities
domain_check: Reports expiry, registrar, registry statuses, DNS records, DNSSEC, resolution of the apex and www, plus SPF and DMARC findings.ssl_check: Examines certificate dates, issuer, chain validation, SAN coverage, TLS negotiation, and revocation.uptime_check: Returns HTTP status, response time, redirect hops, HTTPS upgrade behavior, HSTS, and selected security headers.seo_audit: Reviews page metadata, headings, canonical and language information, social tags, images without alt text, robots.txt, sitemaps, and broken internal links.site_crawl: Finds duplicate titles, broken links, and unexpected noindex directives across a site.accessibility_audit: Checks WCAG violations through axe-core in a browser.portfolio_report: Runs portfolio checks and sorts findings by urgency.health: Returns server name, version, Node.js version, and process uptime.
The portfolio://sites resource exposes the configured site list without requiring a tool call. The quarterly_report prompt turns a portfolio run into a client-facing report.
Limitations and notes
upkeep-mcp MCP server is in early development. Accessibility checks require a real browser, while the other listed checks are designed around information available without one. DKIM is intentionally not reported because selectors cannot be discovered without guessing or enumerating DNS names.
An absent SPF or DMARC record is treated as informational rather than as a newly broken condition. Incorrect records can produce warnings. Nameserver TCP refusal is not automatically treated as a DNS failure, because some healthy nameservers refuse TCP while still serving normal resolver traffic. Different zone serials are also not necessarily errors.
A successful TLS handshake does not establish revocation status by itself. The server separately validates OCSP evidence when a responder is available, and it distinguishes an unavailable revocation source from a confirmed certificate problem.