Google Search Console MCP: 네 개의 SEO MCP 서버가 실제로 노출하는 것

Google Search Console MCP 서버는 CSV를 내보내지 않고도 에이전트가 검색 데이터를 읽게 하는 방법입니다. 여기까지는 쉽습니다. 어려운 것은 서버끼리 구별하는 일입니다. 모두 똑같은 방식으로 자신을 소개하고, 차이는 "실제로 무엇을 할 수 있는지" 물을 때에야 드러나기 때문입니다.

그래서 물었습니다. 2026년 9월 12일, 공개된 SEO MCP 서버 네 개를 연결하고 각각에 tools/list 요청을 보내 반환된 수를 세었습니다. 결과는 42, 21, 4, 1이었습니다.

이 격차는 품질 순위가 아닙니다. 설계상의 결정이며, 에이전트가 할 수 있는 일, 컨텍스트 비용, 그리고 얼마나 많은 데이터가 밖으로 나가는지를 바꿉니다.

무엇을 어떻게 검증했는가

방법: 각 서버는 자체 문서가 지시하는 방식 그대로 실행했습니다. 표준 입출력을 통하거나, 문서가 그 방식을 명시한 경우 HTTP를 통했습니다. MCP initialize 핸드셰이크를 보내고 이어서 tools/list를 보낸 뒤 도구 수와 이름을 기록했습니다. API 키는 키 없이는 서버가 시작을 거부한 경우를 제외하고 사용하지 않았습니다.

한 서버, 즉 서드파티 Search Console 패키지는 우리의 50초 대기 창 안에 핸드셰이크를 끝내지 못해 점수를 매기지 않고 제외했습니다. 도구 목록은 릴리스마다 바뀌므로 이 수치는 어느 날 아침의 스냅숏으로 다뤄야 하며, 어떤 벤더의 영구적인 속성이 아닙니다.

네 가지 설계와 각각의 용도

래퍼(21개 도구). mcp-gsc는 Search Console API를 받아 개별 보고서를 이름 붙은 도구로 감쌉니다. 목록은 검색 분석가의 직무기술서처럼 읽힙니다. search_analytics, inspect_url, top_movers, quick_wins, cannibalization, content_decay, device_country_breakdown, ctr_anomalies, weekly_seo_report, indexing_coverage. 장점은 모델이 쿼리를 구성할 필요가 전혀 없다는 것입니다. 대가는 보고서에 무엇이 들어가야 하는지에 대한 남의 생각을 물려받는다는 것, 그리고 목록 밖의 것은 아무것도 요청할 수 없다는 것입니다.

플랫폼 전체의 거울(42개 도구). Ahrefs 서버는 벤더의 제품 표면을 엔드포인트 단위로 그대로 노출합니다. rank-tracker-overview, rank-tracker-competitors-overview, keywords-explorer-matching-terms, keywords-explorer-volume-history, batch-analysis. 우리가 측정한 것 중 가장 기능이 많고 컨텍스트 면에서 가장 비쌉니다. 작업과 관련이 있든 없든 모든 도구 정의가 로드되기 때문입니다. 이는 트레이드오프를 가장 선명하게 보여줍니다. 능력의 폭과 맞바꿔 모든 프롬프트에 영구적인 세금이 붙습니다.

게이트웨이(4개 도구). DataForSEO의 v3 서버는 반대 방향으로 갔습니다. docs_index, docs_list_sections, docs_search, 그리고 범용 api_request 하나를 노출합니다. 모든 엔드포인트에 이름을 붙이는 대신, 모델이 문서를 찾고 그다음 인증된 호출을 하도록 가르칩니다. 도구 네 개로 수백 개 엔드포인트의 API를 덮고, 모델은 구체성의 비용을 로드 시점이 아니라 호출 시점에 치릅니다. 우리 검증에서 HTTP 엔드포인트는 자격 증명 없이 invalid auth를 반환했고 자격 증명과 함께 정상 응답했습니다. 바람직한 동작입니다.

단일 도구 서버(1개 도구). seo-mcp-server는 정확히 하나의 도구 ai_content_detect만 반환합니다. 작은 서버가 잘못된 것은 아니지만 그것이 무엇인지에는 솔직해야 합니다. 데모나 단일 점검이지 SEO 작업대가 아닙니다. 주간 보고를 기대하고 설치하면 설치 안내가 결코 언급하지 않은 방식으로 실망하게 됩니다.

