추천 목록의 단골 MCP 서버 10개 중 5개는 이미 보관 처리됐다, 대체는 이렇다

하루 평균 1만 9,600건. 2026년 9월 28일부터 10월 25일(UTC) 사이 npm이 집계한 21일을 평균 내면, 보관 처리되어 수정이 끝난 @modelcontextprotocol/server-postgres 패키지가 이만큼 내려받아졌습니다. 같은 기간 현역 참조 서버인 순차적 사고(2만 5,699건), 공식 저장소 밖에서 활발히 관리되는 Firecrawl(2만 4,719건)과 같은 자릿수입니다. “로컬 AI에 붙일 MCP 서버 10선”에 단골로 나오는 이름 열 개 가운데 다섯이 이런 처지라서, 이 글은 열 개를 한 장의 지도에 올려 놓고 칸마다 무엇을 해야 하는지 짚습니다. 수치와 버전은 모두 2026-10-27(UTC)에 다시 열어 본 값입니다.

열 개를 칸마다 칠해 보면

추천 글에 되풀이해서 오르는 이름은 파일 시스템, Git, Fetch(웹 가져오기), 순차적 사고, SQLite, PostgreSQL, GitHub, Brave 검색, Puppeteer, 그리고 웹 수집 서비스 Firecrawl입니다. 아래 격자는 이 열 개를 공식 저장소 README와 npm·PyPI 정보에 대조해 칠한 것입니다. 초록은 지금 공식 저장소가 관리하는 서버, 파랑은 공식 저장소 밖에서 따로 관리되는 프로젝트, 빨강은 보관된 서버입니다.

그림 1. 위 다섯은 그대로 쓰는 칸, 아래 다섯은 갈아탈 칸. 보관 칸 다섯 중 네 개에는 npm 폐기 표시가 붙어 있다

위쪽 다섯은 릴리스가 최근까지 이어지고 있어서 손댈 것이 없습니다. 아래 다섯이 문제입니다. GitHub·Brave·Puppeteer·PostgreSQL은 npm 패키지에 “더 이상 지원하지 않음”이라는 deprecated 표시가 붙었고, PostgreSQL과 SQLite에서는 SQL 인젝션 결함이 보고됐으며, SQLite는 후속을 가리키는 안내조차 없습니다. 후속이 있는 서버도 이름만 바꿔 끼우면 되는 것은 아닙니다. 마지막 절에서 갈아탈 때 달라지는 점을 하나씩 다룹니다.

보관이 무슨 뜻인지부터 정리합니다. 보관된 서버들이 모여 있는 modelcontextprotocol/servers-archived는 소유자가 2025년 5월 29일 보관 처리해 읽기 전용이 되었고, 마지막 푸시는 그 전날인 5월 28일입니다(별 306개). README 맨 위에는 이 저장소가 더 이상 관리되지 않으며 보안 업데이트도 버그 수정도 나오지 않고 보안 보증도 없다는 안내가 있습니다. 현역 저장소인 modelcontextprotocol/servers(별 9만 1,591개)에 남은 참조 서버는 Everything, Fetch, Filesystem, Git, Memory, Sequential Thinking, Time 일곱 개이고, README의 보관 목록은 13개입니다. 이 글의 다섯 외에 AWS KB 검색, EverArt, GitLab, Google Drive, Google Maps, Redis, Sentry, Slack이 들어 있습니다. 목록에서 눈여겨볼 두 줄이 있습니다. Brave 검색에는 공식 서버로 대체되었다는 말이, Slack에는 Zencoder가 이어서 관리한다는 말이 붙어 있습니다. 보관 저장소 쪽 목록에는 Git도 적혀 있지만, 현역 저장소 README는 Git을 지금도 관리하는 참조 서버로 두고 PyPI의 mcp-server-git도 2026.10.19 릴리스까지 이어지고 있습니다.

npm에서는 표시가 이렇게 보입니다. 네 패키지의 최신 버전에 “Package no longer supported”라는 deprecated 문구가 붙어 있습니다. 표시가 붙었다고 설치가 막히지는 않아서, npx -y로 실행하면 그대로 받아서 돌아갑니다.

데모 서버 묶음이 추천 목록의 뼈대가 된 길

