Skip to main content
Glama
closeofbusiness

m4x

by closeofbusiness
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
Python
Local

m4x — local, private audio transcription

Turn voice memos and podcasts into text entirely on your own machine. m4x is a thin, fast wrapper around whisper.cpp that ships as both a command-line tool and an MCP server for AI agents.

Think of it as a tiny, local-first alternative to cloud transcription products (Plaud, Otter, etc.) — with one big difference: your audio never leaves your computer. No account, no upload, no API key, no per-minute fee. It runs beautifully on Apple-silicon Macs (Metal-accelerated) but works anywhere whisper.cpp does.

⚡ On an Apple M-series machine, the large-v3-turbo model transcribes roughly an hour of audio in a couple of minutes, fully offline.

Why local?

m4x (local)

Typical cloud transcriber

Where your audio goes

Stays on your machine

Uploaded to a third party

Account / API key

None

Required

Cost

Free

Per-minute or subscription

Works offline

Yes

No

Summaries

Bring your own LLM (see below)

Built-in (cloud)

Related MCP server: MCP Audio Server

Requirements

  • Python 3.10+

  • whisper.cpp (whisper-cli) — install via Homebrew: brew install whisper-cpp

  • A ggml model — download once (see below)

Install

# 1. the transcription engine
brew install whisper-cpp

# 2. a model (large-v3-turbo: great quality/speed; ~1.5 GB)
mkdir -p ~/whisper-models
curl -L -o ~/whisper-models/ggml-large-v3-turbo.bin \
  https://huggingface.co/ggerganov/whisper.cpp/resolve/main/ggml-large-v3-turbo.bin

# 3. m4x itself
pipx install .        # or: pip install .

CLI usage

# a single voice memo
m4x transcribe ~/Downloads/memo.m4a
# -> writes ~/Downloads/memo.txt

# a whole folder of podcasts, German
m4x transcribe ~/Podcasts --lang de

# print to stdout and pipe straight into your own LLM for a summary
m4x transcribe interview.mp3 --stdout | llm "summarise this into 5 bullet points and action items"

Options: --lang (e.g. en, de, or auto), --model <path>, --out <dir>, --stdout.

MCP usage (Claude Desktop & other agents)

m4x also runs as an MCP server so an agent can transcribe for you. Long files run as a background job — start, then poll.

Add to your MCP client config (e.g. Claude Desktop claude_desktop_config.json):

{
  "mcpServers": {
    "m4x": {
      "command": "m4x-mcp"
    }
  }
}

Tools exposed: transcribe_start(file_path, language) → job_id, transcribe_result(job_id), transcribe_list_jobs().

"Mini-Plaud" pattern: transcribe → summarise

m4x deliberately does transcription only and stays out of the AI-summary business, so you keep full control (and privacy) over that step. Pair it with any LLM you like:

m4x transcribe standup.m4a --stdout | llm "Extract decisions, owners, and due dates as a table"

Or, in an agent: call transcribe_start, poll transcribe_result, then ask the model to summarise the returned text.

Configuration

Everything has sensible defaults; override via environment variables:

Variable

Default

Meaning

M4X_WHISPER_BIN

whisper-cli on PATH, else /opt/homebrew/bin/whisper-cli

Path to the whisper.cpp binary

M4X_MODEL

~/whisper-models/ggml-large-v3-turbo.bin

Path to the ggml model

How it works

m4x shells out to whisper-cli with your chosen model and language, writes a .txt transcript next to the audio (or to --out), and returns the text. The CLI and the MCP server share one small core module — no duplicated logic. That's the whole thing: ~200 lines, no magic.

License

MIT — see LICENSE. Contributions welcome; see CONTRIBUTING.md and SECURITY.md.

Available Tools

3 tools
transcribe_list_jobsA

List all known transcription jobs and their statuses.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior3/5

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

Description implies read-only listing behavior but lacks details on authentication, error handling, or response format. For a simple list with no params, it is adequate but minimal.

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?

Single sentence with clear action and object. No wasted words, efficiently conveys purpose.

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 a straightforward list tool with no parameters and an output schema, the description is nearly complete. It could mention that jobs are from transcription tasks, but not essential.

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?

