프로토타입 · 미리 보기: 공식 레지스트리의 모든 서버를 담고 있으며 30분마다 동기화해요. 리뷰와 계정 기능은 다음 단계에서 열려요.
PopNx MCPAI를 쓰는 사람을 위한 MCP 서버 · 쉬운 말로 설명해요

upkeep-mcp

제작자: tiagocalado86버전 0.6.1i★ –i내 컴퓨터에서 실행
레지스트리 이름io.github.tiagocalado86/upkeep-mcp

설치

개요

제작자가 쓴 설명(영어 원문)

Website maintenance checks: domains, SSL, uptime, technical SEO and accessibility

PopNx MCP의 세 기둥

이 세 가지는 절대 하나의 점수로 합치지 않아요. 의견, 측정, 인기는 서로 다른 것이니까요.

할 수 있는 일

이 서버는 아직 쉬운 말로 된 요약을 쓰지 못했어요. 아래는 레지스트리에서 읽어 온 사실이에요.

  • 연결 방식: 내 컴퓨터에서 실행
  • 전송 방식: stdio
  • 카테고리: 마케팅 및 소셜 미디어

설치

쓰고 있는 AI 앱을 고른 다음 설정을 복사하세요.

설치하기 전에

  • 기본 점검: 1개 중 1개 통과
  • 내 컴퓨터에서 내 사용자 계정의 권한(파일, 네트워크, 앱)으로 실행돼요.
  • 레지스트리에 입력해야 할 키가 나와 있지 않아요.

필요한 것

  • npmNode.js 설치(npx 명령어용)

어떤 앱을 쓰세요?

위에서 앱을 고르세요. 기억해 두었다가 다음부터는 버튼에 “…에 설치”라고 표시해요.

Claude Desktop → Settings → Developer → Edit Config를 열고 claude_desktop_config.json에 이 내용을 붙여 넣으세요

{
  "mcpServers": {
    "upkeep": {
      "command": "npx",
      "args": [
        "-y",
        "upkeep-mcp"
      ]
    }
  }
}

터미널에서 이 명령어를 실행하세요

claude mcp add upkeep -- npx -y upkeep-mcp

Cursor에서 열기

또는 설정을 직접 복사하기

프로젝트의 .cursor/mcp.json 또는 ~/.cursor/mcp.json에 붙여 넣으세요

{
  "mcpServers": {
    "upkeep": {
      "command": "npx",
      "args": [
        "-y",
        "upkeep-mcp"
      ]
    }
  }
}

브라우저가 앱을 열지 물어본 다음, 앱이 설정을 보여 주고 확인을 요청해요. 키 값은 비워 두니 직접 입력하세요.

VS Code에서 열기

또는 설정을 직접 복사하기

프로젝트의 .vscode/mcp.json에 붙여 넣으세요

{
  "servers": {
    "upkeep": {
      "type": "stdio",
      "command": "npx",
      "args": [
        "-y",
        "upkeep-mcp"
      ]
    }
  }
}

브라우저가 앱을 열지 물어본 다음, 앱이 설정을 보여 주고 확인을 요청해요. 키 값은 비워 두니 직접 입력하세요.

이 서버는 내 컴퓨터에서 실행되는데, ChatGPT는 인터넷에 있는 서버에만 연결할 수 있어요. 다른 앱을 고르세요.

선택한 앱은 이 기기의 쿠키에만 저장돼요. 계정은 필요 없어요.

이 설정은 제작자의 레지스트리 정보로 만들었어요. README와 다르면 README를 따르세요.

할 수 있는 일

내 컴퓨터에서 실행돼요. 설치하면 AI 앱에 도구 목록이 나타나요.

기본 점검i

누구나 볼 수 있는 정보를 점검했고, 코드는 읽지 않았어요. 해당하지 않는 항목은 개수에서 뺐어요. · 2026년 11월 7일 점검

  • ✓ 통과

    제작자와 저장소 일치

    레지스트리 이름이 GitHub 계정 tiagocalado86 기준으로 확인되었고, 이 계정이 저장소를 소유하고 있어요

  • … 아직 점검 안 함

    계속 관리되고 있음

    아직 GitHub에서 이 저장소를 읽어 오지 않았어요

  • … 아직 점검 안 함

    라이선스 있음

    아직 GitHub에서 이 저장소를 읽어 오지 않았어요

  • – 해당 없음

    엔드포인트 응답

    내 컴퓨터에서 실행되는 서버라 인터넷 엔드포인트가 없어요

  • – 해당 없음

    OAuth로 로그인

    내 컴퓨터에서 실행되며, 대신 로컬 설정을 사용해요

  • … 아직 점검 안 함

    도구 설명에 숨겨진 지시 없음

    내 컴퓨터에서 실행돼요. 도구 목록은 인터넷 엔드포인트가 있는 서버에서만 읽을 수 있어요