이 서버들은 처음부터 “써 보라고 만든 제품”이 아니었습니다. MCP는 2024년 11월 25일 Anthropic이 규격과 SDK를 공개하면서 시작되었고, 그때 같이 나온 서버 묶음이 servers 저장소입니다. 파일·Git·Postgres·GitHub·Slack·Google Drive·Puppeteer처럼 누구나 붙이고 싶은 연동이 한곳에 모여 있으니, 추천 글과 영상이 이 저장소의 이름을 그대로 따 왔습니다. 설정 예제는 npx -y 패키지명 한 줄이어서 복사하기 쉽고, 복사된 줄을 나중에 다시 열어 보는 사람은 드뭅니다.

README는 지금도 맨 위에서 선을 긋습니다. 이 서버들은 MCP 기능과 SDK 사용법을 보여 주는 교육용 참조 구현이고 프로덕션용 솔루션이 아니며, 쓰는 쪽이 자기 위협 모델에 맞는 안전장치를 더해야 한다는 내용입니다. 서버 목록을 찾는다면 이 저장소가 아니라 MCP 레지스트리를 보라는 안내가 따로 붙어 있습니다.

보관 날짜를 마지막 릴리스와 나란히 놓으면 하나 더 보입니다. 보관 딱지는 이미 멈춰 있던 개발을 뒤늦게 적은 것에 가깝습니다.

패키지	마지막 릴리스	보관(2025-05-29)까지
PostgreSQL server-postgres 0.6.2	2024-12-04	176일
Brave 검색 server-brave-search 0.6.2	2024-12-04	176일
GitHub server-github 2025.4.8	2025-04-08	51일
SQLite mcp-server-sqlite 2025.4.25	2025-04-25	34일
Puppeteer server-puppeteer 2025.5.12	2025-05-12	17일

일수는 편집부 계산입니다. 보관 시점에 이미 반년 가까이 고쳐지지 않은 서버도 있었다는 뜻이고, 추천 글이 처음 쓰였을 때와 지금의 코드는 같지 않습니다.

보관 딱지가 붙어도 하루 2만 번 내려받는다

보관된 패키지가 실제로 얼마나 쓰이는지는 npm 내려받기 집계로 봅니다. 한 가지 주의가 필요합니다. npm의 주간 합계 호출은 일별 집계가 비어 있는 날(0건)을 그대로 합산해서 값이 들쭉날쭉합니다. 그래서 집계가 들어 있는 21일(2026-09-28~10-25)만 골라 하루 평균을 냈습니다. 내려받기 수에는 자동 빌드와 미러링이 섞여 있어 사람 수와 같지 않습니다. 다만 목록을 따라 만든 설정이 지금도 많이 돌아다닌다는 신호로는 충분합니다.

그림 2. 하루 평균 내려받기(편집부 계산). 빨강은 보관된 패키지

막대에서 먼저 눈에 들어오는 것은 파일 시스템 서버(9만 6,225건)의 압도적인 길이입니다. 그 아래에서 보관된 PostgreSQL(1만 9,611건)과 GitHub(1만 8,404건)가 현역 순차적 사고(2만 5,699건), Firecrawl(2만 4,719건)의 70%대에 걸쳐 있습니다. Brave 검색에서는 보관된 옛 패키지(3,974건)와 후속 패키지(3,929건)가 거의 같은 높이입니다. 옛 이름이 후속과 같은 수만큼 쓰이고 있다는 뜻입니다.

시간에 따른 변화도 확인했습니다. 보관된 지 1년이 지난 뒤에도 사용량은 줄지 않았습니다.

패키지	2026-06-01~28 하루 평균	2026-09-28~10-25 하루 평균
server-postgres	14,466건	19,611건
server-github	21,069건	18,404건
server-brave-search	3,965건	3,974건
server-puppeteer	4,452건	4,280건

두 기간 모두 집계가 있는 날만 평균했습니다(편집부 계산). PostgreSQL은 오히려 늘었습니다. Datadog Security Labs가 2025년 8월 글에서 적은 이 패키지의 주간 내려받기는 약 2만 건이었으니, 주 2만 건을 하루로 나누면 약 2,900건이니, 지금의 하루 평균은 그 일곱 배에 가깝습니다(편집부 계산). 목록은 계속 복사되고, 복사된 설정은 계속 실행됩니다.

보관된 코드에 남은 구멍, SQLite와 PostgreSQL

