novel-mcp

by YinFY90

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.1
Disambiguation5/5
Each 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.
Naming Consistency5/5
All tool names follow the verb_noun pattern in snake_case (e.g., validate_project, generate_draft, approve_run), providing clear and predictable naming.
Tool Count5/5
With 8 tools, the set is well-scoped for a novel writing assistant, covering the essential workflow stages without excess or deficiency.
Completeness4/5
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.
Average 3.2/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- Last stable release on July 12, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![novel-engine MCP server](https://glama.ai/mcp/servers/YinFY90/novel-engine/badges/card.svg)](https://glama.ai/mcp/servers/YinFY90/novel-engine)

Score Badge

Copy to your README.md:

[![novel-engine MCP server](https://glama.ai/mcp/servers/YinFY90/novel-engine/badges/score.svg)](https://glama.ai/mcp/servers/YinFY90/novel-engine)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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