audiobook_mcp

Overview Schema Source Related Servers Discussions Admin

Advance a conversion job by one bounded chunk of work

audiobook_continue_conversion

Resume an interrupted audiobook conversion job from its last checkpoint, advancing through encoding and assembly until the chaptered M4B file is complete.

Instructions

Do up to time_budget_seconds of work on a job (aligning chapters, encoding segments, assembling, or delivering the final file -- whichever stage it's currently in), checkpoint to disk, and return. Re-call this with the same job_id, or use audiobook_run_until_done to loop automatically, until the response's "done" field is true.

Safe to call again immediately if a previous call errored partway through a stage -- work already checkpointed is never redone.

Args: params (ContinueConversionInput): - job_id (str): from audiobook_start_conversion. - time_budget_seconds (float): stop and checkpoint after roughly this long (5-300s, default 60).

Returns: str: JSON status object -- see audiobook_get_status's Returns schema, which this shares exactly.

Error Handling: - "unknown_job" if job_id isn't registered. - ffmpeg/encoding failures surface with ffmpeg's own error text tail included; the job's checkpoint is untouched so retrying (after e.g. freeing disk space) picks up where it left off.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 18, 2026

TDQS

A5/5.0

Behavior5/5

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

The description goes well beyond the annotations by disclosing checkpointing, safe re-invocation after partial failures, that checkpointed work is never redone, and exact error outcomes including 'unknown_job' and ffmpeg failure behavior. This gives a full behavioral model for a mutating tool.

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 front-loaded with the core behavior, then organized into Args, Returns, and Error Handling sections. Every sentence adds necessary operational information without redundancy or filler.

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?

The description covers invocation, looping behavior, retry semantics, error cases, return-value reference, and parameter constraints. With an output schema available and a clear pointer to audiobook_get_status for the return schema, nothing needed to call the tool correctly is missing.

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 description coverage is reported at 0%, so the description must carry the parameter explanation. It does: job_id is sourced from audiobook_start_conversion, and time_budget_seconds is given with its operational meaning, range (5-300s), and default of 60.

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 a specific verb ('Advance'), a clear resource ('a conversion job'), and the bounded-chunk behavior ('Do up to time_budget_seconds of work ... checkpoint to disk, and return'). It also names the stages the job moves through, which distinguishes it from related job-management tools and from audiobook_run_until_done.

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?

The description explicitly tells the agent to re-call with the same job_id until 'done' is true, and names audiobook_run_until_done as the automatic-loop alternative. It also gives retry guidance after errors, making when-to-use and how-to-continue unambiguous.

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

Deploy Server