네 가지 원형. 그중 둘은 실제 보고 워크플로로 확장되며, 서로 다른 방향으로 확장됩니다.

도구 수가 잘못된 헤드라인인 이유

같은 수를 가진 두 서버가 전혀 다르게 동작할 수 있습니다. 중요한 것은 경계의 모양이지 숫자가 아니기 때문입니다.

래퍼는 당신의 질문을 미리 정합니다. 기반 API가 까다롭고 래퍼가 실제 전문성을 담고 있을 때 이는 정말 유용합니다. mcp-gsc 목록이 그렇습니다. 그것이 한계가 되는 순간은 당신의 질문이 목록에 없는 첫 번째 순간이며, 우회할 방법이 없습니다.

게이트웨이는 거의 아무것도 정하지 않고 일을 모델에 밀어냅니다. 더 유연하고 더 취약합니다. 모델은 무엇이든 닿을 수 있습니다. 즉 잘못된 엔드포인트에 닿고, 응답 형태를 잘못 읽고, 원하던 필드가 다른 이름이라는 걸 알아내는 데 도구 호출 세 번을 쓸 수도 있습니다. 단순한 질문에서는 래퍼가 빠릅니다. 새로운 질문에서는 애초에 답하는 쪽이 게이트웨이뿐입니다.

실용적인 기준은 "도구가 몇 개인가"가 아니라 "매주 묻는 그 일을 서버가 노출하는가"입니다. 순위 추적 업무라면 보통 날짜와 기기 분할이 있는 검색 애널리틱스, 그리고 URL 검사입니다. 래퍼도 게이트웨이도 그것을 덮습니다. 42개 도구 서버는 그것을 덮고, 오늘 쓰지 않을 마흔 가지를 더 덮습니다.

무언가를 설치하기 전에 확인할 것

기능 목록이 아니라 권한 범위를 읽으십시오. Search Console 서버는 OAuth 부여가 허용하는 것을 그대로 물려받습니다. 속성을 나열하고 검색 애널리틱스를 가져올 수 있는 읽기 전용 부여는 보고와 모니터링에 충분합니다. 설정 변경, 사이트맵 제출, 색인 생성 요청을 제공하는 것은 당신의 속성에 쓰는 것이며, "저장소에 스타가 있다"보다 훨씬 높은 기준을 받을 자격이 있습니다.

당신의 기기에서 무엇이 나가는지 확인하십시오. API 자격 증명을 벤더로 전달하는 게이트웨이는 자신의 토큰으로 Google API와 직접 통신하는 로컬 래퍼와 위험 프로필이 다릅니다. 둘 다 괜찮을 수 있습니다. 다만 하나만이 제3자가 당신이 가져오는 모든 키워드를 본다는 뜻입니다.

빈 응답 테스트를 돌리십시오. 데이터가 없는 날짜 범위, 예컨대 아직 공개하지 않은 속성을 서버에 물으십시오. 잘 만든 서버는 빈 결과 집합을 반환합니다. 졸속으로 만든 서버는 오류를 반환하고, 오류를 받은 에이전트는 빠진 데이터에 대해 그럴듯한 설명을 지어내곤 합니다. 이 하나의 테스트가 어떤 코드 리뷰보다 많은 문제를 잡습니다.

두 서버가 같은 보고서를 노출해도 당신의 자격 증명을 누가 보는지는 다를 수 있습니다.

도구가 실패할 때 무슨 일이 일어나는지 확인하십시오. 요청 한도는 실재합니다. Search Console은 사이트당 분당 1,200 쿼리를 허용하고, 에이전트의 재시도가 몰리면 그것만으로 소진됩니다. 한도를 표면화하는 서버는 쓸 만합니다. 아무것도 반환하지 않고 조용히 넘어가는 서버는 노출이 없다고 에이전트를 가르치며, 이는 오류보다 나쁩니다. 같은 한도가 직접 만든 순위 추적기의 형태도 정하므로, 요청 예산은 설정 파일에 한 줄을 할애할 가치가 있습니다.

에이전트에 연결하기

설정은 작은 부분입니다. 가치를 얻을지 결정하는 것은 배치입니다.