“어차피 로컬 실험인데”라는 생각에 제동을 거는 사례가 두 건 있습니다. 둘 다 보관된 서버에서 나왔고, 둘 다 보안 업체가 공개 분석을 냈습니다.

SQLite 참조 서버는 사용자 입력을 SQL 문장에 그대로 이어 붙여 파이썬 sqlite3 드라이버로 실행하는 전형적인 SQL 인젝션 결함을 가졌습니다. Trend Micro가 2025년 6월 11일 Anthropic에 알렸고, 돌아온 답은 이 저장소가 보관된 데모라 범위 밖이고 패치 계획이 없다는 것이었습니다(GitHub 이슈 #1348). 보안 업체가 더 걱정한 것은 그다음입니다. 공격자가 질의를 닫고 “열림” 상태의 가짜 지원 티켓을 DB에 심으면, 나중에 티켓을 분류하던 AI 에이전트가 그 안의 지시를 정상 업무로 읽고 따릅니다. 업체의 시연에서는 에이전트가 메일 도구로 고객 데이터를 공격자 주소에 보냈습니다. DB에 쓰인 글자가 훗날 에이전트의 명령이 되는 저장형 프롬프트 인젝션입니다. 보관 전에 이 코드가 5,000회 넘게 포크·복사되었다는 점도 업체가 짚었습니다. 고쳐지지 않은 코드가 그만큼 퍼졌다는 뜻입니다.

PostgreSQL 서버의 사정은 Datadog Security Labs의 분석에 상세히 나옵니다. 이 서버는 사용자가 보낸 SQL을 읽기 전용 트랜잭션으로 감싸 실행해서 쓰기를 막는다고 내세웠습니다. 그런데 DB 드라이버는 세미콜론으로 이은 여러 문장을 한 번에 받습니다. 트랜잭션을 중간에 끝내는 문장을 앞에 붙이면 그 뒤 문장은 보호 없이 일반 쓰기로 실행될 수 있었습니다. 연결 풀을 호출 사이에 공유해 한 호출의 세션 설정이 다음 호출에 번지는 문제도 함께 지적됐습니다. 경과는 이렇습니다. 2024년 11월 27일 한 보안 연구자가 HackerOne으로 먼저 제보했고, 2025년 4월 1일 Datadog 엔지니어가 패치를 담은 보고서를 냈습니다. Zed Industries는 자기 포크(@zeddotdev/postgres-context-server)를 4월 9일 v0.1.4로 고쳤습니다. Anthropic은 5월 29일 저장소에는 수정을 넣었지만, Datadog 글의 시점에 npm 0.6.2와 Docker 이미지는 그대로였고 수정은 릴리스되지 않은 버전에만 있었습니다. 지금 npm의 최신 버전은 여전히 0.6.2입니다.

“읽기 전용”을 서버가 말할 때와 DB가 말할 때

PostgreSQL 사례에서 배울 것은 결함 하나보다 두 문장의 차이입니다. “서버가 읽기 전용이라고 한다”와 “DB가 읽기만 허용한다”는 같은 말이 아닙니다. 앞쪽은 서버 코드가 지키겠다는 약속이고, 뒤쪽은 DB 계정의 권한이 강제하는 사실입니다. 약속은 코드에 틈이 있으면 깨지고, 강제는 서버가 뚫려도 남습니다.

그림 3. 같은 질의가 계정 권한에 따라 다른 결말을 맞는다. 노란 영역은 약속, 초록 영역은 강제

그림에서 질의는 에이전트에서 서버, 드라이버를 거쳐 DB에 닿습니다. 노란 영역 안에서는 서버가 읽기 전용 트랜잭션으로 감싸든 말든 우회로가 생길 수 있습니다. 결말은 초록 영역, 곧 DB가 이 접속에 어떤 권한을 줬는가로 갈립니다. 소유자 권한 계정이면 쓰기가 실행되고, SELECT만 준 계정이면 같은 문장이 권한 오류로 끝납니다. 그래서 DB를 MCP 서버에 연결할 때는 서버를 고르기 전에 계정부터 만듭니다. PostgreSQL이라면 이런 모양입니다.

-- 읽기 전용 계정: 이름·스키마는 내 환경에 맞게 바꾼다
CREATE ROLE mcp_reader LOGIN PASSWORD '<비밀번호 관리 도구에서 발급>';
GRANT CONNECT ON DATABASE appdb TO mcp_reader;
GRANT USAGE ON SCHEMA public TO mcp_reader;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO mcp_reader;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO mcp_reader;

같은 원리가 다른 서버에도 적용됩니다. 파일 시스템 서버를 Docker로 띄운다면 바인드 마운트 끝에 ro를 붙여 운영체제가 쓰기를 막게 합니다. GitHub는 서버 옵션의 읽기 전용 모드와 별개로, 토큰 자체의 권한을 좁혀 서비스가 강제하게 합니다. 서버 옵션은 겹겹이 쌓을 수 있는 방어 가운데 한 겹이고, 가장 믿을 층은 서버 코드와 상관없이 운영체제·DB·서비스가 막는 층입니다.

현역 네 서버가 손대는 범위

지금도 관리되는 참조 서버 네 개는 이름만 비슷하고 성격이 많이 다릅니다. 도구 목록을 열어 보면 이 서버를 켠다는 것이 AI에게 무엇을 허락하는 일인지 보입니다.

파일 시스템은 AI가 열어 볼 수 있는 폴더를 시작할 때 명령줄 인자로 지정합니다. README는 이 방식이 모든 프로토콜 버전에서 동작하는 유일한 방법이라고 설명합니다. 클라이언트가 실행 중에 폴더를 바꿔 주는 Roots 방식은 프로토콜 2026-07-28 버전에서 폐기 예정으로 표시되었고, 이 버전의 연결에서는 아예 쓸 수 없습니다. 도구마다 힌트가 붙어 있어서, 아홉 개 읽기 도구는 순수한 읽기로, write_file·edit_file·move_file은 파괴적(destructive) 도구로 표시됩니다. 실제 동작을 보면 write_file은 있는 파일을 그대로 덮어쓰고, move_file은 목적지에 파일이 있으면 실패하며, edit_file은 dryRun으로 바뀔 내용을 미리 보여 줍니다. 실행에는 Node.js 24 이상이 필요합니다.

Git은 “마지막 두 커밋 사이에 무엇이 바뀌었나”처럼 이력을 묻는 데 어울립니다. Python 패키지라 uvx mcp-server-git --repository <경로>로 실행합니다. 놓치기 쉬운 점은 --repository가 작업 트리 안의 어떤 경로든 받아서 저장소 루트로 해석한다는 것입니다. 하위 폴더 하나만 열어 줄 생각으로 지정해도 저장소 전체가 대상이 됩니다. 이 옵션을 아예 빼면 호출마다 repo_path를 받는 방식으로 돌아갑니다. 커밋·리셋·체크아웃 도구도 켜져 있으니, 이력 조회만 필요한데 에이전트가 브랜치를 바꾸는 일은 승인 단계에서 막아야 합니다.

Fetch는 기본값이 안전하게 잡혀 있습니다. 루프백·사설·링크 로컬·클라우드 메타데이터 주소(169.254.169.254)처럼 공개되지 않은 주소로 풀리는 호스트를 거부하고, 리다이렉트를 따라갈 때마다 같은 검사를 다시 하며, 모델이 요청한 가져오기에는 robots.txt를 따릅니다. 한계도 README에 적혀 있습니다. 주소를 검사한 뒤 연결하기 전 사이에 DNS 응답을 바꾸는 DNS 리바인딩은 막지 못하고, 프록시만 풀 수 있는 호스트 이름은 검사하지 못합니다. 개발 서버나 사내 페이지를 읽히려면 --allow-private-ips를 직접 켜야 하는데, README가 보안 위험을 직접 경고하는 옵션이니 필요할 때만 켭니다.

순차적 사고는 외부 시스템에 닿지 않아서 권한 걱정이 가장 적습니다. 모델이 thought(이번 단계의 생각), thoughtNumber, totalThoughts, nextThoughtNeeded를 채워 호출하고, 앞 단계를 다시 쓸 때는 isRevision과 revisesThought, 갈래를 칠 때는 branchFromThought를 씁니다. 원인이 여럿인 디버깅에서 첫 가설에 바로 매달리지 않게 하는 용도입니다. 생각 기록이 로그에 남는 것이 싫다면 환경 변수 DISABLE_THOUGHT_LOGGING을 true로 둡니다.

세 서버를 함께 붙인 설정은 이렇게 생겼습니다. 경로만 내 프로젝트로 바꿉니다.

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/me/project"]
    },
    "git": {
      "command": "uvx",
      "args": ["mcp-server-git", "--repository", "/Users/me/project"]
    },
    "fetch": {
      "command": "uvx",
      "args": ["mcp-server-fetch"]
    }
  }
}

