# slima [Health: Active]

**Category:** 💻 Developer Tools  
**Repository:** https://github.com/slima-ai/slima-mcp  
**GitHub Stars:** 1  
**npm Downloads (last month):** 1034  
**Views:** 1  
**Installs:** 0  
**Upvotes:** 0  
**Directory Page:** https://allmcps.com/mcp/slima

## Description
MCP Server for Slima - AI Writing IDE for Novel Authors with AI Beta Reader.

## Tools
Capabilities this server exposes over MCP:

- **get_capabilities** — What this Slima server supports: which file extensions an AI may write, the content types, the available tools, and the guide index.

Call this once at the start of a Slima session, before writing anything. Every field is derived from the contract the server actually enforces, so it cannot drift from real behaviour the way a written description can.
- **list_guides** — List the available Slima guides: titles and one-line summaries of when to load each.

Guides teach how to operate Slima — file structure, version control, team knowledge bases, the relationship-map format. Load one with `load_guide` when you are about to do the thing it covers.
- **load_guide** — Load one Slima guide in full.

Read `book-structure` before creating files, `version-control-basics` before a large rewrite, `team-knowledge-base` when working in a publisher's team, `beta-reader` before spending the author's credits on a report. `list_guides` has the current set.
- **list_writing_skills** — List Slima's writing skills — the craft procedures the in-app coach follows for tasks like developing a character, revising a scene, or diagnosing pacing.

Use these when the task is about the WRITING. Use `list_guides` when the task is about operating Slima.
- **load_writing_skill** — Load one writing skill in full — a step-by-step procedure plus the questions a coach would ask.

Follow it rather than summarising it at the author.
- **create_book** — Create a new **Writing Studio** book in your Slima library.

Only Writing Studio (free-form novels / long-form prose) books can be created via MCP.
To create a **Script Studio** book (screenwriting with structured series/seasons/episodes/scenes),
please use the Slima app UI — MCP does not yet support Script Studio scaffolding.
- **list_books** — List the books in your Slima library. Results are paginated; if the response says more books exist, call again with the next `page` before concluding a book is not there.
- **get_book** — Get details of a specific book
- **get_book_structure** — Get the file/folder structure of a book
- **get_writing_stats** — Get word-count totals for a book.

Reports the book's authoritative totals only. Do NOT compute "progress", "words
written today", or a writing streak from commit history — Slima prunes intra-day
commits after 30 days, so any delta derived from "the last N commits" silently
changes span over time and will not match what the author sees in the app. Those
figures are account-level and are not exposed here.
- **list_teams** — List the teams this account belongs to — publishers, studios, writing groups.

A team book carries house rules and shared knowledge that change how you should write for it. If a book belongs to a team, read `list_team_rules` before writing.
- **get_team** — Get one team: its members and their roles.
- **list_team_rules** — The team's coaching rules — its house style — each marked mandatory or advisory.

Read these BEFORE writing for a team book, not after a draft is rejected. Mandatory rules are not suggestions: prose that ignores one gets re-edited by a person, which is worse than not writing it.
- **list_team_memories** — What the team has established over time: recurring characters, naming conventions, continuity spanning books, decisions already argued through.

Treat these as settled. If one contradicts a book's text, say so rather than picking a side.
- **list_team_skills** — The team's own writing procedures.

Some are marked `confidential: true` and come back WITHOUT a source path; their file contents are withheld from this connection. That is deliberate, and it does not stop the skill working — the server applies it on the team's behalf. Do not try to reconstruct one, reproduce it verbatim, or reach its contents by another route: those routes are closed and audited. Read the `team-knowledge-base` guide before working in a team knowledge base.
- **list_notes** — The author's margin notes on this book — book-level and chapter-level, including foreshadowing pairs.
- **create_note** — Leave a note beside the manuscript. Notes do not touch the prose or the word count.

Use `note_type: "chapter"` with the file's token in `file_id` to anchor it to one chapter; `"book"` for the work as a whole. Do not use notes as your own scratchpad — they appear in the author's interface as their own thinking. See the `notes-and-foreshadowing` guide.
- **semantic_search** — Find passages by MEANING rather than by the words used.

`search_content` finds the word an author typed; this finds the passage they meant — "where does the mother's resentment surface?" returns the scene even when neither word appears in it. On a team knowledge base it is the difference between browsing and asking.

