Skip to main content
Glama

batch_upload

Upload chapters from local manuscript directories to the Fanqie Novel backend in batches, with dry-run preview, draft or publish modes, and volume routing.

Instructions

批量上传章节(核心工具)。source 支持三种:① 作品目录(含 chapters.json + chapters/NNNN.md,自动取标题与分卷号);② 普通目录(*.md 按文件名排序,首行「第N章 …」作标题);③ manifest .json。默认 dry_run=true 只返回上传计划(标题/字数/段落数),确认后传 dry_run=false 真正上传。mode 默认 draft 存草稿;publish 才提交审核(审核中不可改)。支持 range(如 1-20)、volume_map(稿件卷号→番茄 volume_id)、限速与失败策略。

Input Schema

NameRequiredDescriptionDefault
modeNodraft=存草稿(默认);publish=提交审核
rangeNo章节号范围,如 1-20、1,3,5-7、all(默认 all)
sourceYes稿件目录 / chapters.json / manifest .json / 单个 .md 的路径
book_idNo可选;默认当前选中书
dry_runNotrue=只预览计划不上传(默认);false=真正执行
volume_idNo全部章节放进这个分卷(单卷模式)
volume_mapNo多卷映射:稿件卷号 → {"volume_id":"…","volume_name":"…"}。例如 {"1":{"volume_id":"123","volume_name":"第一卷"}}。未映射的卷落到 volume_id/默认卷
interval_msNo每章之间的间隔毫秒数,默认 2000(限速保护,不建议低于 1000)
volume_nameNo分卷名(与 volume_id 配套)
max_chaptersNo本次最多上传多少章(0=不限,默认 0)。大书建议分批
continue_on_errorNo单章失败是否继续(默认 true)。鉴权失效时无论如何都会立即停止

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries the burden well: it discloses defaults (dry_run=true, mode=draft, interval 2000ms), rate-limiting protection, continue_on_error semantics, and that publish puts chapters into an unmodifiable review state. It stops short of describing the actual return payload for a non-dry-run upload.

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?

Front-loads the core identity with '(核心工具)', then enumerates source types and the dry-run gate in a compact progression. Dense but every clause carries operational meaning; slightly long, though nothing is obviously redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 11-parameter mutation tool with no annotations and no output schema, the description covers safety (dry-run first, auth failure aborts, rate limiting) and the key defaults. It could say a bit more about what a real upload returns, but it is sufficient to invoke correctly.

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 coverage is already 100%, so baseline is 3; the description adds real value by explaining the three source layouts, how range and volume_map are used (including unmapped-volume fallback to volume_id/default), and the draft-vs-publish consequence of mode.

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?

States a specific verb+resource (批量上传章节) and immediately distinguishes itself from the single-chapter sibling by emphasizing batch scope and the three accepted source layouts. An agent can tell this apart from upload_chapter without inspecting schemas.

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?

Clearly prescribes the workflow: dry_run=true first to preview the plan, then dry_run=false to actually upload; mode=draft by default, publish only when ready for review. It does not explicitly name upload_chapter as the alternative for a single chapter, leaving that inference to the 'batch' framing.

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