Claude Code를 쓴다면 같은 서버를 명령 한 줄로 등록합니다. -- 뒤는 서버 실행 명령이 그대로 전달되고, 등록 뒤에는 /mcp로 연결 상태를 확인합니다.

claude mcp add --transport stdio git -- uvx mcp-server-git --repository /Users/me/project
claude mcp list

Firecrawl: 서버 앞에 서비스가 서 있는 경우

열 개 가운데 Firecrawl만 성격이 다릅니다. 공식 저장소의 참조 서버가 아니라, 같은 이름의 업체가 firecrawl/firecrawl-mcp-server(MIT, 별 약 7,700개)로 따로 관리하는 서버이고, 업데이트도 활발합니다(저장소 푸시 10월 26일, npm firecrawl-mcp 3.34.1). 앞의 네 서버가 내 컴퓨터 안의 파일·이력을 다룬다면, 이 서버는 외부 서비스로 가는 문입니다.

전체 프로필 기준 도구가 27개에 이릅니다. 한 장짜리 페이지 긁기(scrape), 사이트 주소 지도 만들기(map), 검색(search), 여러 페이지 순회(crawl), PDF 같은 문서 해석(parse), 클릭과 입력이 필요한 페이지 조작(interact), 변경 감시(monitor), 크레딧 사용량 조회(credit_usage)가 들어 있습니다. 슬롯이 부족한 클라이언트를 위한 줄임판도 있습니다. 키 없이 쓰는 호스팅 엔드포인트는 scrape·search·parse 세 개만 열려 있고 속도 제한이 걸리며, crawl·map·agent는 API 키(FIRECRAWL_API_KEY)가 있어야 합니다. 자체 호스팅은 FIRECRAWL_API_URL로 내 인스턴스를 가리키면 됩니다.

