MCP 서버에 자료 조회와 작업 실행을 노출하려 합니다. tools·resources·prompts는 어떻게 구분하나요?

tools는 인자를 받아 함수를 실행하는 인터페이스이고, resources는 URI 등으로 식별되는 자료를 읽는 인터페이스이며, prompts는 사용자가 선택해 활용할 수 있는 메시지 템플릿입니다. 셋은 실행·자료·재사용 가능한 요청 형식을 구분하는 기본 역할입니다. 그러나 실제 host가 어떤 기능을 노출하고 언제 모델에 넣는지는 구현 정책에 달려 있으므로 이름만으로 자동 실행이나 안전성을 단정하지 않습니다.

사용자 의도에 맞는 표현

사내 규정 원문은 resource로 읽고, 기간을 조건으로 이슈를 검색하는 기능은 tool로 제공할 수 있습니다. 코드 리뷰 요청의 입력 형식을 일정하게 만드는 템플릿은 prompt에 어울립니다. 검색 결과도 자료이지만 질의 인자와 실행 비용이 있는 검색 API를 tool로 제공하는 것은 자연스럽습니다. 같은 데이터를 반드시 하나의 종류로만 제공해야 하는 것이 아니라 사용 방식과 클라이언트 지원을 기준으로 결정합니다.

resource를 읽었다고 모델이 그것을 이미 문맥에 넣었다는 뜻은 아닙니다. host가 어떤 구간을 어떤 신뢰 수준으로 넣을지 선택해야 합니다. prompt 역시 사용자가 선택한 템플릿이지 원격 서버가 host의 정책을 덮어쓰는 권한이 아닙니다. tools의 읽기·파괴적 변경 같은 주석은 실행 정책의 참고 자료일 뿐, 실제 서버의 인가와 구현 검증을 대신하지 않습니다.

발견·조회·실행의 비용

목록에서 기능을 발견하는 것, 원문을 읽는 것, 변경 도구를 실행하는 것은 권한과 비용이 다릅니다. 대형 resource는 페이지나 범위 조회, 안정적인 문서 ID와 잘림 표시를 제공하고, 검색 결과는 다음 조회에 사용할 참조를 돌려줄 수 있습니다. 비공개 문서의 제목이나 템플릿 메타데이터도 노출할 수 있는지 확인합니다. 도구 목록에 보인다는 이유로 모든 사용자가 실행할 수 있다고 판단하지 않습니다.

2026-07-28 명세는 목록·자료의 캐시 힌트와 요청별 계약 등 이전 리비전과 다른 요소를 포함합니다. 실제 시스템에서는 리비전을 고정해 기능 발견·권한 변경·자료 갱신이 반영되는지를 시험하겠습니다. 목록을 오래 캐시하면 삭제한 도구를 모델이 호출할 수 있고, 원문을 오래 캐시하면 낡은 정책을 답할 수 있습니다. 자료와 기능을 표준 형식으로 나누는 것은 통합을 쉽게 하지만, 최신성·인가·모델 입력 선택은 여전히 host와 서버가 함께 설계해야 합니다.

실행 사례로 확인합니다

같은 규정 문서를 prompt 본문에 복사하고 resource에도 제공하면 어느 쪽이 최신인지 달라질 수 있습니다. 템플릿은 작업 입력의 구조를 제공하고 최신 규정은 안정적인 resource 참조로 읽는 방식을 검토할 수 있습니다. 반대로 작은 고정 예시는 템플릿에 두는 것이 간단합니다. 두 선택의 갱신 책임과 캐시 수명을 정하고, 읽기 결과에 버전과 출처를 남깁니다. tool이 자료를 반환해도 결과의 신뢰 수준은 외부 데이터이며, resource가 파일 URI를 쓴다고 host의 임의 파일 접근권한을 얻는 것은 아닙니다. 인터페이스 종류는 사용자 경험과 발견 방식을 돕는 분류이지 권한의 우회 경로가 되어서는 안 됩니다.