MCP 서버는 에이전트가 실제 도구 — 브라우저·데이터베이스·배포 플랫폼 — 에 닿게 합니다. 실전에서 어떻게 썼는지, 함정 포함해 적습니다.
브라우저 자동화
인브라우저 MCP가 실제 Chrome 세션을 구동합니다 — 클릭·폼 채우기·스크린샷. 저를 문 함정: 브라우저 확장이 연결 안 돼 있으면 자동화가 아예 안 돌고, 그 실패가 앞에서 항상 명확하진 않습니다. 이에 의존하는 플로를 짜기 전에 연결을 확인하세요.
결과 카드 캡처용 Playwright
앱이 결과를 입력 플로 뒤에 숨기면 Playwright MCP로 플로를 몰아 — 폼 채우고, 제출하고, 결과 페이지에 도착 — 결과 카드를 캡처합니다. React 입력 채우기는 .value 설정만이 아니라 네이티브 setter + input 이벤트가 필요합니다. 아니면 프레임워크가 변경을 인식 못 합니다.
Supabase 관리
스키마 작업은 Supabase Management API를 MCP로 씁니다. 여기 함정은 진짜 벽입니다: DDL은 service key로 실행 불가 — management 토큰(sbp_... 토큰)이 필요하고, 그 토큰이 키체인에서 사라질 수 있어, DDL 호출이 갑자기 권한 에러로 실패하면 재인증합니다.
Vercel
Vercel MCP가 에이전트 루프 안에서 배포·프로젝트 작업을 커버해, "변경하기"와 "배포하기"가 별도 터미널로의 컨텍스트 전환 없이 같은 세션에 삽니다.
솔직한 부분
MCP의 가치는 추상적으로 "에이전트가 더 많이 한다"가 아니라 — 탐색·행동·검증이 한 루프로 접힌다는 것입니다. 하지만 각 서버엔 날카로운 모서리가 있습니다: 살아 있어야 하는 연결, 프레임워크가 필요로 하는 input 이벤트, service key가 대체 못 하는 토큰. MCP 도구를 다른 통합처럼 다루세요 — 각각의 인증 모델과 그 하나의 실패 모드를 알면 — 에이전트가 코드 생성기에서 실제로 스택을 구동하는 무언가로 바뀝니다.