MCP tools resources prompts는 MCP 서버를 만들 때 가장 먼저 구분해야 하는 세 가지입니다. 이름만 보면 모두 모델에게 무언가를 제공하는 기능처럼 보이지만, 실제 역할은 꽤 다릅니다.
tools는 모델이 호출하는 행동이고, resources는 모델에게 넣을 수 있는 맥락이며, prompts는 사용자가 고르는 작업 템플릿에 가깝습니다. 이 구분이 흐려지면 MCP 서버는 금방 애매해집니다.
이 글은 MCP 스펙을 줄줄이 요약하기보다, 서버를 설계할 때 무엇을 tool로 만들고 무엇을 resource나 prompt로 남겨야 하는지 판단하는 기준을 정리합니다.
MCP tools resources prompts 차이를 먼저 한 장으로 보기
MCP tools resources prompts의 핵심 차이
MCP 공식 문서는 tools를 모델이 호출할 수 있는 기능으로 설명합니다. 예를 들면 날씨 조회, 데이터베이스 질의, 파일 생성, 외부 API 호출처럼 결과를 만들거나 시스템 상태를 바꿀 수 있는 행동입니다.
resources는 파일, 문서, 데이터베이스 스키마, 애플리케이션 정보처럼 모델이 읽을 수 있는 맥락입니다. 사용자가 선택하거나 애플리케이션이 판단해서 대화 context에 넣을 수 있습니다.
prompts는 구조화된 메시지 템플릿입니다. slash command처럼 사용자가 특정 작업을 선택하면, 서버가 미리 정의한 지시와 입력 형식을 제공하는 방식으로 이해하면 쉽습니다.
가장 단순한 판단 기준은 이렇습니다. 모델이 실행해야 하면 tool, 모델이 읽어야 하면 resource, 사용자가 시작할 작업 흐름이면 prompt입니다.
tool로 만들면 모델이 행동을 고를 수 있다
tool은 MCP 서버에서 가장 강한 인터페이스입니다. 모델은 도구 목록을 보고 현재 요청에 맞는 tool을 선택할 수 있고, tool input schema에 맞춰 인자를 채워 호출합니다.
그래서 tool은 단순 조회에도 쓸 수 있지만, 시스템에 영향을 주는 작업이라면 더 신중해야 합니다. 공식 문서도 trust and safety 관점에서 사용자가 tool invocation을 거절할 수 있는 human-in-the-loop 흐름을 권장합니다.
{
"name": "create_issue",
"description": "Create a GitHub issue in the current repository",
"inputSchema": {
"type": "object",
"properties": {
"title": { "type": "string" },
"body": { "type": "string" }
},
"required": ["title", "body"]
}
}이 예시는 명확히 tool입니다. 모델이 사용자의 의도를 판단해 issue를 만들 수 있고, 실행 결과가 외부 시스템에 남기 때문입니다. 이런 tool은 이름, 설명, schema, 승인 UI까지 함께 설계해야 합니다.
resource는 모델이 읽는 맥락이다
resource는 tool보다 수동적입니다. 모델이 호출해서 행동을 수행한다기보다, 클라이언트나 사용자 선택에 의해 모델에게 제공되는 context에 가깝습니다.
프로젝트 README, API 스키마, 설정 파일, 릴리스 노트, 데이터베이스 테이블 정의는 resource로 잘 맞습니다. 모델이 읽어야 하는 자료이지, 매번 실행해야 하는 행동은 아니기 때문입니다.
resource://project/README.md
resource://database/schema/users
resource://docs/release-notes/latestresource를 잘 나누면 모델에게 필요한 문서만 넣을 수 있습니다. 반대로 모든 것을 tool로 만들면 모델이 호출해야 할 행동과 읽어야 할 자료가 섞여 선택이 어려워집니다.
prompt는 사용자가 고르는 작업 템플릿이다
prompt는 반복되는 작업 절차를 표준화하는 데 좋습니다. 예를 들어 코드 리뷰, 릴리스 노트 작성, 장애 보고서 정리처럼 시작 형식이 정해져 있는 작업입니다.
prompt를 tool로 만들 수도 있지 않을까 생각할 수 있습니다. 하지만 prompt는 실행보다 작업 시작 템플릿에 가깝습니다. 사용자가 명시적으로 고르고, 서버가 필요한 메시지 구조를 만들어 주는 흐름입니다.
예를 들어 `/review-pr` 명령이 있다면 prompt는 리뷰 관점, 필요한 입력, 출력 형식을 제공하고, 실제 PR diff를 가져오는 작업은 별도 tool이나 resource와 연결할 수 있습니다.
서버 설계에서 자주 하는 실수
- 문서를 모두 tool로 만든다: 읽기 자료까지 호출 행동처럼 보이면서 모델 선택이 어려워진다
- 위험한 쓰기 작업을 확인 없이 tool로 연다: 파일 삭제, 배포, 결제, 공개 발행 같은 작업은 승인 흐름이 필요하다
- prompt에 최신 데이터를 하드코딩한다: 바뀌는 데이터는 resource나 tool에서 가져오게 하는 편이 낫다
- tool 설명을 너무 추상적으로 쓴다: 모델이 언제 호출해야 하는지 판단하기 어려워진다
실무 판단표
- 사용자가 선택하는 반복 업무 절차인가? prompt 후보
- 모델이 읽어야 하는 문서나 상태인가? resource 후보
- 모델이 외부 시스템에 요청을 보내거나 계산을 수행해야 하는가? tool 후보
- 실행 결과가 되돌리기 어렵거나 공개적으로 남는가? tool이더라도 승인 흐름 필요
- 한 번 가져온 뒤 여러 답변에서 참고할 자료인가? resource로 시작하는 편이 안전
정리
MCP tools resources prompts를 구분하는 일은 스펙 암기가 아니라 서버의 책임을 나누는 일입니다. tool은 행동, resource는 맥락, prompt는 작업 템플릿입니다.
처음 MCP 서버를 설계한다면 모든 기능을 tool로 만들기보다, 읽기 자료와 실행 행동을 먼저 분리하는 편이 좋습니다. 그 다음 반복 업무를 prompt로 묶으면 모델이 호출할 행동과 사용자가 선택할 workflow가 깔끔하게 나뉩니다.
함께 보면 좋은 글: MCP란 무엇인가, MCP 보안은 왜 중요할까