No parameters exist, so schema coverage is 100%. Description adds no param info, but baseline for 0 params is 4 per guidelines.

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?

Description clearly states the tool lists transcription jobs and their statuses, with specific verb and resource. Distinguishes from siblings like transcribe_start and transcribe_result, which focus on starting and retrieving jobs respectively.

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

Usage Guidelines2/5

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

No guidance on when to use this tool over siblings or context about prerequisites. Description only states function without comparative advice.

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

transcribe_resultA

Get the result of a transcription job started with transcribe_start.

Returns "running" if still in progress, the transcript text if done, or a diagnostic message if it failed.

ParametersJSON Schema
NameRequiredDescriptionDefault
job_idYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full burden. It transparently discloses three return states (running, transcript text, diagnostic message), which are the key behavioral outcomes. It does not mention idempotency, rate limits, or persistence, but for a simple poll operation, this is adequate.

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 concise at three sentences, with the main action front-loaded. Every sentence adds value: first defines purpose, second explains return behaviors. No unnecessary details.

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?

Given the tool's simplicity (one parameter, no nested objects) and the presence of an output schema, the description reasonably covers the main return cases. It could mention the output format (e.g., JSON) but is otherwise complete for a polling tool.

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

Parameters3/5

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

The schema has 0% description coverage for job_id. The description compensates by implying that job_id comes from transcribe_start, adding context beyond the schema. However, it does not specify format, example, or constraints, leaving some ambiguity.

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 states the tool gets the result of a transcription job started with transcribe_start, distinguishing it from siblings. It specifies the verb 'Get', resource 'result', and lists possible return values (running, transcript, diagnostic), which clarifies the tool's role.

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?

The description implies usage after transcribe_start by referencing it, providing clear context. However, it does not explicitly state when not to use it (e.g., for listing jobs) or alternative approaches, though sibling tools provide context.

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

transcribe_startA

Start a transcription job and return a job_id immediately.

Args: file_path: Absolute path to an audio file (mp3, wav, m4a, …). language: Language code ('en', 'de', 'auto'). Default 'auto'.

Returns: A job_id string. Pass it to transcribe_result to poll for the transcript.

ParametersJSON Schema
NameRequiredDescriptionDefault
languageNoauto
file_pathYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden. It discloses that the tool returns immediately (asynchronous behavior) and requires polling. This is sufficient for a non-destructive start-job tool. No destructive or permission details are missing.

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 extremely concise: three short paragraphs for purpose and returns, plus a clear Args/Returns structure. Every sentence adds value without redundancy.

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?

Given the tool's simplicity (start async job with two parameters) and the presence of an output schema (though not shown, the return value is described), the description covers all essential information: usage, parameters, return format, and next steps with sibling tool. It is complete for its complexity.

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?

The schema has 0% description coverage, so the description must add meaning. It does: file_path requires absolute path with examples (mp3, wav, m4a), and language specifies codes ('en', 'de', 'auto') with default 'auto'. This fully compensates for the schema's lack of descriptions.

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 starts with a clear verb and resource: 'Start a transcription job and return a job_id immediately.' It distinguishes itself from sibling tools transcribe_list_jobs and transcribe_result by focusing on job initiation and immediate return of an identifier.

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?

The description explains the return value (job_id) and explicitly instructs to pass it to transcribe_result for polling. This provides a clear workflow and usage context. However, it does not explicitly state when not to use this tool or mention alternatives beyond the sibling.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 3 tool updatesv0.1.0
    • First observedtranscribe_list_jobs
    • First observedtranscribe_result
    • First observedtranscribe_start
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a distinct purpose: starting a job, listing jobs, and retrieving results. There is no overlap or ambiguity.

Naming Consistency5/5

All tools follow the consistent pattern 'transcribe_<action>', using snake_case and verb_noun structure.

Tool Count4/5

3 tools is minimal but appropriate for a simple transcription service covering the core workflow. Could be expanded, but not insufficient.

Completeness4/5

The set covers starting, polling results, and listing jobs, which are the essential operations. Missing cancellation or deletion, but not critical for the domain.

Maintenance

ActivityStale
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers