MCP Tasks (async): Why Aren't Any Agents Supporting Them? — Cornelia Davis, Temporal

한 줄 핵심

MCP tasks는 장기 실행과 중단 복구를 위해 필요하지만 V1의 상태 저장형 설계와 복잡한 클라이언트 프로토콜 때문에 구현이 어려웠고, V2는 무상태화와 extension 분리로 훨씬 단순해진다.

시간별 요약

1. 0:01
   MCP tasks는 장기 실행 도구를 비동기로 다루기 위한 기능이며, 실험적 사양이고 구현 복잡도가 높아 클라이언트가 쉽게 지원하지 못한 이유가 분명하다. 구매 주문과 인보이스 처리 예시로, 작업이 오래 걸리고 사람 승인과 장애 복구가 필요한 상황을 설명한다.
2. 4:01
   MCP tasks의 핵심은 호출 즉시 결과를 받는 대신 handle을 받아 장기 실행 작업과 상호작용하는 구조다. 그러나 네트워크 끊김, 서버 중단, 사용자 부재처럼 긴 시간 동안 발생할 수 있는 장애를 견뎌야 하므로 durability가 필수다.
3. 11:00
   V1은 task list와 task result를 중심으로 한 상태 저장형 프로토콜이라서, task list는 대량 작업에서 조회 비용이 크고 task result는 장기 연결과 역방향 상호작용 때문에 구현이 매우 까다롭다. 즉, 기능은 가능하지만 분산 시스템 규모에서 다루기 어려운 구조다.
4. 16:01
   V2는 프로토콜을 무상태 core와 extensions로 재구성하고, tasks를 extension으로 분리해 구조를 단순화한다. 특히 task list를 제거하고 client가 update를 보내는 방식으로 바뀌면서, input required 처리와 task result 흐름이 훨씬 구현하기 쉬워진다.
5. 19:01
   V2에서도 task ID 영속화와 다수 작업 처리 문제는 남아 있으며, 대규모에서는 여전히 polling만으로는 확장성이 부족하다. 이를 보완하기 위해 notification 기반 변경 감지와 fast MCP 통합 구현이 다음 단계로 제시된다.

실무 인사이트

• MCP tasks를 도입할 때는 기능 여부보다 먼저 클라이언트 쪽 durability, 재연결, 상태 복구 전략을 설계해야 한다.
• 대량의 장기 작업을 다룬다면 task list처럼 전수 조회하는 API보다, 변경 알림과 개별 pull을 결합한 구조가 더 현실적이다.
• 실제 구현 난이도는 스펙 문서보다 클라이언트 프로토콜의 상태 관리와 역방향 상호작용 설계에서 크게 발생한다.