Pi.dev: MCP는 지원하지 않는다더니!

Pi가 MCP를 코어 기능으로 지원하기 시작함. MCP 자체의 변화뿐 아니라, 통합에 필요한 인터프리터 샌드박스와 도구 체계 개선이 Pi 전반에도 유용하다는 판단에 따른 결정임 MCP에는 여전히 도구 호출을 조합하기 어렵다는 한계가 있음. 도구를 컨텍스트에 나열하고 텍스트를 반환하는 방식보다, 문서로 도구를 검색하고 구조화된 데이터를 받는 방식이 필요함 Pi는 MCP 도구를 JavaScript 샌드박스인 Codemode에 노출해 호출 순서를 조정하고 여러 도구를 코드로 조합하도록 함 최신 모델의 도구 지연 로딩 등에 맞춰, 도구를 LLM에 직접 제공할지 Codemode에서만 사용할지 구분할 수 있도록 도구 구성 체계를 보완함 Codemode는 하네스 측에서 실행되며 상태를 파일 시스템이 아닌 세션 대화 기록의 일부로 유지함. MCP 외에도 사용할 수 있고, MCP를 설정하면 자동으로 로드됨 MCP를 확장에서 코어로 옮긴 이유 Pi는 과거 사이트에서 MCP 미지원을 내세웠으며, 팟캐스트와 Mario의 글에서도 MCP에 부정적인 태도를 보였지만, 이제 업그레이드하면 MCP를 지원함 지난 1년간 MCP가 달라졌지만, 프로토콜의 개선만으로 코어 통합을 결정한 것은 아님 Pi에는 확장 생태계가 있으며, MCP도 이미 확장 기능으로 제공되고 있었음 Earendil이 공식적으로 지원하는 확장으로 둘 수도 있었지만, 통합에 필요한 변화가 Pi 전반에 유용하다고 판단함 Pi와 MCP 모두 인터프리터 형태의 샌드박스가 필요하며, 이번 변화는 Pi 안에서 Jev를 더 쉽게 사용하는 데도 도움이 됨 세계는 고정되어 있지 않다는 전제 아래, 기존 입장을 유지하기보다 변화한 MCP와 Pi의 요구를 함께 재검토함 남아 있는 문제: 도구 조합과 서버 설계 MCP의 가장 큰 문제는 여전히 조합하기 어렵다는 점이며, 도구 호출을 조합하는 샌드박스인 Codemode도 이를 완전히 해결하지는 못함 이제는 MCP 자체보다 기존 서버와 이를 다루는 하네스들의 서로 다른 접근 방식이 더 큰 문제임 많은 MCP 서버는 도구를 모두 컨텍스트에 넣는 하네스를 전제로 설계됐으며, 토큰 효율을 위해 텍스트를 반환하려고 함 Pi가 지향하는 MCP는 지능형 도구 검색을 갖춘 OpenAPI에 더 가까움 도구는 구조화된 데이터를 반환해야 함 도구의 문서와 설명을 통해 필요한 도구를 찾을 수 있어야 함 CLI가 유용한 이유는 에이전트와 모델이 효율적인 Bash 구문으로...