마케팅 및 소셜 미디어 카테고리의 다른 서버와 비교i

  • 이 카테고리의 다른 서버 3559개 중 0%보다 스타가 많아요
  • 이 카테고리의 다른 서버 3559개 중 31%보다 최근에 레지스트리에 공개됐어요
  • 기본 점검 결과가 이 카테고리의 다른 서버 3559개 중 100%와 같거나 더 좋아요

레지스트리에서 이 카테고리의 활성 서버 전체와 비교했어요. 스타는 게시자가 저장소를 소유한 경우에만 세요.

자주 묻는 질문

upkeep-mcp, 안전한가요?

해당하는 기본 점검 1개 중 1개를 통과했어요. 코드는 읽지 않았어요. 키나 토큰을 넣기 전에 서버가 어떤 권한을 요구하는지 확인하고, 꼭 필요한 권한만 있는 키를 쓰세요.

어떤 키나 코드가 필요한가요?

레지스트리에 필수 키가 나와 있지 않아요. 다만 처음 쓸 때 로그인을 요구하는 서버도 있어요.

내 컴퓨터에서 실행되나요, 클라우드에서 실행되나요?

내 컴퓨터에서 실행돼요. AI 앱이 필요할 때 실행하고, 데이터는 제작자의 서버를 거치지 않아요(서버 자체가 온라인 서비스를 호출하는 경우는 제외).

아직 관리되고 있나요?

GitHub 저장소는 마지막으로 – 변경됐고, 최신 버전(0.6.1)은 2개월 전 레지스트리에 올라왔어요.

어떤 앱에서 쓸 수 있나요?

Claude Desktop, Claude Code, Cursor, VS Code처럼 MCP를 지원하는 앱에서 쓸 수 있어요. 내 컴퓨터에 Node.js도 있어야 해요.

대신 쓸 수 있는 건 뭐가 있나요?

같은 카테고리에는: MCP YouTube Transcript, Google Analytics MCP, BibiGPT YouTube Video Summarizer

대안

같은 카테고리에서 다른 제작자가 만든 서버예요. 스타 순으로 정렬했어요.

카드 보는 법:★ GitHub 스타i세 기둥: 리뷰 · 점검 · 사용 정도i업데이트 = 최신 버전을 레지스트리에 공개한 날i

MCP YouTube Transcript

제작자: jkawamoto

An MCP server retrieving transcripts of YouTube videos

내 컴퓨터에서 실행★ 495MIT10일 전 업데이트
설치

Google Analytics MCP

제작자: surendranb

GA4 MCP server for AI agents: schema discovery, server-side aggregation, analysis-ready defaults.

내 컴퓨터에서 실행★ 244MIT10일 전 업데이트
설치

AI video summarizer: summarize and transcribe YouTube, Bilibili, TikTok and podcast videos.

클라우드에서 실행★ 137MIT10일 전 업데이트
설치

제작자의 README

README 열기

제작자의 저장소에서 쓰인 그대로 가져왔어요. PopNx MCP가 검토하거나 보증한 내용이 아니에요. HTML, 이미지, 스크립트는 제거했어요. 링크를 누르면 이 사이트를 벗어나요.

upkeep-mcp

An MCP server for the recurring checks behind ongoing website maintenance: domains, SSL certificates, uptime, technical SEO and accessibility — all from publicly available information.

Built for people who look after a portfolio of client sites on a retainer, not just a single domain. The goal is to answer one question quickly: what needs attention this week?

Status

Early development, built in public phase by phase. Everything that needs no browser is implemented and useful today.

ToolPurposeStatus
domain_checkRegistration expiry, registrar, nameserver agreement, DNS records, DNSSECAvailable
ssl_checkCertificate expiry, issuer, chain validity, SAN coverage, TLS versionAvailable
uptime_checkHTTP status, response time, redirect chain, HTTPS upgrade, security headersAvailable
healthServer name, version, Node.js version, uptimeAvailable
seo_auditTitle, meta, headings, canonical, robots.txt, sitemap, broken linksAvailable
site_crawlDuplicate titles, broken links and stray noindex across a whole siteAvailable
portfolio_reportAll of the above across a portfolio, sorted by urgencyAvailable
accessibility_auditWCAG violations via axe-core, in a real browserAvailable

