Allows using OpenAI-compatible APIs (or any API with similar interface) for generating chapter drafts.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@novel-mcp validate my novel project and build context for ch-0001"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
这是一套本地优先的逐章小说写作流程。章节计划、人物、世界观、风格和状态保存在小说项目目录中；初稿与审稿保存在运行目录中；正文经过人工确认后才进入正式稿并更新故事状态。
当前版本提供离线 Mock Provider，也支持 OpenAI-compatible 与 Anthropic API。Codex、Claude Code 和 WorkBuddy 可以通过同一个 MCP 服务参与写作。
Python 3.11 或更高版本
macOS、Windows 或 Linux
Related MCP server: Narrarium MCP Server
python -m pip install "git+https://github.com/YinFY90/novel-engine.git"也可以从 Releases 下载 .whl 文件：
python -m pip install novel_engine-0.1.0-py3-none-any.whlpython3 -m venv .venv
source .venv/bin/activate
python -m pip install -e '.[test]'py -3.11 -m venv .venv
.\.venv\Scripts\Activate.ps1
python -m pip install -e ".[test]"novel init "我的小说" --id my-novel --title "我的小说"
novel validate "我的小说"初始化后，在 plans/ch-0001.yaml 编写章节计划，在 canon/ 中维护人物、世界观和风格。
所有命令均可增加 --json，便于 Codex、Claude Code、WorkBuddy 或其他工具读取结果。
# 1. 组装上下文，输出中会返回 run_id
novel --json context "我的小说" ch-0001
# 2. 使用离线 Mock Provider 生成初稿
novel --json draft "我的小说" --run-id <run_id> --provider mock
# 3. 执行基础审稿
novel --json review "我的小说" --run-id <run_id>
# 4. 查看本次运行及正典差异
novel --json run-inspect "我的小说" <run_id>
# 5. 人工确认后提交正文、状态并创建快照
novel --json approve "我的小说" --run-id <run_id>确认前，manuscript/ 和 state/ 保持不变。确认后，本次初稿写入 manuscript/<chapter-id>.md，状态提案一次写入 state/，同时在 snapshots/ 保存恢复点。同一运行重复确认会返回已有结果。
API 模式由引擎调用已配置的模型生成初稿。密钥放在环境变量中，项目文件和运行记录不会保存密钥。
OpenAI-compatible：
export NOVEL_PROVIDER=openai-compatible
export NOVEL_API_KEY="<API key>"
export NOVEL_MODEL="<模型名称>"
export NOVEL_BASE_URL="<API 地址>"Anthropic：
export NOVEL_PROVIDER=anthropic
export ANTHROPIC_API_KEY="<API key>"
export NOVEL_MODEL="<模型名称>"Windows PowerShell 使用 $env:NOVEL_PROVIDER、$env:NOVEL_API_KEY、$env:NOVEL_MODEL 和 $env:NOVEL_BASE_URL 设置相同变量。
完整章节流程仍使用统一命令：
novel --json validate "我的小说"
novel --json context "我的小说" ch-0001
novel --json draft "我的小说" --run-id <run_id>
novel --json review "我的小说" --run-id <run_id>
novel --json run-inspect "我的小说" <run_id>
novel --json approve "我的小说" --run-id <run_id>writer、reviewer、settler 的模型配置可以分别保存；当前版本的 API 自动调用用于正文写作，审稿和状态整理继续使用可检查的本地规则与章节计划。人工确认是写入正式正文和故事状态的唯一入口。
命令参数可以覆盖项目与环境配置：
novel --json draft "我的小说" --run-id <run_id> \
--provider openai-compatible \
--model "<模型名称>" \
--base-url "<API 地址>"Codex、Claude Code、WorkBuddy 使用 novel-mcp 连接同一小说项目：
validate_project 检查项目。
build_context 创建章节运行并取得 run_id。
AI 工具自己写正文时调用 submit_draft；使用已配置 API 时调用 generate_draft。
review_run 生成审稿结果和状态提案。
inspect_run 检查本次运行，project_status 查看当前阶段。
用户明确接受正文后调用 approve_run。
三种工具的配置与项目调用规则位于：
所有入口共用 runs/、manuscript/、state/ 和 snapshots/。适配层只提供调用规则，不保存独立状态。
novel status "我的小说"
novel status "我的小说" --run-id <run_id>
novel run-inspect "我的小说" <run_id>examples/example-story 是一个完全虚构的最小示例，包含第一章章节计划、人物资料、世界规则、行文风格和初始状态。
可以复制整个目录，在副本中运行完整流程：
cp -R examples/example-story "示例故事"
novel validate "示例故事"
novel --json context "示例故事" ch-0001Windows PowerShell：
Copy-Item -Recurse examples\example-story "示例故事"
novel validate "示例故事"
novel --json context "示例故事" ch-0001novel-project/
├── novel.yaml # 项目信息
├── canon/ # 已确认的大纲、人物、世界观和风格
├── plans/ # 章节计划
├── manuscript/ # 已确认正文
├── state/ # 已确认故事状态
├── packs/ # 作品或类型规则包
├── runs/ # 每次运行的上下文、初稿、审稿和提案
└── snapshots/ # 确认时生成的恢复点项目目录可以整体复制到另一台电脑。项目内文件引用统一使用相对路径。
本项目参考了多个开源小说写作项目的工作流设计，包括可检查上下文、文件化记忆、连续性检查、审稿与回退机制。具体项目和借鉴内容见 ACKNOWLEDGMENTS.md。本仓库的代码、示例和文档独立维护，不包含这些项目的源码或作品内容。
测试只使用本地临时目录和 Mock Provider，不访问网络，也不读取密钥。
pytest跨平台 GitHub Actions 模板位于 ci/github-actions-tests.yml。仓库管理员获得 GitHub CLI 的 workflow 权限后，可将它放入 .github/workflows/tests.yml 启用。
Human approval gate: commit draft and proposed state exactly once and create a snapshot.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute or current-directory-relative novel project path. | |
| run_id | Yes | Run identifier returned by build_context. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It mentions 'exactly once', hinting at idempotency, but fails to state whether the action is destructive, what happens if called again, permission requirements, or side effects like creating a snapshot. This is insufficient for a critical gating action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence conveys the core action without superfluous words. Every part of the description delivers value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is somewhat lacking. It covers the main action but omits details on return structure, error cases, and behavioral constraints. For a gating tool, agents need more context about what 'commit' means and how the snapshot is used.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description adds meaning by explaining what the tool does with the parameters: commit draft and create snapshot. This provides context beyond the schema, earning a score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: acting as a human approval gate that commits draft and proposed state exactly once and creates a snapshot. It uses specific verbs ('commit', 'create') and resources ('draft and proposed state', 'snapshot'), distinguishing it from sibling tools like submit_draft or review_run.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., after which step), when not to use it, or how it fits into the workflow. The description leaves the usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a run and record an inspectable context packet for one chapter.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute or current-directory-relative novel project path. | |
| run_id | No | Run identifier returned by build_context. | |
| chapter_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears full responsibility for behavioral disclosure. It indicates mutation ('Create a run') but fails to explain idempotency, side effects, or the meaning of 'record an inspectable context packet.' The circular definition of run_id further obscures behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently communicates the core function with no redundant or extraneous information. It is optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (3 parameters, no output schema, no annotations, and several siblings), the description is under-specified. It does not explain what a 'run' is, how it relates to other tools, or what the output looks like, leaving agents without sufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 67% schema description coverage, the description should compensate for the undocumented chapter_id parameter. It does not; it merely mentions 'one chapter.' The run_id description in the schema is circular, and the tool description adds no clarification.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create a run and record an inspectable context packet for one chapter,' which clearly identifies the tool's primary action. It distinguishes from siblings like validate_project and generate_draft by focusing on run creation and context recording, but 'inspectable context packet' is somewhat vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as validate_project or generate_draft. It does not mention prerequisites, typical invocation order, or scenarios to avoid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate and record a draft with a configured provider; mock works offline.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute or current-directory-relative novel project path. | |
| run_id | Yes | Run identifier returned by build_context. | |
| provider | No | mock |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool generates and records a draft, implying mutation, and notes mock offline capability. However, without annotations, it should also explain safety (e.g., overwriting behavior), prerequisites, or side effects. The current description leaves behavioral assumptions ambiguous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with a single sentence that covers the action and a key behavioral note. It is front-loaded with the purpose. However, it may be too terse, missing details that could fit in a slightly longer description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks completeness regarding prerequisites (e.g., run_id from build_context), side effects, and the meaning of 'record'. With no output schema, the agent doesn't know what the tool returns. The description should at least explain the output or success criteria.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers path and run_id with descriptions. The description adds the note that mock works offline, providing context for the provider parameter. However, it does not elaborate on path or run_id beyond the schema, and the provider parameter still lacks a schema description. Overall, it adds marginal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates and records a draft with a configured provider, providing the action and resource. It also mentions offline mock capability, which adds specificity. However, it does not explicitly differentiate from sibling tools like submit_draft, though the names imply different stages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit usage guidance. It does not specify when to use this tool over siblings like build_context or submit_draft. The mention of mock working offline hints at a scenario but lacks clear directives on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect run state, artifacts, and proposed state differences.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute or current-directory-relative novel project path. | |
| run_id | Yes | Run identifier returned by build_context. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It implies a read-only operation but does not clarify whether the tool has side effects, requires specific permissions, or has performance implications. The description is too brief to meet the transparency burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no superfluous words. It conveys the core functionality efficiently, exemplifying ideal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema), the description is minimally adequate but lacks details about return values or how the inspection results are structured. It does not fully prepare an agent to interpret the output or handle edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides clear descriptions for both parameters (path and run_id), achieving 100% schema coverage. The tool description adds no additional parameter meaning beyond what the schema offers, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Inspect' with a specific resource 'run state, artifacts, and proposed state differences,' clearly distinguishing it from sibling tools like 'review_run' or 'project_status' which imply different actions. The purpose is unambiguous and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'review_run' or 'project_status.' It lacks context about prerequisites, typical use cases, or conditions that would favor this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return project status or one run's status.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute or current-directory-relative novel project path. | |
| run_id | No | Run identifier returned by build_context. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description should disclose that this is a read-only operation. It doesn't mention side effects, permissions, or error handling, leaving important behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence, concise. Could be restructured to front-load the key distinction (project vs run status), but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain return format and content. It doesn't, leaving agents uncertain about what 'status' entails. Also lacks error context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already provides descriptions for both parameters (100% coverage). The description adds no extra semantic value beyond what's in the schema, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns project or run status, and distinguishes between two modes based on run_id presence. However, it doesn't differentiate from sibling tools like review_run or inspect_run.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings like inspect_run or review_run. The description implies general status retrieval but gives no context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Review the recorded draft and create a state proposal for human approval.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute or current-directory-relative novel project path. | |
| run_id | Yes | Run identifier returned by build_context. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It mentions 'review' and 'create a state proposal' but does not disclose side effects, required permissions, or what 'review' entails (e.g., validation, modifications). For a tool that likely creates or modifies state, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is concise, though it sacrifices detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of output schema and annotations, the description is too minimal. It does not explain what a 'state proposal' is, how it relates to sibling tools, or what the agent should expect after invocation. The tool's role in a pipeline is implied but not clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions in the schema. The description adds no extra meaning beyond the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'review' and the resource 'recorded draft', and specifies the output 'state proposal'. It distinguishes from siblings like inspect_run (inspection) and approve_run (approval) by indicating a preparatory step for human approval. However, it could be more explicit about what a 'state proposal' means.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after build_context (as it uses run_id) and before human approval (approve_run). However, it gives no explicit when-to-use or when-not-to-use guidance, nor mentions alternatives like inspect_run or validate_project.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record draft text produced by an external AI tool in an existing run.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute or current-directory-relative novel project path. | |
| text | Yes | ||
| run_id | Yes | Run identifier returned by build_context. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden. It only states 'Record draft text', which implies a write operation, but fails to disclose whether it appends or overwrites, required permissions, or effects on existing data. Minimal transparency for a potentially destructive action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence of 13 words, front-loaded with verb and object, no fluff or repetition. Every word contributes to the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 params, no output schema), the description is minimally sufficient. However, it lacks workflow guidance (e.g., that run_id comes from build_context) and does not clarify the tool's role among siblings. Adequate but could be more informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% (path and run_id have descriptions; text does not). The tool description does not add any additional parameter meaning beyond the schema, such as text format or constraints. Adequate but no extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action ('Record') and the object ('draft text produced by an external AI tool in an existing run'). This distinguishes it from siblings like 'generate_draft' (which creates a draft) and 'review_run' (which reviews), as it specifically handles external draft submission.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a draft is produced externally and needs to be recorded in an existing run, but it does not explicitly state when to use this tool versus alternatives like 'generate_draft' for internal drafting, nor does it provide when-not-to scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate a novel project without changing it.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute or current-directory-relative novel project path. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description is the sole source for behavioral traits. It discloses the non-destructive nature ('without changing it'), but omits other important details such as what validation entails (e.g., error checks, linting), required permissions, or whether it produces output. This is insufficient for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-constructed sentence with no redundant words. It immediately states the tool's purpose and a key behavior. Every word earns its place, and there is no room for improvement in brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter and no annotations or output schema, the description covers only the basic action and non-destructive trait. It does not explain what validation results look like (e.g., success/failure, error list), side effects (none expected but unstated), or when validation might fail. The agent lacks enough context to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter, so the baseline is 3. The description does not add any additional meaning to the 'path' parameter beyond what the schema provides, nor does it explain how the path is used in validation. It neither enhances nor detracts from the schema's documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('validate') and resource ('a novel project'), and adds the qualifier 'without changing it' to imply read-only behavior. This helps distinguish it from sibling tools like submit_draft or approve_run that may modify state, though it doesn't explicitly call out differences.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a usage context (validation without side effects) but does not explicitly state when to use this tool over siblings like review_run or inspect_run. No guidance on prerequisites or conditions is provided, leaving the agent to infer usage from the verb alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.1approve_runbuild_contextgenerate_draftinspect_runproject_statusreview_runsubmit_draftvalidate_projectEach tool targets a distinct action in the novel project workflow: validation, context building, draft generation, external submission, review, inspection, approval, and status. No overlapping purposes.
All tool names follow the verb_noun pattern in snake_case (e.g., validate_project, generate_draft, approve_run), providing clear and predictable naming.
With 8 tools, the set is well-scoped for a novel writing assistant, covering the essential workflow stages without excess or deficiency.
Core CRUD-like operations are present: create (build_context), update (submit_draft, approve_run), read (project_status, inspect_run), delete is absent but not critical. Minor gap: no tool to list all runs or chapters, but the workflow is coherent.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AI-native fiction platform. Any AI can register, read, search and co-author novels via MCP or REST.
Publish Git-backed multilingual novels with agents, safe layouts, reviews, and author approval.
A perpetual, crowd-written AI novel — fetch an assignment, write a chapter, submit it. CC0.
Generate full stories, chapters, characters & cover art from a premise (planner-writer pipeline).
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/YinFY90/novel-engine'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