{
  "mcpServers": {
    "gsc": {
      "command": "npx",
      "args": ["-y", "mcp-gsc"],
      "env": { "GSC_CREDENTIALS": "/path/to/service-account.json" }
    },
    "dataforseo": {
      "url": "http://localhost:3000/mcp",
      "headers": { "Authorization": "Basic <base64 login:password>" }
    }
  }
}

우리가 쓰는 세 가지 규칙을, 막아주는 고통이 큰 순서로 적습니다.

데이터 소스마다 서버 하나. 둘 다 순위 질문에 답할 수 있다고 주장하는 두 서버는 두 개의 답을 만들고, 에이전트는 정확한 쪽이 아니라 더 그럴듯하게 들리는 쪽을 고릅니다. Search Console은 래퍼에, 서드파티 SERP 데이터는 게이트웨이에 주고, 어느 필드에 어느 쪽이 권위 있는지 적어 두십시오.

보고 정의를 서버 밖에 두십시오. 도구는 에이전트에게 데이터 접근을 줍니다. 당신의 정의는 주지 않습니다. 어떤 속성을 세는지, 어떤 쿼리가 돈이 되는 쿼리인지, 순위가 기간 평균인지 일일 스냅숏인지. 그것들은 에이전트가 무언가를 호출하기 전에 읽는 지침 파일에 속하며, 유용한 요약과 자신만만한 오답을 가르는 차이입니다. 주간 보고 워크플로는 정의가 도구 밖에 사는 실제 예입니다.

첫 실행은 손으로 검증하십시오. 서버를 통해 한 주치 검색 애널리틱스를 가져와 Search Console 화면의 같은 주와 비교하십시오. 숫자가 맞지 않으면 날짜 범위나 기여 분석 문제가 있고, 그 이후의 모든 자동 보고서가 그것을 물려받습니다.

Auspia 관점: MCP의 질문은 "어느 서버가 최고인가"가 아닙니다. "에이전트와 데이터 사이에 어떤 경계를 둘 것인가"입니다. 래퍼는 미리 받아들이는 계약입니다. 게이트웨이는 매 실행마다 받아들이는 책임입니다. 어느 쪽이 더 넓은 순위 워크플로에 맞는지는 에이전트 역량 가이드가 작업을 정리합니다. 둘 다 정당하며, 데이는 팀은 자신이 선택했다는 걸 알아차리지 못한 채 선택한 팀입니다.

자주 묻는 질문

Google이 Search Console용 공식 MCP 서버를 공개합니까? 2026년 9월 12일 기준으로 우리가 패키지 저장소에서 찾을 수 있는 것은 없었습니다. 우리가 시험한 Search Console 서버는 공식 API 위에 올라간 커뮤니티 또는 벤더 프로젝트입니다. 공식인 것은 API 쪽이므로 그것 자체가 자동으로 문제가 되지는 않지만, 그 서버가 당신이 선택하는 유지보수 의존성이라는 점은 뜻합니다.

에이전트 세션 하나에 MCP 도구가 몇 개면 너무 많습니까? 정해진 수는 없습니다. 실용적인 한계는 도구 목록이 컨텍스트 창에서 당신의 지침을 밀어내는지 여부입니다. 그중 둘만 필요한 작업에 42개 도구 서버를 로드하면 매 호출마다 마흔 개 정의 값을 치르는 것입니다. 일상 업무에는 좁은 서버를, 탐색에는 넓은 서버를 로드하십시오.

서비스 계정 없이 에이전트가 Search Console에서 MCP를 쓸 수 있습니까? 됩니다. 서버가 OAuth 흐름을 구현했고 당신이 한 번 로컬에서 완료하면 됩니다. 서비스 계정 경로는 자동화가 쉽고 사람에게 넘기기 어려워, 팀은 보통 둘 다 돌립니다. 정기 실행에는 서비스 계정, 수시 작업에는 OAuth입니다.

어느 서버를 남겼습니까? 래퍼입니다. 주간 보고용이며 질문이 알려져 있기 때문입니다. 게이트웨이는 래퍼가 덮지 않는 데이터 소스가 필요한 일을 위해 설치된 채로 둡니다. 그것은 흥미로운 작업의 대부분이고 일상 작업의 어느 것도 아닙니다.

글쓴이: Julian Mercer, Auspia에서 40개 이상의 에이전트 툴체인을 가로지르는 MCP 통합 연구자. 에이전트 프로토콜, 도구 경계, 언어 모델을 살아 있는 데이터에 연결하는 운영 비용에 관해 씁니다.