Costs a small embedding charge, unlike literal search. Returns §N paragraph anchors so you can quote them back precisely.
- **list_comments** — Editorial comment threads on this book, open and resolved.

Read these before starting work on a book you have been handed — they are where an editor has already said what is wrong, and producing an independent list without reading them usually contradicts a decision someone already made.
- **create_comment** — Leave an editorial comment.

Comment when the change is a judgement call — pacing, whether a motivation lands, whether a scene earns its length. Edit the file instead when the author asked for the change. When unsure, comment: a comment costs ten seconds to dismiss, an unwanted rewrite costs the author a diff of their own prose.
- **resolve_comment** — Mark a comment thread addressed.

Say what you did when you resolve one. A silent resolve tells the editor nothing about whether you understood the note.
- **reopen_comment** — Reopen a comment thread that was resolved but should not have been.
- **get_chapter** — Read a chapter or file from a book. Accepts a full path, or just a filename if you are not sure of the folder. If you already know the exact path, `read_file` is equivalent and more direct.
- **list_personas** — List available virtual reader personas for beta reading feedback
- **analyze_chapter** — Get AI Beta Reader feedback on a chapter from a specific reader persona. This may take a moment to complete.

**Not supported for Script Studio books** (`book_type: "script"`) — AI Beta Reader is a Writing Studio feature and does not yet parse `.scene` or `series.json` structures. Use the Script Studio UI's built-in analysis for screenplays.
- **get_reader_test** — Collect an AI Beta Reader report by its test token — for a report that analyze_chapter started but did not finish inside its wait window.

Use this rather than calling analyze_chapter again: the report is already running server-side and has already been charged. Re-running starts a second report and charges again.
- **read_file** — Read the content of any file in a book by its path. For `.map` relationship graphs, prefer `view_relationship_map` — this tool returns their raw JSON (node ids and pixel coordinates), which is hard to reason about.
- **write_file** — Replace the entire content of an existing file (creates a new commit).

**IMPORTANT — Script Studio books (`book_type: "script"`):**
Writes are restricted to `.script_studio/planning/**/*` only.
Structured files (`series.json`, `*.character`, `*.scene`, `*.storyline`, `*.note`, `*.location`, `season.json`, `episode.json`) are READ-ONLY via MCP — structural edits must go through the Script Studio UI.
The sentinel file `.script_studio/planning/.initialized` is also read-only (frontend bootstrap marker).
Attempting to write outside `planning/` returns HTTP 400 with code `INVALID_PATH`.
For per-book details, read resource `slima://books/{book_token}/schema`.

For Writing Studio books (`book_type: "book"`), all paths remain writable.
Always check `book_type` via `list_books` or `get_book` before writing to an unfamiliar book.

**Not every file type takes a generic write.**
- Field-level tools only: `.beats` → `update_beat_board`, `.timeline` → `update_timeline`, `.script` → `update_script`, `.map` → `update_relationship_map`, `.geomap` → `update_world_map`
- Not writable at all: `.character`, `.location`, `.json`, `.yaml`, `.yml`
- `.map` is the character relationship graph (關係圖) — not a geographic map; `.geomap` is the world map (地圖).

A refusal names the file type and what to do instead — it is information, not
an obstacle to route around. Call `get_capabilities` for the authoritative
table; this list ships with the client and can lag a deploy.
- **edit_file** — Replace a specific text segment in a file (search and replace). Use this for precise edits instead of rewriting the whole file.

The replacement is performed by the server inside a lock, so the reported count is what was actually written — not a local guess. If the text is missing or ambiguous the call fails with a message telling you what to do next; act on it rather than retrying the same arguments.

**IMPORTANT — Script Studio books (`book_type: "script"`):**
Writes are restricted to `.script_studio/planning/**/*` only.
Structured files (`series.json`, `*.character`, `*.scene`, `*.storyline`, `*.note`, `*.location`, `season.json`, `episode.json`) are READ-ONLY via MCP — structural edits must go through the Script Studio UI.
The sentinel file `.script_studio/planning/.initialized` is also read-only (frontend bootstrap marker).
Attempting to write outside `planning/` returns HTTP 400 with code `INVALID_PATH`.
For per-book details, read resource `slima://books/{book_token}/schema`.

For Writing Studio books (`book_type: "book"`), all paths remain writable.
Always check `book_type` via `list_books` or `get_book` before writing to an unfamiliar book.

