01-개념

01 — 무엇을 만들까

만들지 말지 먼저 결정

이 챕터의 가장 중요한 한 줄: 이미 있는지 다시 한 번 본다. 02-카탈로그 → Anthropic Registry → 벤더 공식 → awesome-mcp-servers. 그래도 없거나, 사내 시스템처럼 외부에 못 두는 경우가 만들 차례다.

도구(Tool)? 리소스(Resource)? 프롬프트(Prompt)? — 셋 중 무엇

세 원시(Primitives)는 호출 주체가 다르다 — mcp-quickstart-server, mcp-python-sdk.

원시	호출 주체	HTTP 비유	부작용	첫 선택?
Tool	모델(승인 후)	POST	가능	✅ 거의 항상
Resource	클라이언트	GET	없어야 함	데이터 노출이 주목적이면
Prompt	사용자가 선택	템플릿	없음	반복 작업 자동화 시

룰 오브 썸(rule of thumb): 처음에는 도구만 만든다. 안정되면 리소스·프롬프트를 점진 추가. 이것이 사양의 설계 원칙 4 “Features can be added progressively”의 실천이다.

좋은 도구의 속성

1. 좁은 책임 — 한 도구 = 한 동사 (create_invoice, search_users)
2. 명확한 입력 스키마 — 타입 힌트만으로 충분
3. 읽기/쓰기 분리 — list_*, get_*은 안전, create_*, delete_*는 위험
4. 반환은 텍스트 — LLM이 읽을 수 있어야 함. 큰 결과는 요약 + 페이지네이션
5. 멱등성 — 같은 입력에 같은 결과(가능하면)
6. 에러 메시지가 자기설명적 — “EACCES” 대신 “/foo 디렉터리 쓰기 권한 없음”

좋은 서버의 속성

설계 원칙 1·2를 다시 읽자 — mcp-architecture:

1. “Servers should be extremely easy to build” — 하나에 몰아넣지 마라
2. “Servers should be highly composable” — 여러 개로 쪼개라

→ 사내용 MCP를 만들 때도 **“한 서버 = 한 시스템”**으로 자른다. 사내 ERP MCP, 사내 검색 MCP, 사내 위키 MCP… 이렇게 셋이 낫다.

어떤 SDK?

	Python (mcp[cli])	TypeScript (@modelcontextprotocol/sdk)
개발 속도	⭐ 가장 빠름 (FastMCP 데코레이터)	빠름 (Zod 스키마)
배포 편의	uv/pip	npm/npx
에코시스템	httpx, pydantic	zod, fetch
추천	시작은 Python	노드 인프라가 이미 있다면

다음 챕터에서 둘 다 코드로 보여준다.

다음

• 02-구조