Chrome DevTools MCP와 Playwright MCP의 도구 설명 점수 평가: 두 서버 모두 사용 시점을 명확히 언급하지 않음

저는 두 가지 브라우저 자동화 MCP(Multi-Capability Protocol) 서버, 즉 Google의 Chrome DevTools MCP와 Microsoft의 Playwright MCP의 도구 설명을 점수화했습니다. 이들의 평균 점수는 각각 100점 만점에 45.1점과 41.9점이었습니다. Chrome DevTools MCP에서는 30개 도구 중 24개가 언제 사용해야 하는지 언급하지 않았고, Playwright MCP에서는 25개 도구 중 23개가 그러했습니다. 또한 각각 27개와 21개의 도구가 반환하는 값이 무엇인지 명시하지 않았습니다.

이 점수화는 제가 구축한 MCP 도구 설명을 위한 정적 linter인 Forecall을 사용하여 진행되었습니다. 이 글에서는 그 결과를 보여주고, 낮은 점수를 받은 설명과 높은 점수를 받은 설명의 차이점, 여기에 세 문장을 추가했을 때 어떤 변화가 있었는지, 그리고 실제 모델들이 두 버전을 가지고 무엇을 했는지를 다룹니다.

에이전트는 이름, 설명 및 입력 스키마에서 도구를 선택하고 그 외에는 아무것도 사용하지 않음

AI 에이전트는 MCP 서버가 반환하는 도구 목록( tools/list의 결과)을 읽고 어떤 인자들로 어떤 도구를 호출할지 결정합니다. 에이전트가 의존하는 것은 오직 세 가지 요소뿐입니다: 도구의 이름, 설명, 그리고 입력 스키마.

만약 설명이 단순히 이름을 반복할 뿐이라면, 모델은 이름과 스키마만을 가지고 있으며, 실제로 호출을 수행하기 전까지는 무엇을 반환하는지 아무것도 알 수 없습니다. 이것이 충분한지는 실제 모델로만 측정할 수 있으며, 저는 이 글의 후반부에서 이를 진행했습니다.

점수화 방법: tools/list를 가져온 다음 100점 만점에 여섯 가지 항목을 평가하기

저는 2026년 10월 7일에 이 두 버전을 로컬에서 시작하고 그들의 tools/list 결과를 JSON으로 저장했습니다. 도구 호출은 이루어지지 않았습니다.

저는 Forecall의 CLI (npx forecall lint)를 사용하여 JSON을 점수화했습니다. 이 도구는 각 도구를 여섯 가지 항목에 대해 점수를 매깁니다:

결과: 둘 다 40점대에 평균이며, 같은 부분에서 약합니다

| | Chrome DevTools MCP | Playwright MCP | |
| --- | --- | :--- |
| 평균 점수 (Average score) | 45.1 | 41.9 |
| ... |
두 서버 모두에서, 감점된 대부분의 점수는 '언제 사용해야 하는지(when to use)'와 '반환 값(return value)'에서 발생했습니다. 둘 다 인자(arguments)를 잘 설명하고 있으며, 근접하게 동일한 설명을 가진 도구 쌍은 없으므로 도구 이름이 명확히 구분됩니다.

차이가 나는 부분은 얼마나 많은 설명이 단순히 이름을 재진술하는지입니다. Playwright MCP의 25개 도구 중 14개가 그러한 경우에 해당합니다.

낮은 점수를 받은 도구들은 이름을 재진술하는 한 문장으로 끝납니다

가장 낮은 점수는 Chrome DevTools MCP에서 31점(drag, hover, upload_file)이었고, Playwright MCP에서는 33점(browser_handle_dialog, browser_navigate, browser_type 등)이었습니다. 해당 설명들은 다음과 같습니다:

높은 점수를 받은 도구들은 예시와 함께 사용 시점을 말합니다

같은 서버들 중에는 점수가 잘 나온 도구들도 있습니다. Chrome DevTools MCP의 최고점은 fill_form으로, 72점입니다:

여러 개의 폼 요소(입력 필드, 선택 상자, 체크박스, 라디오 버튼)를 한 번에 채울 수 있습니다. 폼과 상호 작용할 때는 개별적인 '채우기' 또는 '클릭' 호출을 여러 번 사용하는 것보다 항상 이 도구를 우선적으로 사용해야 합니다. 훨씬 빠르고 신뢰성이 높으며, 턴 수를 줄여줍니다. 예시: 사용자 이름, 비밀번호를 채우고 '로그인 유지' 체크박스를 한 번의 호출로 선택합니다.

이것은 어떤 상황에서 다른 도구(fill 또는 click)와 구분하여 사용해야 하는지 설명하고 구체적인 예를 제시합니다. 빠진 것은 반환 값에 대한 내용뿐입니다.

Playwright MCP가 가장 좋은 점수를 받은 것은 browser_find로, 66점을 받았습니다. 이 단락에서는 무엇을 검색하는지, 무엇을 반환하는지, 그리고 전체 스냅샷을 찍는 것보다 왜 더 저렴한지에 대해 설명합니다.

세 문장이 drag의 점수를 31점에서 74점으로 올렸다

저는 drag의 설명을 그 스키마에 있는 사실만을 사용하여 다시 작성했습니다. 저는 세 가지 내용을 추가했습니다: 언제 사용해야 하는지(그리고 upload_file과 어떻게 다른지), 호출하기 전에 무엇을 해야 하는지, 그리고 무엇을 반환하는지입니다.

Drag one element and drop it onto another inside the page. Use it for drag-and-drop UIs such as sortable lists, kanban boards and sliders; to send files from the computer, use upload_file instead. Take a snapshot first and pass the uids of both elements as from_uid and to_uid. Returns a snapshot of the page after the drop when includeSnapshot is true.

