Skip to main content
Glama

create_chapter_from_marks

Creates a localized chapter variant from sentence marks via TTS, translation, and alignment pipeline. Returns chapter ID on success or failure details with retry hint.

Instructions

Create one chapter variant (single language+level) via cwbe's /chapters/from-marks pipeline: cwtts → Gemini sentence translate → awesome-align → ingest. Polls the resulting Job until terminal. To build all 9 language variants of the same chapter, call this once per source language — one chapter at a time, no concurrent runs (see Concurrency Cap in CLAUDE.md).

Returns JSON with status ("COMPLETED" | "FAILED" | "CANCELLED" | "TIMEOUT"), job_id, message, and — on success — chapter_id. On failure the message includes sourceAudioBlobName=... scraped from cwbe logs; pass that back to retry without regenerating audio.

If a chapter with the same (publication, language, level, title) already exists, cwbe returns that chapter's UUID immediately — safe to retry.

Args: publication_id: Publication UUID on cwbe. title: Localized chapter title (e.g. "0005 - Les plans"). language: Source language code (EN | FR | ES | DE | IT | PT | ZH | JA | KO). level: Difficulty (B1 | B2). marks: Pre-split sentence list in the source language. No blanks. source_audio_blob_name: Optional retry hint — skip phase 0 (TTS) by reusing a cached audio bundle from a previous failed run. Scrape from cwbe logs after a failure. tokens_per_mark: Pre-segmented source tokens, one list per mark (parallel to marks). Required for CJK source — obtain via the segment tool (one batched /segment call), then feed the same tokens to the cjk-glosser agent. Passing them here makes cwbe trust the caller's tokenisation and skip its internal cwseg call, eliminating agent-vs-cwseg split mismatches. Optional for EU source. token_glosses: Per-token gloss overrides. Required and non-empty for CJK-source chapters — cwbe rejects with HTTP 400 if any (non-punctuation source token, Asian target) cell is missing. Each entry is a dict with keys token, sourceLanguage, targetLanguage, gloss — e.g. [{"token": "你好", "sourceLanguage": "ZH", "targetLanguage": "JA", "gloss": "こんにちは"}]. Use gloss: "" for explicit ML Kit fallback. Entries are request-scoped and never written to any cache.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
publication_idYes
titleYes
languageYes
levelYes
marksYes
source_audio_blob_nameNo
tokens_per_markNo
token_glossesNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

No annotations, but description fully discloses behavior: pipeline steps, polling until terminal, response structure (status, job_id, chapter_id), failure details (blob name in logs). Even covers cwbe behavior for duplicate chapters.

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?

Well-structured: starts with purpose and pipeline, then return format, then parameter descriptions. Each section is concise yet informative. No redundant information.

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

Completeness5/5

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

For a complex tool with 8 parameters, output schema not provided, the description covers everything: return values, error handling, concurrency, parameter details, and even best practices (e.g., pre-segmenting for CJK).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% coverage, so description is essential. It explains all 8 parameters in detail, including optional ones like source_audio_blob_name for retry, and special CJK requirements for tokens_per_mark and token_glosses.

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 states 'Create one chapter variant (single language+level)' with specific pipeline steps (cwtts, Gemini, awesome-align, ingest). It distinguishes from siblings like 'upload_chapter_from_zip' by detailing the custom pipeline and concurrency constraints.

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

Usage Guidelines5/5

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

Explicitly says when to use: for one chapter at a time, no concurrent runs. Provides retry strategy (pass sourceAudioBlobName). Mentions safe idempotency when chapter already exists.

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

Install Server

Other Tools

Latest Blog Posts

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/paulmichaelstafford/cwmcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server