고르는 기준은 단순합니다. 주소를 아는 페이지 하나를 읽는다면 키도 비용도 없는 Fetch로 충분합니다. 여러 페이지를 돌아야 하거나, 클릭·입력이 필요한 페이지, PDF를 읽어야 한다면 Firecrawl을 고려합니다. 클라우드 쪽은 호출마다 크레딧이 쓰이고, 읽을 페이지 주소가 외부 서비스로 나간다는 점을 감안합니다. 문서가 당부하는 것은 하나입니다. 키를 서버 주소나 채팅 창에 적지 말고 클라이언트 설정이나 비밀 관리 도구에 두라는 것입니다.

내 설정에 보관된 이름이 남았는지 찾기

이미 목록을 따라 설정했다면 내 환경에 보관된 패키지가 들어 있는지부터 읽기 전용 명령으로 찾습니다. 아래 명령은 파일을 바꾸지 않습니다.

# Claude Code: 등록된 서버 이름과 상태
claude mcp list

# 설정 파일에서 보관된 패키지 이름 찾기 (경로는 쓰는 앱에 맞게)
grep -rnE "server-(github|postgres|puppeteer|brave-search)|mcp-server-sqlite" \
  .mcp.json ~/.claude.json "$HOME/Library/Application Support/Claude/claude_desktop_config.json" 2>/dev/null

# 패키지에 deprecated 표시가 있는지 npm에 물어보기
npm view @modelcontextprotocol/server-github deprecated

npm view 명령은 표시가 있으면 문구를 돌려주고, 현역 패키지(예: server-filesystem)에는 아무것도 출력하지 않습니다. 팀 저장소의 .mcp.json도 같은 방법으로 훑습니다. Claude Code에서 --scope project로 추가한 서버는 이 파일에 저장되어 팀과 공유하려고 커밋되므로, 보관된 패키지가 한 번 들어가면 팀원 모두의 환경에 퍼집니다. 토큰이 그 파일에 평문으로 들어가 있지 않은지도 같이 봅니다.

