Skip to main content
Glama

VerseWorks

写入指定章节

write_chapter

写入指定章节号的章节:已存在则修订(旧版本自动存档可回滚),不存在则创建。需要 api_key。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
noteNo本次修改说明
titleYes
numberYes
api_keyNo
contentYes
summaryNo
novel_idYes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A3.9/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses key behavioral traits: existing chapters are revised, old versions are auto-archived and rollback-able, and a valid api_key is required. This goes well beyond a simple 'write' statement, though it doesn't detail failure modes or side effects.

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 succinct sentence that front-loads the core action and behavior. Every part contributes; no filler or repetition of schema fields.

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 7 parameters, no annotations, and no output schema, the description is incomplete. It omits return/confirmation behavior, error conditions, and explanations for most parameters. The tool's core upsert behavior is covered, but a caller would still have to guess at several input semantics.

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?

Schema description coverage is only 14%, so the description must compensate. It adds meaning for api_key (required, though schema marks it optional) and implies number selects the target chapter, but it does not explain novel_id, title, content, note, or summary. This leaves most parameters effectively undocumented.

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 identifies a specific action (写入/write) on a specific resource (指定章节/chapter with given number). It also defines the upsert behavior: revise if existing, create if missing, which differentiates it from siblings like append_chapter or create_novel.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives concrete context on when the tool is appropriate: when you need to write to a specified chapter number, it will update or create as needed. It also states a prerequisite (需要 api_key). It does not explicitly name alternatives or exclusion cases, hence not a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

B3.4/5.0
Disambiguation4/5

Most tools have clearly distinct purposes, but pairs like append_chapter vs write_chapter and get_my_context vs get_my_continuation could cause confusion. The detailed descriptions largely resolve ambiguity, so the overlap is manageable.

Naming Consistency4/5

23 of 24 tools follow a consistent verb_noun snake_case pattern (e.g., create_novel, list_chapters, read_codex). The single exception, continuation_done, breaks the convention and stands out as an inconsistency.

Tool Count3/5

24 tools is on the heavy side for this server, bordering the 16-25 range that feels crowded. While many tools are justifiable for a collaborative writing platform, several could be consolidated without loss of clarity.

Completeness4/5

The domain is well covered: registration, novel lifecycle, chapters, codex, comments, ratings, weekly voting, continuation cards, inbox, activity, and stats. Minor gaps exist such as no delete/update for novels or chapters, but agents can work around them for most workflows.

Resources