Confirms that the upkeep-mcp server is running and reports which version it is.

Use this to verify the connection after installing or reconfiguring the server, or when another upkeep-mcp tool behaves unexpectedly and you need to establish whether the server itself is reachable.

Do not use it to check whether a website is up — it says nothing about any domain or URL, only about this server process. Use uptime_check for websites.

Returns the server name and version, the Node.js version it runs under, how long the process has been alive, and the time of the check.

Reports when a domain registration expires, who the registrar is, and how the domain is configured in DNS — nameservers, address records, mail exchangers, TXT and CAA records, whether the delegation is signed with DNSSEC, and what its SPF and DMARC records say about who may send email as it.

Use it to answer "is this domain about to lapse?", "who do we renew this with?", "where does this domain point?" or "why does the apex not work when www does?". It is the right first call when a site has gone dark for no obvious reason.

Use it too for "why is this client's email going to spam?" or "can someone spoof this domain?" — SPF and DMARC are read from the domain's own DNS.

It also asks each of the domain's own nameservers, directly, whether they agree about the zone. That answers "why does this site work for some people and not others?" and "is this old nameserver still in the delegation?" — a question no recursive resolver can answer, because it replies with whatever one server told it and does not say which. Pass checkNameservers: false to skip it.

Do not use it to check whether a website responds — that is uptime_check — or to inspect an SSL certificate, which is ssl_check. It reads only what registries and DNS publish. It reports no DKIM: finding a DKIM key needs its selector, and a selector cannot be discovered without guessing at names, which this project will not do.

Registration data comes from RDAP. Some country registries (.de, .nl, .no, .au, .fi) publish no expiry date at all; the result says so explicitly rather than reporting a gap as if it were an unknown. An expiry inside 30 days is reported as a warning and inside seven days as critical — a manual renewal needs that much lead time. Returns findings ordered by how much attention they need, worst first.

Inspects the TLS certificate a host actually serves: when it expires, who issued it, whether the chain verifies, which hostnames it covers, and which TLS version was negotiated.

Use it to answer "when does this certificate need renewing?", "why does the browser warn about this site?" or "does the certificate cover www as well as the bare domain?" — the last being one of the most common real-world misconfigurations, along with a missing intermediate certificate, which is reported as UNABLE_TO_VERIFY_LEAF_SIGNATURE.

Do not use it for domain registration expiry, which is a different date entirely — that is domain_check. It connects to the host but does not request a page; use uptime_check for that.

Certificates that are expired, self-signed or untrusted are inspected and reported rather than refused. Revocation is checked over OCSP, preferring the response a server staples to the handshake and otherwise asking the issuing authority directly; the answer is only believed once its signature verifies against that authority. Many healthy certificates cannot be checked at all, because since 2025 the two largest issuers publish no OCSP responder and distribute revocation by CRL instead — that is reported as an unavailable reason rather than as a problem with the site, and produces no finding. Certificate revocation lists are not downloaded.

A certificate is reported as a warning inside 14 days and as critical inside seven. That window is deliberately shorter than the one domain_check uses for registrations: ACME clients renew with 30 days left, so 28 days remaining is a healthy site in the middle of a normal renewal, not a problem. Returns findings ordered by urgency, worst first.

Requests a page and reports whether it answered, how long it took, the full redirect chain it went through, whether plain HTTP is upgraded to HTTPS, and which security headers came back.

Use it to answer "is this site up?", "why does this URL take four redirects to load?", "does http:// still work and should it?" or "does this site send HSTS?". It is the check to run when a client reports that a page is down or slow.

Do not use it to inspect a certificate — that is ssl_check — or for registration and DNS, which is domain_check. It fetches one page, not a whole site: use seo_audit for crawling.

Redirects are followed one hop at a time so the whole chain is visible, up to ten hops. Response time is wall clock to the first response headers and includes DNS, TCP and TLS setup, so it is not a measure of server processing time.

Status codes are graded rather than lumped together: 5xx, 404 and 410 are critical, 401 and 403 are a warning because they are normal for a staging site, and 429 is reported as unknown because a throttled check establishes nothing about real availability. Returns findings ordered by urgency, worst first.

Reads one page and reports the technical SEO facts a maintenance retainer is judged on: title and meta description, heading structure, canonical, Open Graph, hreflang, language, viewport, images with no alt text, the state of robots.txt and the sitemap, and which internal links are broken. The sitemap is checked against the rules of the sitemaps protocol, so a file that exists but that consumers drop is reported as broken rather than as present.

