Local TTS Automation on Mac: CLI, MCP, and Batch Queues

Direct answer: automate local TTS through one application-owned job contract that works from the CLI, an MCP tool, and the graphical queue. The request should name the project or source, voice, engine, language, output directory, format, overwrite policy, and optional pronunciation profile. The result should return a stable job ID, effective model, generated files, checksums, warnings, and failures. Make jobs idempotent, stream progress, support cancellation, validate paths, and require confirmation before overwriting or cloning a new voice. MCP is a discovery and invocation layer, not permission to let a model write anywhere or synthesize any speaker without review.

Automation surfaces

Define one stable job schema

Use explicit required and optional fields with versioning. Resolve friendly voice and model names to effective immutable identifiers before work begins. Reject unknown formats, unsupported languages, missing consent, paths outside approved roots, and incompatible model settings. A dry run should show files, estimated downloads, collisions, and required approvals without generating audio. Keep the same validation in every surface so the CLI cannot bypass a GUI safety rule.

Make retries safe

Generate into a job directory and publish outputs atomically. Derive an idempotency key from the approved request and source revision, or accept one from the caller. Retrying after a crash should reuse completed valid clips and regenerate only missing or corrupt outputs. Never append duplicate queue items silently. Record per-item status and preserve the original failure. The long-form endurance guide shows why repairable sections matter for large scripts.

Expose progress, cancellation, and provenance

Report queued, preparing model, normalizing, generating, exporting, completed, cancelled, and failed states with current item and totals. Cancellation should stop model work, finalize no partial public file, and leave a resumable manifest. Every output should identify the engine, model revision, voice or consented reference, language, settings, source hash, normalization version, and creation time. Redact script content, license keys, and private paths from routine logs.

Design MCP tools narrowly

Prefer small tools such as list installed voices, validate a job, submit an approved batch, get status, cancel, and reveal outputs. Use JSON Schema constraints and approved filesystem roots. Treat tool annotations as untrusted metadata and confirm destructive or identity-sensitive operations in the host. The existing Murmur automation documentation should remain the user-facing contract, while protocol details stay in diagnostics and developer references.

Production acceptance record

Before acting on this local TTS automation Mac recommendation, create an acceptance record for the exact feature and release. Name the owner, reviewer, user task, minimum Mac, operating system, application version, runtime, model revision, precision, input fixture, expected artifact, and pass threshold. Attach versioned job and result schemas, dry-run collision report, twenty-item retry and resume test. Keep upstream documentation in one section and measurements from your own machine in another. Record every unsupported path, timeout, crash, incorrect output, and manual repair. A result counts as a pass only when the artifact is usable for the stated job. Fast but incomplete output, an unrecoverable cancellation, or a file that cannot be reopened remains a failure.

Run the record once on a clean launch, once after warmup, once with realistic companion applications open, and once after deliberately interrupting the workflow. Exercise the operating steps that matter most here: Use one versioned job contract. Validate models, voices, consent, and paths. Offer dry run and idempotency. Save raw timings and checks instead of copying only a winning screenshot. Include rejected options and the reason each lost, so a later framework or model update can reopen the decision without starting from memory. Assign an update trigger such as a new runtime release, model revision, minimum operating system, material support issue, or change in licensing. Review the record before changing defaults, removing a fallback, or publishing a broad performance claim.

Evidence to collect before publication

Publish an example job schema and run a 20-item batch that includes a duplicate request, invalid path, missing voice, cancellation, process restart, and one failed clip. Show the dry run, progress events, final manifest, checksums, exit codes, and resumed result. Demonstrate the same validation through CLI and MCP without exposing a real private script.

• Versioned job and result schemas
• Dry-run collision report
• Twenty-item retry and resume test
• Cancellation and atomic-output proof
• CLI and MCP validation parity

Reader worksheet

List every automated action and classify it as read-only, generative, identity-sensitive, filesystem-writing, overwrite-capable, or network-requiring. Record required inputs, approved roots, confirmation, idempotency key, progress events, output manifest, cancellation, and recovery. Remove any field whose meaning depends on hidden application state.

Practical checklist

1. Use one versioned job contract.
2. Validate models, voices, consent, and paths.
3. Offer dry run and idempotency.
4. Stream progress and support cancellation.
5. Write outputs atomically with manifests.
6. Require approval for destructive or identity-sensitive work.

Frequently asked questions