이것만으로도 43점입니다. 언제 사용해야 하는지(when to use)에 대한 문장이 가장 큰 영향을 미쳤습니다: '사용 시점' 점수가 0점에서 만점인 20점으로 올랐기 때문입니다.

재작성본은 또한 새로운 발견을 가져왔습니다: 이 도구는 파괴적일 수 있지만 destructiveHint가 없습니다. 이는

Chrome DevTools MCP 유지 관리자가 에이전트가 짧은 설명으로 인해 혼란을 겪는 구체적인 사례를 요청했습니다. 그래서 제가 하나를 만들어 보았습니다. 가짜 서버(stand-in server)는 chrome-devtools-mcp 1.10.1의 tools/list를 원래 그대로 또는 드래그, 호버(hover), upload_file로 재작성된 형태로 반환했고, 모델들은 이 세 가지 중 하나가 올바른 도구인 여덟 개의 원스텝 작업(one-step tasks)을 받았습니다. 그 대상은 칸반 카드, 호버 메뉴, 툴팁, '사진 추가' 버튼, 드롭된 이미지를 받는 아바타 영역 등이었습니다.

• 원래 설명 그대로 사용했을 때는 어떤 모델도 잘못된 도구를 선택하지 않았습니다: Fable 5.1을 사용한 Claude Code, Sonnet 5.5 및 Haiku 4.5 (24/24), gpt-6-astra를 사용한 Codex CLI (11/11), 그리고 Claude Opus 5.5, Claude Sonnet 5.5, gpt-6-astra, gpt-6.1-sol에 대한 원턴 API 호출(32/32). 유일하게 잘못된 선택은 두 개의 작은 Codex 모델에서 hover 대신 click을 사용한 경우였으며, 이는 텍스트가 모호했던 작업에서 발생했습니다.
• 제가 재작성한 설명으로는 두 모델의 성능이 저하되었습니다. gpt-5.6-luna는

Forecall 자체 평가를 사용한 나중에 더 많은 테스트를 진행해도 동일한 결과가 나왔습니다. 30개의 Chrome DevTools MCP 도구 전체(도구당 8개 요청)에 걸쳐 Claude Sonnet 5.5와 GPT-6.1 Sol은 각각 99%, 98%의 확률로 올바른 도구를 선택했습니다. 또한, 요청에 페이지 번호가 포함되지 않은 경우 대부분 list_pages를 먼저 호출했는데(이러한 요청의 77–87%), 이는 올바른 조치입니다.

자체 서버에서 테스트해 보기

서버의 tools/list를 가져와 점수를 매겨보세요:

npx forecall dump -o tools.json -- <서버를 시작하는 명령어>

npx forecall lint tools.json

두 명령어 모두 사용자의 기기에서 실행되며, 결과는 어딘가로 전송되지 않습니다. 평균 점수가 60점 미만으로 떨어질 경우 CI(지속적 통합) 작업을 실패시키려면 --fail-under 60을 추가하세요. 대신 브라우저에서 테스트하려면 같은 JSON을 forecall.dev에 붙여넣으세요. 가입할 필요가 없습니다. 로그인 없이 사용할 수 있는 공개 서버의 경우, JSON 대신 해당 URL을 붙여넣을 수 있습니다. 두 서버의 전체 결과는 각각 forecall.dev/en/servers/chrome-devtools와 forecall.dev/en/servers/playwright에서 확인할 수 있습니다.

한 가지 주의할 점이 있습니다. 이 점수는 텍스트만 읽는 것에서 나오기 때문에, browser_close 같은 도구는 이름만으로도 짧고 명확하지만, 모델이 올바르게 사용하더라도 낮은 점수를 받을 수 있습니다. 이 점수는 개선할 여지가 있는 부분을 안내하는 지표로 간주하세요. 실제 모델들이 올바른 도구를 선택하는지 여부는 다른 방식으로 측정해야 하며, 위 테스트에서 보여주듯이 높은 점수가 더 나은 선택을 의미하지는 않습니다.

점수를 활용하여 격차를 찾고, 실제 모델로 재작성된 내용을 테스트하기

Google과 Microsoft의 브라우저 자동화 서버들은 인자(arguments)를 신중하게 설명하지만, 도구를 언제 사용해야 하는지 또는 무엇을 반환하는지에 대해서는 거의 언급하지 않습니다. 이 linter가 그러한 격차를 빠르게 찾아냅니다. 모델이 잘못 선택할 것이라고 알려주지는 않지만, 제가 테스트한 세 가지 도구의 경우, 모델들은 한 줄짜리 텍스트로는 올바르게 선택했지만, 더 긴 텍스트를 사용하자 그중 두 개가 성능이 저하되었습니다.

자체 서버를 운영하는 경우, 점수가 가장 낮은 도구부터 시작하여 호출이 무엇을 반환하는지 등 누락된 부분을 채우세요. 그런 다음 배포하기 전에 사용자가 실행할 모델로 새 텍스트를 확인하세요. 'drop'과 같은 단어나 예시 UI 목록은 모델을 잘못된 도구 쪽으로 유도할 수 있습니다.

업데이트: 저는 microsoft/playwright-mcp#1788와 ChromeDevTools/chrome-devtools-mcp#3026에서 상위 스트림(upstream)에 리라이트(rewrite)를 제안했습니다. Playwright 유지 관리자는 그 중 하나를 닫으면서, 점수보다는 최첨단 모델(frontier model)을 대상으로 재현 가능한 궤적(trajectory)을 요청했습니다. #3026에서는 위 테스트 이후, 저는 짧은 설명이 모델을 혼란스럽게 한다는 주장을 철회했습니다.

저는 Forecall의 저자입니다. 이 린터는 오픈 소스이며 다음과 같습니다: github.com/forecall/forecall-cli.