▲

MCP 명세 – 2025-06-18 버전 변경점

 (modelcontextprotocol.io)
1P by GN⁺ 13시간전 | ★ favorite | 댓글 2개
  • MCP 스펙의 새 업데이트는 구조화된 메타데이터와 컨텍스트 관리 부분에 주안점을 둠. 확장성 향상과, 다양한 시스템 간 상호운용성 강화 목적
  • 새로운 데이터 필드가 추가되며, 기존의 필수 필드들이 좀 더 구체적으로 정의. 메타데이터 구조의 계층화로 인해 시스템별 별도 확장 방식 지원이 가능해짐
  • 컨텍스트 추적과 속성 갱신을 위한 명확한 규칙 제시, 이전 대비 일관된 상태 정보 관리 기능이 강조됨
  • 권한 관리 및 데이터 검증 절차가 프로토콜 명세에 명시됨. 새롭게 추가된 일부 필드는 향후 프로토콜 버전과의 호환성을 염두에 둔 것
  • 크로스 플랫폼 통합 지원: 여러 AI 플랫폼, 클라우드 서비스 환경에서도 일관된 방식으로 컨텍스트 데이터를 교환할 수 있는 기반을 제공
  • MCP(Model Context Protocol)는 머신러닝 모델 또는 대규모 언어 모델 등 다양한 AI 시스템 간의 컨텍스트 메타데이터 교환을 위한 프로토콜임