It also exposes the portfolio://sites resource (the site list, for a client to read without spending a tool call) and the quarterly_report prompt (turns a portfolio run into the report a client actually reads).

Published on npm, so it installs with one command — see Installation. A public instance is also running, for anyone who would rather point a client at a URL than run anything — see The hosted instance.

What it looks like

> Is example.com about to expire?

example.com expires 2027-08-13 (346 days). Registrar: RESERVED-Internet Assigned Numbers Authority. Nameservers: elliott.ns.cloudflare.com, hera.ns.cloudflare.com. Resolves: apex yes, www yes. DNSSEC: delegation signed.

Check the certificate on expired.badssl.com

expired.badssl.com:443 certificate expires 2015-04-12 (-4159 days). Issued by COMODO RSA Domain Validation Secure Server CA. Chain does not verify (CERT_HAS_EXPIRED). Negotiated TLSv1.2. Host matched via *.badssl.com. Revocation not established: http://ocsp.comodoca.com could not answer: the responder is not authorised to answer for this certificate.

Needs attention:

  • [critical] The certificate expired 4159 days ago.
  • [critical] The certificate chain does not verify: CERT_HAS_EXPIRED.

Check the certificate on revoked.grc.com

revoked.grc.com:443 certificate expires 2026-10-18 (42 days). Issued by Certera RSA DV SSL CA 2. Chain verifies. Negotiated TLSv1.2. Host matched via revoked.grc.com. Revoked on 2025-09-18.

Needs attention:

  • [critical] The certificate was revoked on 2025-09-18; browsers that check revocation will refuse the site.

Note what the second one does: the chain verifies. Node performs no revocation lookup of its own, so that certificate completes a handshake and reports as trusted. Only asking its issuer finds the problem.

Every tool also returns structured data alongside the text, so results can be sorted, filtered and fed into a report. Full input and output for each tool is in examples/, and a whole portfolio session — the weekly triage, a drill-down, and what the comparison against the previous run will and will not claim — is in examples/conversation.md.

The tools

domain_check

Input: domain — a bare domain, a full URL, or an internationalised name. A subdomain is reduced to its registrable domain, since that is what a registration belongs to.

Returns the expiry date and days remaining, the registrar and its IANA ID, registry statuses, A/AAAA/NS/MX/TXT/CAA records, whether the apex and www resolve, whether the delegation is signed with DNSSEC, and what the domain's SPF and DMARC records say about who may send email as it.

Email authentication is read from the domain's own DNS — the SPF record at the apex, the DMARC record at _dmarc. A record that is absent is reported as information, because it is a standing improvement rather than something that broke this week. A record that is present and wrong is a warning, because it fails right now: two SPF records make receivers skip SPF entirely, and +all authorises the whole internet to send as the domain.

DKIM is deliberately not reported. A DKIM key lives at ._domainkey, and a selector cannot be discovered — only guessed, one DNS query per guess. That is subdomain enumeration, which this project does not do, so a domain with no DKIM and one whose selector was not guessed are left indistinguishable rather than the second being reported as the first.

Each of the domain's own nameservers is then asked about the zone directly, over TCP port 53 with recursion off, which is the one question a recursive resolver cannot answer: it replies with whatever one server told it and does not say which. That finds a server left in the delegation after a migration — it answers REFUSED, or its own hostname stopped resolving, and every resolver query landing there is slow or fails — and it finds nameservers holding different versions of the zone, which is the "it works for me but not for my colleague" outage.

What is a fault and what is only unestablished are graded apart. Resolvers ask over UDP first and this server can only use TCP, so a nameserver that refuses TCP is not a broken one: sapo.pt's four all refuse it and the domain resolves perfectly. Different serials are info too — github.com runs two providers that do not transfer between them, so four of its nameservers report 1656468023 and four report 1, and nothing is wrong. A hostname that does not resolve, or an answer without authority for the zone, is broken for everybody and is a warning. Pass checkNameservers: false to skip the whole thing — portfolio_report does, because a portfolio would pay this per site and a deployment that cannot open port 53 would grade every site at once as unestablished. docs/adr/0020 records why it speaks DNS by hand and what it deliberately does not check.

