MCP와의 관계

도구(tool)를 만들 때 참고할 다른 표준이 있다면 MCP(Model Context Protocol)입니다. 우리 매니페스트의 도구 정의는 MCP 도구와 거의 1대 1로 겹칩니다. 실제로 플랫폼이 앱 도구를 MCP 도구 정의로 바꿔 Claude 실행기에 넘기는 다리 역할을 이미 하고 있습니다.

매핑

input, output은 매니페스트 문서에서 설명하듯 문자열(번들 안 파일 경로)이거나 인라인 JSON Schema 객체입니다. 어느 쪽이든 결국 같은 모양의 JSON Schema 객체로 풀립니다.

{
  "key": "weather.forecast",
  "title": { "ko": "일기 예보", "en": "Weather forecast" },
  "input": { "type": "object", "properties": { "city": { "type": "string" } }, "required": ["city"] },
  "output": "schemas/forecast.out.json",
  "approval": "none",
  "irreversible": false,
  "readOnly": true
}

이 예시처럼 input과 output을 같은 도구 안에서 섞어 써도 됩니다. 파일 경로 방식이 기본 권장이고(에이전트로 만들기 참고), 인라인 객체는 외부에서 이미 스키마를 JSON으로 받는 경우처럼 파일로 쪼개는 게 번거로울 때 씁니다.

MCP에 없고 우리만 가진 것

approval, scopes, i18n, triggers, surfaces는 MCP 스펙에 없습니다. 도구 하나의 입출력 계약을 넘어서는 플랫폼 층위(승인 흐름, 권한 경계, 다국어, 트리거, 화면)라서 계속 우리가 가져갑니다. MCP는 도구를 어떻게 부르고 무엇을 주고받는지만 정의하고, 이런 것을 정의하지 않습니다.

열어 둔 방향

지금 만들지는 않았지만, 매니페스트 스키마가 막지 않게 열어 둔 방향이 둘 있습니다.

• 나가는 방향: Tiffy 앱의 도구를 MCP 서버로 노출합니다. 다른 MCP 클라이언트(다른 에이전트, 다른 제품)가 Tiffy 앱의 도구를 그대로 쓸 수 있게 됩니다.
• 들어오는 방향: 이미 있는 MCP 서버를 앱의 한 종류로 설치합니다. 매니페스트가 input/output으로 인라인 객체를 받게 된 것이 이 방향의 전제 조건입니다. 외부 MCP 서버가 내려주는 스키마를 파일로 옮겨 담을 필요 없이 그대로 넣을 수 있어야 하기 때문입니다.

실제로 MCP 서버를 호출해 실행을 잇는 다리를 놓는 일은 이번 범위 밖입니다.