Use it to answer "why is this page not being indexed?", "does this page have the metadata it needs?" or "are there broken links on the homepage?". It is the check to run before a quarterly report, and after a site rebuild.

Do not use it to check whether a site is up, which is uptime_check, or to inspect a certificate, which is ssl_check. It audits one page: it does not crawl a site, and it judges only what is in the HTML, never how a page ranks.

robots.txt is read first and obeyed. A page this crawler is not allowed to read is reported as such and is not requested — and neither are internal links it forbids. An unreadable robots.txt is treated as forbidding everything, per RFC 9309.

Link checking is one HTTP request per link, paced politely, so an audit with links takes seconds rather than milliseconds; pass checkLinks: false when speed matters more. Returns findings ordered by urgency, worst first.

Walks a site from a starting page and reports what only a crawl can see: pages sharing a title or a meta description, internal links that are broken and which page links to them, pages asking not to be indexed, and how much of the site was reachable at all.

Use it after a site rebuild or a migration, and before a quarterly report — the findings here are the ones a client never notices and a search engine always does. Use it to answer "why are these pages competing with each other?", "are there broken links", anywhere on the site?" or "is anything still marked noindex from staging?".

Do not use it to audit one page in depth — that is seo_audit, which reports canonical, Open Graph, hreflang, images without alt text and the sitemap for a single URL. Do not use it to check whether a site is up (uptime_check) or to inspect a certificate (ssl_check). It judges only what is in the HTML, never how a page ranks.

It stays on one origin: https://example.com and https://www.example.com are different origins and only the one you start from is visited.

robots.txt is read first and obeyed for every URL before it is requested. An unreadable robots.txt is treated as forbidding everything, per RFC 9309, and the crawl reports that rather than proceeding.

It costs one request per page, paced at one every half second per host, so 25 pages is about fifteen seconds. Three budgets bound it — pages, depth, and a two-minute deadline — and whichever one stopped the crawl is reported along with how many URLs were left unvisited, because a report that does not say it saw a quarter of the site is worse than no report.

Opens one page in a real browser and runs axe-core over it, reporting the WCAG rules it fails, how many elements fail each one, and where they are.

Use it to answer "does this page meet WCAG 2.2 AA?", "what would an accessibility audit flag?" or "which of these fixes matters most?". It is the check to run before a site goes live, and when a client asks about accessibility obligations.

Do not use it for metadata, headings or broken links, which seo_audit reports without a browser and far faster. It audits one page, not a site, and it renders that page: it is much slower than every other tool here.

It needs a browser. Nothing else in this server does, so if none is installed this tool says so and names the one command that fixes it, while every other check keeps working. A hosted instance runs it too: the published image ships a browser, and every request that browser makes goes through the same public-address and web-port rules as the rest of this server.

Automated rules find roughly a third of accessibility problems. A page with no violations is a page that passed the machine-checkable part, which is not the same as being usable, and the count of undecided rules is reported for exactly that reason. robots.txt is obeyed. Returns findings ordered by urgency, worst first.

Runs the maintenance checks across every site in a portfolio and returns one report ordered by what needs action first: what is down, what expires soonest, what regressed since the last run.

Use it to answer "what needs attention this week?", "is anything down?" or "what do I put in this quarter's report?" across a whole client list. It is the right call whenever the question is about more than one site — running domain_check, ssl_check and uptime_check once per site by hand is what this replaces.

The portfolio comes from the "sites" argument, or from a local JSON file ("sites.json" by default) whose format is documented in sites.example.json. Pass "checks" to override what each site asks for — ["uptime"] answers "is anything down right now?" in a fraction of the time — and "tags" to report on part of the portfolio.

Do not use it to answer a question about one site: domain_check, ssl_check, uptime_check and seo_audit answer those directly and in a fraction of the time. It runs checks and reports; it never changes a site, and it never writes to the portfolio file.

A site that cannot be checked is reported as a finding, never as a failure of the whole report. Only a portfolio that cannot be read at all is an error.

What changed since the previous run is compared against one recorded snapshot. By default that snapshot lives in memory and is lost when this server restarts; a portfolio file may add a "history" path, and then the snapshot is written there and comparisons survive a restart for up to 90 days. Nothing is written unless the portfolio asks for it. Either way the report says what it had to compare against, and why it had nothing when it had nothing, rather than implying nothing changed. Only sites that both runs measured the same way are compared, so a quick uptime-only pass never invents regressions in the run after it.