찾았다면 서버 하나씩 아래 순서로 옮깁니다. 한꺼번에 바꾸면 무엇이 달라졌는지 알기 어렵습니다.

1. 설정을 백업합니다. 설정 파일을 복사해 두고, 그 서버에 쓰던 토큰·키가 무엇인지 적어 둡니다.
2. 후속 서버를 읽기 전용으로 먼저 붙입니다. GitHub은 /readonly 주소, DB는 SELECT 전용 계정, 브라우저는 --isolated로 시작합니다.
3. 옛 서버와 같은 질문을 던져 봅니다. 이슈 목록 보기, 테이블 구조 보기처럼 읽기 작업이 같은 결과를 내는지 비교합니다.
4. 옛 서버를 제거합니다. Claude Code에서는 claude mcp remove <이름>으로 지웁니다.
5. 쓰던 토큰을 폐기하고 새로 발급합니다. 새 서버용 토큰은 권한 범위를 줄여 만듭니다.

후속 서버 다섯, 갈아탈 곳

보관된 다섯 가운데 후속의 모양이 가장 뚜렷한 것부터 차례로 봅니다. 기능이 같다고 가정하고 이름만 바꾸면 안 되는 이유가 서버마다 다릅니다.

GitHub: 공식 서버, 툴셋 단위로 켜고 끈다

이슈·풀 리퀘스트·커밋·Actions 실행 기록은 이제 GitHub이 직접 만드는 github/github-mcp-server(MIT, 별 약 3만 4,000개, 10월 23일 푸시)가 맡습니다. 옛 서버가 도구 26개를 한꺼번에 내놓고 개인 액세스 토큰(PAT)에 repo 권한을 요구한 것과 달리, 새 서버는 도구를 툴셋 단위로 켜고 끕니다. 기본은 컨텍스트·저장소·이슈·풀 리퀘스트·사용자 다섯 묶음입니다.

가장 쉬운 시작점은 GitHub이 호스팅하는 원격 서버 https://api.githubcopilot.com/mcp/입니다. 주소 끝에 /readonly를 붙이면 쓰기 도구가 빠진 읽기 전용 서버가 되고(헤더 X-MCP-Readonly로도 가능), /x/issues처럼 특정 툴셋만 열 수도 있습니다. 로컬 서버는 --read-only와 --toolsets 옵션으로 같은 일을 하고, 읽기 전용 모드에서는 도구를 직접 지정해도 쓰기 도구가 꺼집니다. 로컬 서버는 첫 실행 때 브라우저로 로그인하는 OAuth 방식을 지원하고 토큰은 메모리에만 둡니다. PAT를 쓰려면 환경 변수 GITHUB_PERSONAL_ACCESS_TOKEN을 설정하며, 이쪽이 우선합니다. README가 예로 드는 최소 권한은 repo, read:packages, read:org이고, 일에 필요하지 않으면 더 줄입니다.

공개 저장소의 이슈·댓글에 숨은 지시가 걱정된다면 락다운 모드(--lockdown-mode)가 있습니다. 푸시 권한이 있는 사용자의 내용만 보이게 거르는 필터인데, 문서가 “최선을 다하는 필터이고 권한 경계가 아니다”라고 못박았습니다. 같은 자격 증명으로 다른 도구나 API를 통하면 가려진 내용에 닿을 수 있습니다.

claude mcp add --transport http github https://api.githubcopilot.com/mcp/readonly \
  --header "Authorization: Bearer <읽기 위주로 좁힌 토큰>"

Brave 검색: 이름만 바뀐 공식 서버, 기본 전송이 달라졌다

현역 저장소 README가 직접 후속을 지목합니다. Brave가 만든 brave/brave-search-mcp-server(MIT, npm 2.1.4)입니다. 2.x부터 기본 전송 방식이 STDIO이고, 웹·지역·이미지·영상·뉴스 검색과 요약, 장소 검색, AI 근거용 본문 추출까지 도구 8개를 제공합니다. Brave Search API 키(BRAVE_API_KEY)가 필요하고, 지역 검색의 전체 기능은 Pro 플랜에서만 됩니다. 이미지 검색은 1.x와 달리 base64 이미지 데이터를 돌려주지 않아 응답이 가볍습니다. HTTP로 띄우는 모드는 인증이 없어서 기본이 루프백 주소(127.0.0.1)이고, 전체 네트워크에 열려면 BRAVE_MCP_HOST를 직접 바꿔야 합니다. 열더라도 신뢰하는 네트워크에서만 엽니다.

