MCP가 해결하지 못하는 점
이 글은 복잡한 생산 워크플로우에서 Multi-Capability Protocol (MCP)의 한계를 직원 퇴사 예시를 사용하여 논의합니다. MCP는 도구 호출 및 보안 제어를 표준화하지만, 비즈니스 로직이나 권한을 본질적으로 다루지는 않습니다. 시스템은 도구의 존재와 유효한 인수를 확인할 수 있지만, 관리자가 실제로 해고 시간을 변경할 수 있는지 여부는 확인할 수 없습니다. 이 글은 전송 권한이 비즈니스 권한과 다르다는 점을 강조하는데, 이는 클라이언트의 서버 접근만 확인하고 비즈니스 조치의 유효성은 확인하지 않기 때문입니다.생산 워크플로우는 요청자, 행위자, 주체, 승인자 등 여러 신원을 포함하며, 이들이 통합되면 오해의 소지가 있는 감사 추적이 생성됩니다. 강력한 런타임 환경은 결과적인 도구 호출 전에 조치가 허용되는 이유를 설명하는 "실행 봉투"라는 간결한 기록이 필요합니다. 이 봉투에는 권한 있는 이벤트, 정책 버전, 실행 후 타임스탬프와 같은 세부 정보가 포함되어 조치를 공식 기록과 연결하고 조기 또는 무단 조치를 방지합니다.승인은 중요한 사실이 변경되면 만료될 수 있으며, 실행 시간에 가까운 고용 상태 및 법적 보류와 같은 중요한 정보의 재검증이 필요합니다. 쓰기 작업 중 타임아웃은 실패를 확인하지 않으므로, 재시도 또는 조정 전략을 안내하기 위해 도구가 멱등성 키 및 상태 조회와 같은 실행 세부 정보를 노출해야 할 필요성을 강조합니다.궁극적으로 워크플로우 무결성에 대한 책임은 분산되어 있습니다. 호스트는 도구 노출을 관리하고, 런타임은 정책을 평가하고 복구를 처리하며, MCP 서버는 요청을 검증하고, 대상 시스템은 자체 기록에 대해 권위가 있습니다. 이러한 제어를 구현하는 데는 비용이 들지만, 정확한 권한, 현재 증거 및 실패 의미가 가장 중요한 계정 비활성화와 같은 높은 결과의 조치에는 필수적입니다.