Major changes

  1. JSON-RPC 배치(batching) 지원 제거 (PR #416)
  2. 구조화된 도구 출력(structured tool output) 지원 추가 (PR #371)
  3. MCP 서버를 OAuth 리소스 서버로 분류, 보호된 리소스 메타데이터를 추가해 연동 Authorization 서버를 찾을 수 있도록 개선 (PR #338)
  4. MCP 클라이언트가 RFC 8707의 Resource Indicator 구현 필수 (악의적 서버의 액세스 토큰 획득 방지 목적) (PR #734)
  5. Authorization 명세 내 보안 고려사항(security considerations) 및 베스트 프랙티스 명확화, 별도 보안 가이드 페이지 추가
  6. Elicitation(질의 요청) 기능 추가, 서버가 사용자에게 추가 정보를 요청할 수 있도록 지원 (PR #382)
  7. Resource Links 지원 추가, 도구 호출 결과에 리소스 링크 포함 가능 (PR #603)
  8. 프로토콜 버전 협상 시, HTTP에서 MCP-Protocol-Version 헤더 필수 (PR #548)
  9. Lifecycle Operation의 SHOULD를 MUST로 변경 (참고)

Other schema changes

  1. _meta 필드가 더 많은 인터페이스 타입에 추가됨 (PR #710), 적절한 사용법 명시
  2. CompletionRequest에 context 필드 추가, 이전에 해석된 변수 포함 가능 (PR #598)
  3. 프로그램용 식별자와 별도의 사용자 친화적 표시를 위한 title 필드 추가 (name은 코드 식별자 용도로, title은 표시용) (PR #663)
▲
kernel00 1시간전  [-]

핵커뉴스 댓글이 좀 아쉽네요. stdio 만 봤나본데 지금 remote mcp server나 그걸 중개해주는 registry들이 얼마나 우후죽순 생겨나는데....

답변달기
▲
GN⁺ 13시간전  [-]
Hacker News 의견
  • 내가 MCP(Machine Context Protocol) 붐을 타면서 가장 크게 배운 점은, 백엔드 소프트웨어 개발에서는 굳이 MCP를 쓸 필요가 없다는 사실임. 아키텍쳐적으로 맞지 않는 부분이 있음. 특히 Elixir 같은 환경에서는 더더욱 그렇다는 생각임. API 하나마다 서버를 따로 둔다면, 500개의 API에 500개의 마이크로서비스를 돌린다는 말이 됨. 직접 20가지 MCP 서버를 써 본 후에야 깨달았는데, 결국 MCP도 함수 호출의 껍데기였음. 각 API는 서버가 아니라 별도의 모듈로 만들면 충분함. 괜히 최신 MCP 사양을 따라갈 필요도, 사양 변경될 때마다 수백 개 마이크로서비스를 업데이트할 필요도 없음. 그냥 불필요한 복잡성이라는 결론임
    • 클라이언트가 게이트웨이나 BFF를 통하지 않고 각 마이크로서비스에 곧바로 연결하지 않는 이상, 그냥 MCP를 전체 서비스 앞에 두고 API, GraphQL, RPC 등 기존 방식처럼 기능만 노출하면 됨. 사실상 LLM에 특화된 인터페이스라는 느낌임. OpenAPI 사양 기반의 tool call도 충분히 쓸 수 있음. 어쨌든 모든 마이크로서비스들끼리 MCP로만 통신하게 하는 건 너무 과한 상상임
    • 나는 MCP를 Claude처럼 API 비용 없이 function call을 가능하게 해주는 플러그인식 통합 솔루션 정도로만 봤음. 만약 네가 API를 쓰고 있는데 급할 일 없다면 굳이 필요 없는 선택지임
    • 사실 MCP는 클라이언트와 모델을 연결해주는 표준 프로토콜이라는 생각임. 단순히 툴 호출을 감싸 주는 용기는 아님
    • 맞음, API마다 MCP 서버 하나씩 두는 건 확장되지 않는 구조임. nango.dev 같은 걸 사용하면 한 서버에서 400개 이상의 API를 포괄할 수 있음. 인증 처리, 가시성 확보, 그리고 직접 tool call할 수 있는 다양한 인터페이스도 제공함. (참고로 나는 창업자임)
    • 나는 한발 더 나가서 LLM에게 JSON 출력을 강제하는 문화 자체가 어리석다는 생각임. LLM이 직접적으로 좋아하지도 않는 까다로운 포맷에 맞추려 시간과 노력이 너무 들어감. 훨씬 제약이 많은 텍스트 기반 DSL이 훨씬 좋은 대안이었음. 예전 GPT 3.5 때는 프롬프트에 간단한 예시 몇 개 주는 것만으로도 영어 기반 DSL을 신뢰성 있게 출력할 수 있었음. 그런데 최신 모델들조차 JSON schema의 일부를 종종 무시한다는 주의가 남아 있음. 네모난 구멍에 동그란 못을 억지로 박는 느낌임, 모두들 억지로 하지 않았으면 좋겠음
  • 이제 인증된 MCP 서버로 가는 간단한 경로가 생긴 걸 정말 기쁘게 생각함. MCP 커뮤니티와 Anthropic 팀에게 진심으로 감사를 표하고 싶음
    • MCP 서버가 왜 필요한지 잘 모르겠음. 에이전트가 RPC를 하고 싶다면 그냥 RPC를 쓰면 충분하지 않은가, 라는 생각임
  • 핵심 사양이 OpenAPI나 다른 것 대신 TypeScript로 작성된 점이 정말 신기하게 느껴짐. 타당한 이유가 있겠지만 그래도 의외라는 인상임
    • 왜 이게 놀라운 건지 궁금함. 나도 타입스크립트를 많이 쓰지만, 이런 관점은 생각해본 적이 없어서 언어 디자인 쪽에서 어떤 결정이 있었는지 궁금한 마음임
  • WWW-Authenticate 챌린지가 도입된 점이 너무 반가운 소식임. 이제 MCP 서버가 클라이언트를 리소스 제공자의 OAuth 플로우로 넘기고, Authorization: Bearer ... 헤더를 받아오기만 하면 되는 그림이 명확해졌음
  • <i>대부분</i> 불필요한 복잡성이 맞다고 생각하지만, 배치 실행 기능은 아쉬움. '이 작업 모조리 다 해놓고, 결과를 한 번에 응답'하는 걸 구현하는 게 재밌었음. 물론 클라이언트가 알아서 배치 응답을 묶어도 되긴 하는데 여전히 재미가 있음
    • 맞음. JSON-RPC 배치 기능은 정말 “와, 이거 신기하네” 했던 경험임. 사양에서 빠지는 건 아쉽지만, 결국 복잡성만 더하는 측면도 있어서 이해는 함
  • elicitation(추론 기반 프롬프트 처리)이 큰 수확이라고 생각함. 내가 가장 좋아하는 MCP 서버 중 하나는 직접 만든 SSH 서버임. 전체 서버 작업의 90%를 자동화할 수 있음. 인증은 설정 파일로 관리했는데, 새 서버에 접속할 일이 생길 때마다 직접 수정해야 해서 살짝 번거로움이 있음
    • 이런 경우엔 fabfile.org 같이 쓸 수도 있다는 마음임. 굳이 LLM을 도입하지 않아도 되는 대화라면 사적으로 두는 게 더 낫다는 생각임
  • 지난 며칠간 MCP로 데이터셋 래퍼를 만들며 놀아봤던 경험임
  1. LLM 분야에서 가장 흥미진진한 시도라는 생각임. 물론 기존 API & tool call로도 비슷한 걸 할 수 있겠지만, 기술에 익숙하지 않은 친구에게도 Claude용 MCP URL만 던져주면 클릭 몇 번으로 써보는 게 굉장히 인상적이었음
  2. csharp SDK를 쓰고 있는데, 인증 기능이 아직 브랜치에만 있어서 아주 초기 상태임. MCP 통합 중 95%의 시간이 인증 구현에 쏠렸음(로컬 빌드가 아니라면 필수임). 문서가 더 나오면 개선될 테지만, 지금은 꽤 손 많이 가는 과정임
  3. 개발자 로그 노출이 부족하다는 점도 있음. Claude가 웹(데스크톱 말고)에서 뭘 주고받는지, 어디서 오류가 나는지 개발자 모드에서 request/response 로그를 보여줬으면 좋겠음. 인증 갱신 문제로 한참 헤맸는데, 내가 잘못된 엔드포인트를 로깅하고 있었다는 걸 늦게야 알아차림. 만약 더 나은 MCP 로깅이 있었다면 몇 분 만에 끝나던 일이었음. 데스크톱과 MCP inspector에서는 잘 됨
  4. 가장 고민인 건 장시간 작업 처리임. 내가 노출하는 데이터셋은 여러 PDF 문서임. Claude 자체적으로 PDF를 다루는 건 불가능해 보이고(방법 있으면 누구든 알려주길 바람!) 일단 gemini를 거쳐서 텍스트로 변환한 뒤 MCP로 넘기는 방식임. 간단한 문서는 잘 되지만, 긴 문서는 처리 시간이 길어짐. 지금은 '처리 중이니 나중에 다시 시도해달라'는 안내만 보냄. progress API가 있긴 한데, 서버에 지속적으로 연결을 유지해야 해서(Cloudflare 상으로는 일정 시간 후 끊김) 실용성에 한계가 있는 듯함. LLM이 x초 후 다시 확인하게 하고, 그 전엔 다른 작업을 하게 만든 상태에서, 타이머가 끝날 때까지 '실행 잠정 중단'되는 방식이 있으면 정말 좋겠음. 현재로서는 연결을 유지할 때 LLM이 아무것도 못하고 대기 상태가 되거나, 아니면 job ID 주고 반환하면 불완전한 응답만 나와서 전체 맥락이 빠지는 경우가 많음. 10분 이상 걸려야 하는 작업에는 큰 장애물이 될 수 있다는 생각임
  • 장기 실행 작업은 아직 공개적으로 논의되고 있는 주제임. MCP도 앞으로 이를 해결할 의도가 있는 걸로 알고 있음. 여러 제안들이 오가고 있고, 항상 작업이 오래 걸릴지 알 수 없으니 장기 작업 API를 분리하는 것만으론 해답이 안 됨. 이 부분을 통합적으로 풀자는 내 제안도 있음 discussion 링크
  • MCP 사양이 빠르게 개선되는 점이 매우 반가움. 새로운 릴리즈마다 기존에 내가 MCP 통합에서 아쉬웠던 부분이 하나씩 채워지는 걸 확인할 수 있음
  • 사양 변경이 합병되려면 단 한 번의 승인이면 된다는 점이 재밌게 느껴짐
  • MCP가 실제로 무엇을 해결하는지 잘 모르겠음. 개인적으로는 노트북에서 뭔가 빨리 프로토타이핑 할 때 역할 정도만 떠오름. 로컬 프로그램을 만든다면 LLM이 접근할 수 있는 툴셋을 훨씬 세밀하게 제어하고 싶음. 예를 들어 Google Calendar용 MCP 서버를 생각해 봐도, MCP가 시간을 크게 절약해주지 않음. 동일 API를 내가 직접 쓸 수도 있고, LLM에게 Google Calendar를 언제, 어떻게 호출할지 명시적으로 알려줘야 하니 3자에게 위임하고 싶지 않음. 또 어떤 언어로 MCP가 작성되었는지 상관없이 내 환경에서 임의로 프로세스를 띄우는 것도 부담임. 내 쪽이 Python인데 사용자에게 타입스크립트 런타임을 추가로 요구해야 한다면 곤란할 수 있음. MCP 래퍼에 취약점 생기면 보안 이슈도 걱정임. 서버 환경에서는 정당성 확보가 더 어려움. 서로 다른 머신에서 구현 세부사항 몰라도 호출할 수 있는 이미 훌륭한 방법이 RPC임. MCP는 그 위에 의견 강한 미들웨어와 보안 문제만 더하는 느낌임
    • 내가 이해 안 가는 건, 왜 지금까지 본 MCP들은 전부 커맨드(명령어) 기반이고 HTTP 인터페이스를 쓰지 않는지 모르겠음. 만약 HTTP 방식이면 한 서버만 띄워서 조직 전체가 공유할 수 있고, 각자 툴체인 세팅 필요 없이 쓸 수 있음
    • 백엔드가 고정된 흐름을 강제하는 기존 방식과 달리, MCP를 쓰면 LLM 자체가 직접 오케스트레이션을 수행하는 게 장점임. 예를 들어 웹 검색을 할 때 쿼리를 재수정해서 원하는 정보를 찾을 때까지 재시도할 수 있음. CLI로 특수한 문제를 풀 때도 여러 툴을 적절한 순서로 활용함. 이건 고정된 흐름에서는 할 수 없는 조직화임
    • MCP가 해결하는 부분은, LLM 중심에서 agent에 tool 등 여러 기능을 표준화된 프로토콜로 연결해주는 점임
    • 나도 강하게 공감하는 부분이 있음. 실제로 써 보면 굉장히 느린 느낌을 받음. 나는 2년 전에 LLM 클라이언트 개발하려고 직장을 그만뒀는데도 아직 Google calendar 연동 못함. 그나마 사용자 입장에서는 이런 임시 구멍을 메꿀 수 있는 게 MCP의 쓸모임. 예전에 아이폰 홈 화면 상위 3줄은 비슷해도 맨 끝줄은 각자 다 제각각이었던 이야기가 기억남. 앞으로도 IT 부서와 개발팀들은 각자 자기 업무에 맞는 MCP 서버를 계속 만들 거라는 예감임
답변달기