ssl_check

Input: domain, optional port (443 by default).

Returns expiry and days remaining, issuer, whether the chain verifies and why not when it does not, which hostnames the certificate covers and via which SAN entry, the negotiated TLS version and cipher, and whether the certificate has been revoked. Expired, self-signed and untrusted certificates are inspected and reported rather than refused — those are the ones worth finding.

Revocation is checked over OCSP. The response a server staples to the handshake is preferred, because it costs no request at all; when there is none, the responder named in the certificate is asked directly. An answer is only believed once its signature verifies against the issuing authority, and only once its CertID is shown to be about the certificate that was actually served — a server serving a revoked certificate alongside a valid response for a different one is otherwise the easy way to fake a clean result.

Many healthy certificates cannot be checked at all: since 2025 the two largest issuers, Let's Encrypt and Google Trust Services, publish no OCSP responder and distribute revocation by CRL. That is reported as an unavailableReason and produces no finding, because it is a decision of the certificate authority and nothing the site owner can act on. A responder that was asked and would not answer is different, and gets one unknown.

uptime_check

Input: url — a full URL, or a bare domain, which is tried over HTTPS.

Returns the status code, response time, every hop of the redirect chain, whether plain HTTP is upgraded to HTTPS, the HSTS policy, and the security headers worth reporting on.

seo_audit

Input: url — the page to audit, plus optional checkLinks (true by default) and maxLinks (25 by default).

Returns title and meta description with their lengths, the heading structure, canonical, lang, viewport, Open Graph, hreflang alternates, the images with no alt attribute, the state of robots.txt and the sitemap, and which internal links are broken.

A gzipped sitemap is unpacked before it is read. Whether it is gzipped is decided by the first two bytes rather than by the file name or the content type, because plenty of files called .xml.gz are not, and plenty that are get labelled text/xml.

The sitemap is then checked against the rules of the protocol, because a file that answers 200 and parses is not the same as a file that works: a root element with no sitemaps.org namespace is dropped whole, an entry on another host is discarded, and one unescaped & makes the document ill-formed XML and costs every entry after it. Each broken rule is reported once with the number of entries that break it and one example, so a mistake repeated across fifty thousand URLs reads as one thing to fix. A rule that only costs a hint — a that is not a W3C Datetime, a outside its seven values — is graded info; one that costs the entry or the file is a warning.

robots.txt is read before anything else is requested and is obeyed — for the page itself and for every internal link. A page this crawler is not allowed to read is reported as such and is never fetched, and an unreadable robots.txt is treated as forbidding everything, as RFC 9309 requires.

> Audit the homepage of example.com

https://example.com/ answered 200. Title: "Example Domain". 1 h1, 0 images without alt, 0 internal links (0 checked, 0 broken). Sitemap: the sitemap URL answered 404.

Needs attention:

  • [warning] The page has no meta description, so search engines will write their own summary of it.
  • [info] The page declares no canonical URL, which is how duplicate addresses for the same page get separated.
  • [info] The page has no og:title or no og:image, so it will share poorly on social networks and in messaging apps.
  • [info] There is no sitemap at https://example.com/sitemap.xml: the sitemap URL answered 404.
  • [info] The site publishes no robots.txt. Nothing is blocked, but the sitemap cannot be declared there either.
site_crawl

Input: url — the page to start from — plus optional maxPages (25 by default, 100 at most) and maxDepth (3 by default).

Walks the site breadth-first from that page and reports what one page cannot tell you about itself: which pages share a title, and therefore compete with each other for the same search result; which share a meta description; which internal links are broken and, crucially, which page links to them; which pages still ask not to be indexed after a rebuild; and how much of the site was reachable at all.

It stays on the origin you start it on — https://example.com and https://www.example.com are different origins, and a crawl that wandered between them would report one site's pages as duplicates of the other's. A link that redirects off the site is counted and left alone: robots.txt was read for this origin and does not speak for anybody else.

Three budgets bound it: pages, depth, and a two-minute deadline. Whichever one ended the crawl is reported along with how many URLs were found and not visited, because a report that does not say it saw a quarter of the site is worse than no report. robots.txt is read first and obeyed

앞부분만 보여 드려요. 나머지는 저장소에서 읽어 보세요

PopNx에게 묻기