MCP 2025-06-18 스펙 업데이트 핵심 정리: Elicitation, Structured Output, Tool Behavior가 바꾸는 것들

MCP(Model Context Protocol)는 빠르게 진화하고 있다. 최초 릴리스 이후 여러 차례 개정을 거쳤고, 매번 MCP 서버가 할 수 있는 것과 클라이언트의 상호작용 방식이 변한다.

2025-06-18 업데이트는 상호작용 모델을 근본적으로 확장하는 세 가지 기능을 도입한다: Elicitation(도구가 사용자에게 질문), Structured Output(타입 안전한 도구 응답), Tool Behavior Annotations(안전성 메타데이터). MCP 서버를 만들거나 유지보수한다면, 이것들은 선택이 아니라 새로운 기준선이다.

이 업데이트 이전에 MCP 도구는 단방향이었다: 클라이언트가 입력을 보내고, 도구가 결과를 반환. 대화 없음.

Elicitation이 이걸 바꿨다. 도구가 실행 중 사용자에게 구조화된 질문을 할 수 있다. 사용자는 세 가지 중 하나로 응답: accept(폼 제출), decline(명시적 거부), cancel(선택 없이 닫기).

실무 영향: 항공권 예약 도구가 모든 매개변수를 미리 요구하는 대신 "어디로? 언제? 몇 명?"을 실행 중 물어볼 수 있다. 승인 워크플로우도 가능 — "프로덕션에 배포합니다. 확인하시겠습니까?" 구조화된 accept/decline으로.

제약: flat 객체에 primitive 타입(string, number, boolean)만. 중첩 객체, 배열 불가. 상호작용을 단순하고 예측 가능하게 유지하기 위함.

// Elicitation request example
const response = await client.request({
  method: "elicitation/create",
  params: {
    message: "Please confirm deployment details",
    requestedSchema: {
      type: "object",
      properties: {
        environment: { type: "string", description: "Target environment" },
        confirmed: { type: "boolean", description: "Proceed with deploy?" }
      },
      required: ["environment", "confirmed"]
    }
  }
});
// response.action: "accept" | "decline" | "cancel"

이전에는 도구 응답이 텍스트 기반 content 배열이었다. 클라이언트가 텍스트를 파싱해서 구조화된 데이터를 추출해야 했다 — 깨지기 쉽고, 오류 발생 확률 높고, 형식 의존적.

이제 도구가 outputSchema를 선언하고 사람이 읽는 content[]와 함께 structuredContent를 반환할 수 있다. SDK가 런타임에 structuredContent를 스키마 대비 검증하고, 위반 시 즉시 실패한다.

실무 영향: 다운스트림 시스템이 파싱 없이 도구 결과를 프로그래밍 방식으로 소비할 수 있다. 날씨 도구가 "22°C입니다"라는 텍스트 대신 {temperature: 22, unit: "celsius"}를 타입 데이터로 반환. 파이프라인 통합이 정규식 기반 대신 안정적으로.

핵심 규칙: outputSchema가 정의되면 structuredContent는 필수. 하지만 content[]도 여전히 필수 — 사람에게도 읽을 수 있는 출력이 필요하니까.

// Tool with structured output
server.tool("get-metrics", {
  outputSchema: {
    type: "object",
    properties: {
      activeUsers: { type: "number" },
      errorRate: { type: "number" },
      status: { type: "string", enum: ["healthy", "degraded", "down"] }
    },
    required: ["activeUsers", "errorRate", "status"]
  }
}, async () => ({
  content: [{ type: "text", text: "System healthy: 1,234 active users, 0.2% errors" }],
  structuredContent: { activeUsers: 1234, errorRate: 0.002, status: "healthy" }
}));

가장 단순하지만 잠재적으로 가장 큰 영향을 미치는 변경. 도구가 이제 네 가지 동작 속성을 선언할 수 있다:

- readOnlyHint: 이 도구는 데이터만 읽는가, 상태를 변경하는가? - destructiveHint: 이 도구가 데이터를 돌이킬 수 없게 파괴할 수 있는가? - idempotentHint: 실패 시 이 도구를 재시도해도 안전한가? - openWorldHint: 이 도구에 외부 부수 효과(이메일 발송, API 호출)가 있는가?

클라이언트는 이 어노테이션으로 UI를 조정한다. destructive 도구에는 확인 대화상자. read-only 도구는 물어보지 않고 자동 실행. idempotent 도구는 네트워크 오류 시 안전하게 재시도.

실무 영향: 클라이언트 코드 변경 없이 더 나은 UX. 서버가 의도를 선언하면 클라이언트가 적응한다. 특히 안전성에 중요 — delete-database 도구는 절대 자동 실행되면 안 된다.

기존 MCP 서버를 유지보수한다면:

1. 모든 도구에 behavior annotations를 추가하자. readOnlyHint와 destructiveHint부터 — UX 영향이 가장 즉각적이다. 2. structured output이 도움될 도구를 식별하자. 결과가 다른 시스템에 공급되는 도구가 대상이다. 3. elicitation으로 어색한 다단계 도구 체인을 대체할 수 있는지 생각해보자. 현재 매개변수 5개를 미리 요구하는 도구라면, 인터랙티브하게 물어보는 게 나을 수 있다.

새 MCP 서버를 만든다면:

- MCP Elicitation Form Builder 스킬로 elicitation 스키마 생성 - MCP Structured Output Validator 스킬로 outputSchema 정의 - MCP Tool Behavior Declarator 스킬로 모든 도구에 어노테이션

세 스킬 모두 카탈로그에서 CLAUDE.md 코드를 복사해 바로 사용할 수 있다.

이 세 기능은 명확한 방향을 시사한다: MCP가 "함수로서의 도구"에서 "인터랙티브 서비스로서의 도구"로 진화하고 있다. Elicitation이 대화를 추가하고, Structured Output이 계약을 추가하고, Behavior Annotations가 안전성 의미론을 추가한다.

다음 프론티어는 도구 합성(composition)일 가능성이 높다 — 도구가 다른 도구를 호출하고, elicitation과 structured output이 체인을 통해 흐르는 것. A2A(Agent-to-Agent) 프로토콜 논의가 이미 이 방향을 가리키고 있다.

지금 이 세 기능을 도입하면 MCP 서버가 앞서가고 다음에 올 것에 대비할 수 있다.