**Not every file type takes a generic write.**
- Field-level tools only: `.beats` → `update_beat_board`, `.timeline` → `update_timeline`, `.script` → `update_script`, `.map` → `update_relationship_map`, `.geomap` → `update_world_map`
- Not writable at all: `.character`, `.location`, `.json`, `.yaml`, `.yml`
- `.map` is the character relationship graph (關係圖) — not a geographic map; `.geomap` is the world map (地圖).

A refusal names the file type and what to do instead — it is information, not
an obstacle to route around. Call `get_capabilities` for the authoritative
table; this list ships with the client and can lag a deploy.
- **create_file** — Create a new file in a book (creates a new commit).

**Writing a chapter? Pass `content_type: "manuscript"`.** Files default to
"reference" (not counted in the author's word count, streak, or manuscript export)
unless they inherit a manuscript folder or you say otherwise.

**IMPORTANT — Script Studio books (`book_type: "script"`):**
Writes are restricted to `.script_studio/planning/**/*` only.
Structured files (`series.json`, `*.character`, `*.scene`, `*.storyline`, `*.note`, `*.location`, `season.json`, `episode.json`) are READ-ONLY via MCP — structural edits must go through the Script Studio UI.
The sentinel file `.script_studio/planning/.initialized` is also read-only (frontend bootstrap marker).
Attempting to write outside `planning/` returns HTTP 400 with code `INVALID_PATH`.
For per-book details, read resource `slima://books/{book_token}/schema`.

For Writing Studio books (`book_type: "book"`), all paths remain writable.
Always check `book_type` via `list_books` or `get_book` before writing to an unfamiliar book.

**Not every file type takes a generic write.**
- Field-level tools only: `.beats` → `update_beat_board`, `.timeline` → `update_timeline`, `.script` → `update_script`, `.map` → `update_relationship_map`, `.geomap` → `update_world_map`
- Not writable at all: `.character`, `.location`, `.json`, `.yaml`, `.yml`
- `.map` is the character relationship graph (關係圖) — not a geographic map; `.geomap` is the world map (地圖).

A refusal names the file type and what to do instead — it is information, not
an obstacle to route around. Call `get_capabilities` for the authoritative
table; this list ships with the client and can lag a deploy.
- **delete_file** — Delete a file or an empty folder from a book (creates a new commit).

A folder that still has anything inside it is refused unless you pass
`recursive: true`. That is not bureaucracy: deleting only the folder would
leave its contents with no parent, and the app then shows the whole subtree at
the book's top level — the author sees their files scattered, with no error.
Say the word and everything inside goes, and you are told how many.

**IMPORTANT — Script Studio books (`book_type: "script"`):**
Writes are restricted to `.script_studio/planning/**/*` only.
Structured files (`series.json`, `*.character`, `*.scene`, `*.storyline`, `*.note`, `*.location`, `season.json`, `episode.json`) are READ-ONLY via MCP — structural edits must go through the Script Studio UI.
The sentinel file `.script_studio/planning/.initialized` is also read-only (frontend bootstrap marker).
Attempting to write outside `planning/` returns HTTP 400 with code `INVALID_PATH`.
For per-book details, read resource `slima://books/{book_token}/schema`.

For Writing Studio books (`book_type: "book"`), all paths remain writable.
Always check `book_type` via `list_books` or `get_book` before writing to an unfamiliar book.

**Not every file type takes a generic write.**
- Field-level tools only: `.beats` → `update_beat_board`, `.timeline` → `update_timeline`, `.script` → `update_script`, `.map` → `update_relationship_map`, `.geomap` → `update_world_map`
- Not writable at all: `.character`, `.location`, `.json`, `.yaml`, `.yml`
- `.map` is the character relationship graph (關係圖) — not a geographic map; `.geomap` is the world map (地圖).

A refusal names the file type and what to do instead — it is information, not
an obstacle to route around. Call `get_capabilities` for the authoritative
table; this list ships with the client and can lag a deploy.
- **append_to_file** — Append content to the end of an existing file (creates a new commit).

Appending is NOT idempotent: sending the same call twice writes the text twice. If a call was blocked, timed out, errored, or you are not sure whether it went through, call `read_file` on the file first and check whether your text is already there; resend only if it is missing.
To make a resend safe, pass `base_version` — the Version printed by `read_file` or by your previous `append_to_file`. If the file has changed since that version, nothing is appended and you are told to check.

**IMPORTANT — Script Studio books (`book_type: "script"`):**
Writes are restricted to `.script_studio/planning/**/*` only.
Structured files (`series.json`, `*.character`, `*.scene`, `*.storyline`, `*.note`, `*.location`, `season.json`, `episode.json`) are READ-ONLY via MCP — structural edits must go through the Script Studio UI.
The sentinel file `.script_studio/planning/.initialized` is also read-only (frontend bootstrap marker).
Attempting to write outside `planning/` returns HTTP 400 with code `INVALID_PATH`.
For per-book details, read resource `slima://books/{book_token}/schema`.

For Writing Studio books (`book_type: "book"`), all paths remain writable.
Always check `book_type` via `list_books` or `get_book` before writing to an unfamiliar book.

**Not every file type takes a generic write.**
- Field-level tools only: `.beats` → `update_beat_board`, `.timeline` → `update_timeline`, `.script` → `update_script`, `.map` → `update_relationship_map`, `.geomap` → `update_world_map`
- Not writable at all: `.character`, `.location`, `.json`, `.yaml`, `.yml`
- `.map` is the character relationship graph (關係圖) — not a geographic map; `.geomap` is the world map (地圖).

A refusal names the file type and what to do instead — it is information, not
an obstacle to route around. Call `get_capabilities` for the authoritative
table; this list ships with the client and can lag a deploy.
- **view_relationship_map** — See a `.map` character-relationship graph as a picture plus a readable summary.

Use this instead of `read_file` for `.map` files: their raw JSON is node ids and pixel coordinates.
The summary lists every character, every relationship ("A —childhood friends→ B") and any faction groups,
so it is useful even in clients that do not display images.

To change one, use `update_relationship_map` (one field at a time). A `.map` is the relationship graph (關係圖), not a geographic map — that is `.geomap`.
- **search_content** — Search for content across all files in a book.

**Script Studio behavior:** By default, structured files (`*.character`, `*.scene`, `*.storyline`, `*.note`, `*.location`, and `*.json` under `.script_studio/`) are **excluded** from search results — their raw JSON is noisy and not useful for full-text search.
Pass `include_structured: true` to search those files too.
Writing Studio books are unaffected by this filter.
- **update_beat_board** — Change a Slima beat board (`.beats`) one field at a time.

This is the ONLY way to write this file type — `write_file` and `edit_file`
are refused for it, because a whole-file write would drop the parts of the
document you were never shown.

Operations: add_act, update_act, remove_act, add_beat, update_beat, remove_beat, move_beat
Example `operations`: [{"op": "add_act", "name": "Act Two", "op_ref": "A2"}, {"op": "add_beat", "title": "The turn", "act_id": "@A2"}]

**Read the file first.** Every id you send must come from that read — never
invent one, never retype one from memory. An unknown id is refused with the
list of real ones, so a mistake costs a round trip, not the author's data.

**One operation per change.** Each operation takes only its own arguments; a
field belonging to a different operation is refused rather than ignored.

**`op_ref` chains within one batch.** Label what an operation creates with
`op_ref: "A2"`, then a LATER operation can point at it as `"@A2"`. Backward
references only, and only inside this one batch — a later call must use the
real id, which comes back in `applied`.

**The batch is all-or-nothing.** If one operation fails nothing is written, so
you never have to work out how far it got.

**Unlike the in-app assistant, there is no review panel here.** What you send
lands in the author's version history immediately. Say what you changed, not
"please confirm it".
- **update_timeline** — Change a Slima timeline (`.timeline`) one field at a time.

This is the ONLY way to write this file type — `write_file` and `edit_file`
are refused for it, because a whole-file write would drop the parts of the
document you were never shown.

Operations: add_entry, update_entry, remove_entry, set_config
Example `operations`: [{"op": "add_entry", "title": "The siege begins", "time_mode": "label", "time_label": "Winter"}]

**Read the file first.** Every id you send must come from that read — never
invent one, never retype one from memory. An unknown id is refused with the
list of real ones, so a mistake costs a round trip, not the author's data.

**One operation per change.** Each operation takes only its own arguments; a
field belonging to a different operation is refused rather than ignored.

**`op_ref` chains within one batch.** Label what an operation creates with
`op_ref: "A2"`, then a LATER operation can point at it as `"@A2"`. Backward
references only, and only inside this one batch — a later call must use the
real id, which comes back in `applied`.

**The batch is all-or-nothing.** If one operation fails nothing is written, so
you never have to work out how far it got.

**Unlike the in-app assistant, there is no review panel here.** What you send
lands in the author's version history immediately. Say what you changed, not
"please confirm it".
- **update_script** — Change a Slima screenplay (`.script`) one field at a time.

This is the ONLY way to write this file type — `write_file` and `edit_file`
are refused for it, because a whole-file write would drop the parts of the
document you were never shown.

Operations: add_scene, update_scene_heading, remove_scene, add_element, update_element, remove_element
Example `operations`: [{"op": "add_scene", "interior": true, "location": "HARBOUR", "op_ref": "S1"}, {"op": "add_element", "scene_id": "@S1", "type": "action", "text": "The fog lifts."}]

**Read the file first.** Every id you send must come from that read — never
invent one, never retype one from memory. An unknown id is refused with the
list of real ones, so a mistake costs a round trip, not the author's data.

**One operation per change.** Each operation takes only its own arguments; a
field belonging to a different operation is refused rather than ignored.

**`op_ref` chains within one batch.** Label what an operation creates with
`op_ref: "A2"`, then a LATER operation can point at it as `"@A2"`. Backward
references only, and only inside this one batch — a later call must use the
real id, which comes back in `applied`.

**The batch is all-or-nothing.** If one operation fails nothing is written, so
you never have to work out how far it got.

**Unlike the in-app assistant, there is no review panel here.** What you send
lands in the author's version history immediately. Say what you changed, not
"please confirm it".
- **update_relationship_map** — Change a Slima relationship map (`.map`) one field at a time.

**This is the character relationship graph (關係圖) — not a geographic map.** A world map
(地圖) is `.geomap`, changed with `update_world_map`.

This is the ONLY way to write this file type — `write_file` and `edit_file`
are refused for it, because a whole-file write would drop the parts of the
document you were never shown.

Operations: add_node, update_node, move_node, remove_node, add_edge, update_edge, remove_edge, add_group, update_group, remove_group, set_meta
Example `operations`: [{"op": "add_node", "label": "Lin Shuang", "op_ref": "N1", "position": {"near_id": "<id of Shen Yan>", "direction": "right"}}, {"op": "add_edge", "source_id": "<id of Shen Yan>", "target_id": "@N1", "label": "mentor"}]

**Read the file first.** Every id you send must come from that read — never
invent one, never retype one from memory. An unknown id is refused with the
list of real ones, so a mistake costs a round trip, not the author's data.

**One operation per change.** Each operation takes only its own arguments; a
field belonging to a different operation is refused rather than ignored.

**`op_ref` chains within one batch.** Label what an operation creates with
`op_ref: "A2"`, then a LATER operation can point at it as `"@A2"`. Backward
references only, and only inside this one batch — a later call must use the
real id, which comes back in `applied`.

**The batch is all-or-nothing.** If one operation fails nothing is written, so
you never have to work out how far it got.

**Unlike the in-app assistant, there is no review panel here.** What you send
lands in the author's version history immediately. Say what you changed, not
"please confirm it".

**Position is content here, not layout.** `update_node` will not move anything — that is
`move_node`, so that "I moved her next to him" is its own reviewable change. Prefer
`{near_id, direction}` over computing numbers. Existing nodes never move; the final
coordinates come back in the notes. Group boxes are computed from `member_ids` — never
send x/y/width/height. Removing a node removes its edges, and you are told so.
- **update_world_map** — Change a Slima world map (`.geomap`) one field at a time.

**This is the geographic world map (地圖).** A character relationship graph (關係圖) is
`.map`, changed with `update_relationship_map`.

This is the ONLY way to write this file type — `write_file` and `edit_file`
are refused for it, because a whole-file write would drop the parts of the
document you were never shown.

Operations: add_place, update_place, add_label, update_label, remove_element, add_river, add_border, paint_region, set_meta
Example `operations`: [{"op": "add_place", "x": 210, "y": 96, "name": "Starhaven", "tier": "port"}, {"op": "add_label", "x": 240, "y": 60, "text": "The Cold Sea", "size": "large"}]

**Read the file first.** Every id you send must come from that read — never
invent one, never retype one from memory. An unknown id is refused with the
list of real ones, so a mistake costs a round trip, not the author's data.

**One operation per change.** Each operation takes only its own arguments; a
field belonging to a different operation is refused rather than ignored.

**`op_ref` chains within one batch.** Label what an operation creates with
`op_ref: "A2"`, then a LATER operation can point at it as `"@A2"`. Backward
references only, and only inside this one batch — a later call must use the
real id, which comes back in `applied`.

**The batch is all-or-nothing.** If one operation fails nothing is written, so
you never have to work out how far it got.

**Unlike the in-app assistant, there is no review panel here.** What you send
lands in the author's version history immediately. Say what you changed, not
"please confirm it".

**Coordinates are grid cells, not pixels**: x 0-519, y 0-363. `read_file` gives you the
map with its three terrain grids replaced by a note — they are machine-encoded and you
do not need them; `paint_region` works in cells. `remove_element` takes any element id
(`pl_` place, `lb_` label, `rv_` river, `bd_` border). Terrain has no undo: paint over it
instead. Move a place with `update_place`, never by removing and re-adding it. An unknown
place `tier` is refused with the full list of real ones — read the error, do not guess.

## Claude Desktop Quick Installation
Install path detected from listing signals. Uses `npx` (confidence: high):

```json
"mcpServers": {
  "slima": {
    "command": "npx",
    "args": ["-y","slima-mcp@0"],
    "env": {
      "SLIMA_API_TOKEN": ""
    }
  }
}
```

**Requires environment variables:** `SLIMA_API_TOKEN` — the values above are empty placeholders; fill in real credentials before running (see the repository for what each one is for).

## Documentation

## What slima MCP server does

slima connects AI clients to books stored in Slima, an AI writing IDE for novel authors. It exposes book management, manuscript file operations, writing guidance, search, planning artifacts, relationship maps, notes, and editorial comments through MCP tools.

The server works with both Writing Studio and Script Studio books, but the two formats have different permissions. Writing Studio books can be created through MCP and support reading and writing across paths. Script Studio books must be created in the Slima application, and MCP writes are limited to the `.script_studio/planning/**/*` area.

## How it works

Local clients launch the package as a stdio MCP server, commonly through `npx`. The hosted endpoint is available at `https://mcp.slima.ai/mcp` for clients that support remote MCP over HTTP. Remote connections use OAuth 2.0 with PKCE; local connections can authenticate with a Slima API token or a token saved by the package's authentication command.

After connection, an AI client can discover the server's capabilities, inspect available guides and writing skills, select a book, and operate on its files. Reading and writing are represented by separate tools. The server also exposes a per-book schema resource at `slima://books/{book_token}/schema`, which describes the paths permitted for that book.

## Setup and configuration

For Claude Desktop or Cursor, configure an MCP server that runs `npx -y slima-mcp@0` and provide `SLIMA_API_TOKEN` in its environment. The token can be obtained from Slima account settings, or authentication can be initiated with `npx slima-mcp@0 auth`. Gemini CLI can add the server with its MCP command or install the repository as an extension.

Web use is configured by adding `https://mcp.slima.ai/mcp` as a custom connector in Claude.ai or ChatGPT Web and completing the OAuth approval flow. The hosted connection does not require a token to be copied into the client. A self-hosted deployment is also possible by deploying the repository's Cloudflare Worker with Wrangler.

Use a major-version package range deliberately. A global `slima-mcp` installation can cause `npx` to reuse an older local copy, so global installations should be removed or updated when using the npx configuration.

## Tools and capabilities

- Inspect server capabilities, guides, and writing skills, then load selected guidance in full.
- Create books, list them with pagination, inspect metadata and structure, and retrieve writing statistics.
- Read chapters or arbitrary files; create, replace, edit, append to, and delete files where permissions allow.
- Search exact text across a book or find passages by semantic similarity.
- View and update relationship maps, beat boards, timelines, scripts, and world maps.
- List and create author notes, create editorial comments, and resolve comment threads.

## Limitations and notes

Script Studio books cannot be created through MCP. Structured Script Studio files, including character, scene, storyline, note, location, season, and episode files, are read-only through MCP; changes must be made in the Slima application. MCP writes for Script Studio are restricted to planning paths.

For Script Studio search, structured files are excluded unless `include_structured: true` is supplied. Chapter analysis through the AI Beta Reader applies to Writing Studio books and is not supported for structured Script Studio scenes. Deleting a file or folder is limited to files and empty folders.

_Full upstream README: https://allmcps.com/mcp/slima/readme_