Puppeteer: 후속이 둘, 용도로 갈린다

옛 서버는 도구 7개(이동·스크린샷·클릭·호버·입력·선택·스크립트 실행)로 브라우저를 조종했고, 로컬 파일과 내부 주소에도 닿을 수 있다는 경고가 붙어 있었습니다. 화면을 조작시키는 후속으로는 Microsoft의 microsoft/playwright-mcp(Apache-2.0, 별 약 3만 8,700개)가 가장 널리 쓰입니다. 화면 이미지가 아니라 접근성 트리(구조화된 페이지 정보)를 읽어서 비전 모델이 필요 없고, --headless, --isolated(프로필을 메모리에만 보관), --allowed-origins 같은 옵션이 있습니다. 같은 README가 Playwright MCP는 보안 경계가 아니라고 밝히며, 오리진 목록은 리다이렉트에 영향이 없다고 적었으니 방어선으로 믿으면 안 됩니다. 코딩 에이전트에는 MCP보다 CLI에 스킬을 붙이는 쪽이 토큰을 아낀다고 권하는 대목도 같은 README에 있습니다. 반면 상태를 유지하며 여러 번 시도하는 탐색형 작업에는 MCP가 어울린다고 합니다.

성능·콘솔 점검이 목적이라면 Chrome DevTools MCP(Apache-2.0, 별 약 5만 4,200개)가 맞습니다. 이 블로그의 Chrome DevTools MCP 소개 글에 따로 정리했습니다.

PostgreSQL: 지정된 후속은 없고, 커뮤니티 서버가 채운다

README는 대체 서버를 지정하지 않았습니다. 커뮤니티 서버 가운데 crystaldba/postgres-mcp(Postgres MCP Pro, MIT, 별 약 3,400개)는 옛 서버(질의 도구 하나와 테이블 스키마 리소스)보다 훨씬 넓습니다. 스키마 탐색, 실행 계획, 느린 쿼리 목록, 인덱스 추천, 상태 점검까지 도구 9개를 줍니다. 접근 모드는 개발용 무제한(Unrestricted)과 운영용 제한(Restricted)이 있고, 제한 모드는 읽기 전용 트랜잭션에 실행 시간 제한을 겁니다. 앞 절에서 본 것처럼 그것도 서버 쪽 한 겹일 뿐이니 SELECT 전용 계정을 함께 씁니다. 인덱스 추천은 DB에 pg_stat_statements와 hypopg 확장이 있어야 동작합니다. 마지막 푸시가 8월 17일이라 앞의 두 후속처럼 매주 움직이는 저장소는 아니라는 점도 고를 때 참고합니다.

SQLite: 후속을 가리키는 안내가 없다

PyPI의 mcp-server-sqlite 마지막 릴리스는 2025년 4월 25일이고 보관된 상태입니다. 도구 6개(읽기 쿼리, 쓰기 쿼리, 테이블 만들기, 목록, 구조 보기, 인사이트 메모)를 가졌지만 README에는 대체 서버가 적혀 있지 않습니다. 새로 시작한다면 보관된 서버가 아니라 활발히 관리되는 다른 SQLite 서버를 고르고, 연결할 DB는 원본이 아닌 사본으로 시작합니다. 앞서 본 저장형 프롬프트 인젝션 시나리오는 DB 안의 글자를 에이전트가 읽는 순간 성립하니, 쓰기 권한이 필요한 작업이 아니라면 읽기 전용으로 여는 것이 기본입니다.

서버를 새로 찾을 때의 출발점은 MCP 레지스트리입니다. 공식 문서 기준으로 레지스트리는 아직 프리뷰이고, 서버 이름이 실제 GitHub 계정이나 도메인 소유자에게서 나왔는지를 검증하는 데 집중합니다. 코드의 보안 검사는 npm·PyPI·Docker Hub와 레지스트리를 가져다 쓰는 마켓이 맡는다고 적혀 있으니, 이름이 믿을 만한 곳에서 왔다는 사실이 코드가 안전하다는 뜻은 아닙니다. MCP 자체의 구조를 처음부터 훑고 싶다면 MCP 입문 글로 이어서 보면 됩니다.