MCP가 파일 종류별로 할 수 있는 일

한 줄로: 확장자별 전체 대조표입니다. MCP가 무엇을 읽고, 무엇을 통째로 쓰고, 무엇은 필드 단위 도구로만 고치고, 무엇은 아예 손대지 못하는지 정리했습니다.

기준이 바뀌었습니다

이 글은 예전에 「글쓰기 스튜디오 작품」과 「시나리오 스튜디오 작품」을 비교하는 글이었습니다. 4.0부터는 그 질문이 성립하지 않습니다. 글쓰기 스튜디오는 하나이고, 대본은 탐색기 안의 .script 파일입니다. 한 화에 한 파일입니다.

MCP가 무엇을 할 수 있는지 정하는 것은 이제 작품이 어느 스튜디오에 속하는지가 아닙니다. 손대려는 파일이 어떤 종류인지입니다.

전체 대조표

확장자	읽기	통째 쓰기(write_file / edit_file / append_to_file)	고치는 방법
.md .markdown .txt	✅	✅	그대로 쓰기
.map 관계도	✅	❌	update_relationship_map
.beats 비트 보드	✅	❌	update_beat_board
.timeline 연표	✅	❌	update_timeline
.script 대본	✅	❌	update_script
.geomap 세계 지도	✅	❌	update_world_map
.character .location	✅	❌	AI가 쓸 경로 없음
.json .yaml .yml	✅	❌	AI가 쓸 경로 없음
.png .jpg .jpeg .gif .pdf	✅	❌	AI가 쓸 경로 없음
그 밖의 확장자(.csv, 확장자 없는 파일…)	✅	✅	그대로 쓰기

마지막 줄은 의도한 결과입니다. 작가는 온갖 참고 파일을 작품 안에 넣어 둡니다. 아무도 구조화하지 않은 종류까지 막아 버리면, 있을지도 모르는 사고를 막으려고 실제로 하는 작업을 망치는 셈이 됩니다.

최종 근거는 이 표가 아니라 get_capabilities입니다. 그쪽은 이 서버가 실제로 집행하는 계약을 돌려줍니다. 가이드와 글쓰기 스킬을 참고하십시오.

세 종류, 세 가지 동작

산문 파일(.md / .markdown / .txt). read_file, edit_file, write_file, create_file, append_to_file, delete_file이 모두 동작합니다. 실무에서는 edit_file을 우선하십시오. 작가가 같은 파일을 고치고 있을 수 있는데, 기준점을 못 찾은 편집은 요란하게 실패하는 반면 통째 쓰기는 작가가 방금 타이핑한 문장을 조용히 덮어씁니다.

구조화 파일 다섯 종류. write_file, edit_file, append_to_file은 모두 거부되고, 변경은 한 번에 한 작업씩 들어갑니다. 예외 두 가지를 기억해 두십시오. create_file은 동작하지만 보낸 내용이 무시됩니다(서버가 빈 골격을 씁니다). 그리고 delete_file도 동작합니다(삭제는 종류 정책을 보지 않고 플랜만 봅니다). 쓰기와 삭제는 둘 다 구독 플랜에 속합니다. 구조화 편집 도구를 보십시오.

아예 쓸 수 없는 것. .character와 .location은 Slima 자체 편집기가 포맷을 소유합니다. .json과 .yaml은 설정과 데이터이고, 미디어 파일은 설명할 것도 없습니다. 읽을 수는 있고 쓸 수는 없으며, 필드 단위 대안도 없습니다.

글자 수는 어떻게 계산되는가

파일 종류에서 따라오는 이야기라 따로 짚어 둘 만합니다.

• .md / .markdown / .txt — 산문으로 계산
• .script — 신 안의 글자를 계산하며, 작가의 일일 글자 수와 연속 기록에 반영됩니다
• .map / .beats / .timeline / .geomap — 항상 0

그래서 AI가 관계도를 정리해 줘도 작가의 숫자에 가짜 성과가 남지 않습니다.

파일 종류를 따지지 않는 도구

파일이 아니라 작품을 대상으로 동작하는 도구 묶음이 따로 있고, 위 표는 거기에 적용되지 않습니다. list_books, get_book, get_book_structure, get_writing_stats, search_content, semantic_search, 메모, 코멘트, 그리고 규칙을 알려 주는 도구들입니다.

그중 몇 개는 특정 파일에서 다르게 동작합니다. 특정 파일에서 다르게 동작하는 도구들을 보십시오.

create_book은 글쓰기용 작품만 만듭니다

MCP가 만드는 것은 언제나 글쓰기 스튜디오 작품입니다. 예전 시나리오 스튜디오는 신규 작품을 받지 않습니다. 그러니 애초에 그쪽에 새로 만들 것도 없습니다. 4.0에서 대본을 쓰는 일은 작품 안에서 시작합니다. 탐색기에서 마우스 오른쪽 버튼을 누르고 「새 대본」을 고르면 .script 파일이 하나 생깁니다.

예전 시나리오 스튜디오 작품이 아직 남아 있다면

그 작품들은 여전히 열리고, MCP로 읽을 수도 있습니다. 다만 규칙 체계가 따로입니다. 위의 확장자 표와는 무관하고, 경로로 판단합니다.

동작	예전 시나리오 스튜디오 작품
모든 파일 읽기	✅ series.json, *.character, *.scene 포함
쓰기 / 수정 / 삭제	⚠️ .script_studio/planning/ 아래에서만
구조화 파일(series.json, season.json, episode.json, *.character, *.location, *.scene, *.storyline, *.note)	❌ MCP에서는 읽기 전용
.script_studio/planning/.initialized	❌ 읽기 전용(프런트엔드의 초기화 표식)
search_content	⚠️ 위 구조화 파일을 기본 제외. include_structured: true를 붙여야 포함
analyze_chapter	❌ 작품 전체에서 지원되지 않음

허용 범위 밖에 쓰면 400 INVALID_PATH가 옵니다. 개별 작품의 정확한 규칙은 작품에 직접 물어볼 수 있습니다. slima://books/{book_token}/schema 리소스를 읽으십시오. schema 리소스로 정확한 권한 확인하기를 보십시오.

get_book은 이런 작품에 대해 쓰기 제한 설명을 스스로 출력합니다. 그래서 손대기 전에 그것을 한 번 호출하는 것이 가장 빠른 확인 방법입니다.

관련 문서

• Docs: 구조화 편집 도구
• Docs: 구조화 파일 보호
• Docs: 특정 파일에서 다르게 동작하는 도구들
• Docs: 파일 조작 도구
• Docs: schema 리소스로 정확한 권한 확인하기
• Docs: 원고와 참고 자료