mcp-content-ops

에이전트가 CMS 콘텐츠를 다룰 수 있게 해주는 MCP 서버입니다. 도구 자체는 단순합니다 — 검색, 읽기, 초안 작성, 필드 설정, 게시. 실제로 고민이 필요했던 부분은 그 어떤 도구가 실행되기 전에 일어나는 일입니다.

우리가 살펴본 대부분의 콘텐츠 MCP 서버는 모델에게 API 클라이언트와 통합 계정이 가진 권한(보통 CMS에서는 모든 권한)을 그대로 부여합니다. 데모는 잘 작동합니다. 그러다 누군가 에이전트에게 "제품 페이지를 정리해줘"라고 요청하면, 시스템 어디에도 그렇게 하면 안 된다고 명시된 것이 없기 때문에 에이전트는 초안 40개를 게시해버립니다.

범위 설정

네 가지 게이트가 순서대로 적용되며, 그중 어느 것도 도구 스키마에 존재하지 않습니다:

1. 인자 검증 — 게시된 스키마를 기준으로 수행됩니다. 알 수 없는 속성은 무시되지 않고 거부됩니다. 인자를 임의로 만들어내는 모델은 도구를 오해한 것이며, 조용히 무시하면 그 사실이 숨겨집니다.

2. 기본 거부. 구성에서 활성화하지 않는 한 쓰기는 꺼져 있습니다. Policy 어디에도 허용적 기본값은 없습니다.

3. 타입 및 필드 허용 목록. 타입이 읽기 가능하다고 해서 쓰기 가능한 것은 아니며, 쓰기 가능한 타입이라고 해서 그 타입의 모든 필드가 쓰기 가능한 것도 아닙니다.

4. 모든 호출에 대한 구조화된 감사 — 허용 여부와 관계없이, 그 이유와 함께 기록됩니다.

호출이 판단되는 기준이 되는 타입은 인자가 아니라 저장된 항목에서 가져옵니다. 호출자가 자신이 편집하는 대상의 종류를 스스로 주장하게 두는 것은, 호출자가 어떤 정책이 적용될지 선택하게 두는 것과 같습니다.

거부된 호출은 JSON-RPC 오류가 아닌 isError가 설정된 일반 도구 결과로 반환됩니다. 모델은 거부된 이유를 확인하고 적응해야 합니다. 프로토콜 오류는 클라이언트가 고장났다는 뜻이며, 이는 다른 차원의 문제입니다.

Related MCP server: ToolBridge

실행 방법

pip install -e ".[dev]"
python -m content_ops.server policy.example.json
pytest -q

그 뒤에 있는 CMS는 cms.py의 인메모리 스텁입니다 — 메서드 네 개뿐이며, 콘텐츠 API로 교체하면 됩니다.

제공하지 않는 것

삭제 도구는 의도적으로 없습니다. 리소스나 프롬프트도 없고 도구만 있습니다. 인증도 없습니다. 이 서버는 stdio 서버이며 신뢰 경계는 이 서버를 실행한 프로세스입니다. 스키마 검증기는 우리 자체 도구 스키마가 사용하는 하위 집합만 다루며 JSON Schema 전체를 다루지는 않습니다.

SDK를 사용하지 않는 이유

MCP Python SDK는 훌륭하며 더 큰 서버라면 그것이 올바른 선택입니다. 이 서버는 stdio 위에서 세 가지 메서드를 구현하며, 와이어 형식이 충분히 작아서 SDK들이 현재 움직이는 속도로 움직이는 의존성이 더 큰 위험이었습니다.