Skip to main content
Glama
jwulff

Apple Voice Memo MCP Server

by jwulff
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Local

Apple Voice Memo MCP Server

An MCP (Model Context Protocol) server that provides programmatic access to Apple Voice Memos on macOS. Use this to let Claude and other AI assistants interact with your voice recordings.

Pairs well with whisper-mcp for local transcription.

Features

  • List voice memos - Browse all your voice memos with metadata

  • Get memo details - Retrieve detailed information about specific recordings

  • Get audio - Access the audio file path or base64-encoded audio data

  • Get transcripts - Extract transcripts from memos (stored by Apple in the audio file)

  • Transcribe memos - Generate transcripts using Apple's SFSpeechRecognizer

Related MCP server: macwhisper-mcp-server

Requirements

  • macOS Sonoma (14.0) or later (Sequoia recommended for transcription)

  • Node.js 18+

  • Full Disk Access permission (for accessing Voice Memos data)

  • Voice Memos app must have been opened at least once

Installation

npm install -g apple-voice-memo-mcp

Or use directly with npx:

npx apple-voice-memo-mcp

Configuration

Claude Desktop

Add to your Claude Desktop config file:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

{
  "mcpServers": {
    "apple-voice-memo-mcp": {
      "command": "npx",
      "args": ["-y", "apple-voice-memo-mcp"]
    }
  }
}

After editing, restart Claude Desktop.

Claude Code (CLI)

For Claude Code, add to your project's .mcp.json file:

{
  "mcpServers": {
    "apple-voice-memo-mcp": {
      "command": "npx",
      "args": ["-y", "apple-voice-memo-mcp"]
    }
  }
}

Or for user-wide configuration, add to ~/.claude/settings.json:

{
  "mcpServers": {
    "apple-voice-memo-mcp": {
      "command": "npx",
      "args": ["-y", "apple-voice-memo-mcp"]
    }
  }
}

Tip: Use /mcp in Claude Code to verify the server is connected.

Local Development Setup

If running from source instead of npm:

{
  "mcpServers": {
    "apple-voice-memo-mcp": {
      "command": "node",
      "args": ["/path/to/apple-voice-memo-mcp/dist/index.js"]
    }
  }
}

Permissions

  1. Full Disk Access: Required to read the Voice Memos database

    • Go to System Settings > Privacy & Security > Full Disk Access

    • Add your terminal app or Claude Desktop

  2. Speech Recognition (for transcription):

    • Required only if using the transcribe_memo tool

    • System will prompt when first used

MCP Tools

list_voice_memos

List all voice memos with metadata.

Parameters:

  • limit (optional): Maximum number of results (1-100, default: 50)

  • offset (optional): Pagination offset

  • search (optional): Search term to filter by title

Example response:

{
  "memos": [
    {
      "id": 1,
      "title": "Meeting Notes",
      "date": "2025-01-07T10:30:00.000Z",
      "duration": 120.5,
      "hasTranscript": true
    }
  ],
  "total": 15
}

get_voice_memo

Get detailed metadata for a specific memo.

Parameters:

  • id (required): Memo ID

get_audio

Retrieve the audio file.

Parameters:

  • id (required): Memo ID

  • format (optional): "path" or "base64" (default: "path")

get_transcript

Extract transcript from a memo.

Parameters:

  • id (required): Memo ID

  • format (optional): "text", "json", or "timestamped"

transcribe_memo

Transcribe a memo using SFSpeechRecognizer.

Parameters:

  • id (required): Memo ID

  • language (optional): Language code (default: "en-US")

How It Works

Data Access

Voice Memos data is stored in:

  • Database: ~/Library/Group Containers/group.com.apple.VoiceMemos.shared/Recordings/CloudRecordings.db

  • Audio files: Same directory, .m4a format

Transcript Storage

Apple stores transcripts directly inside the .m4a audio files using a custom MPEG-4 atom called tsrp. This MCP server parses these atoms to extract transcripts - no separate transcript files exist.

Development

# Clone the repository
git clone https://github.com/jwulff/apple-voice-memo-mcp.git
cd apple-voice-memo-mcp

# Install dependencies
npm install

# Build
npm run build

# Run in development
npm run dev

# Test with MCP inspector
npm run inspector

Troubleshooting

"Voice Memos database not found"

  1. Ensure you've opened the Voice Memos app at least once

  2. Grant Full Disk Access to your terminal/application

  3. Check if iCloud sync is enabled for Voice Memos

"No transcript available"

  • On macOS Sequoia+, open the memo in Voice Memos app to trigger automatic transcription

  • Older macOS versions don't have automatic transcription

  • Use the transcribe_memo tool to generate a transcript via SFSpeechRecognizer

Native module binding errors

If you see errors about missing better_sqlite3.node bindings:

npm rebuild better-sqlite3

This recompiles the native module for your current Node.js version.

License

MIT

Available Tools

5 tools
get_audioA

Retrieve the audio file for a voice memo. Can return either the file path or base64-encoded audio data.

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesThe ID of the voice memo
formatNoOutput format: 'path' returns file path, 'base64' returns encoded audio (default: path)

TDQS

A4/5.0
Behavior4/5

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

With no annotations, the description reveals the key behavioral trait of offering two output formats. It implies a read-only operation but does not explicitly state it as such.

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?

Two sentences, no fluff, front-loading the core action and output options.

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 simple 2-parameter tool with no output schema, the description covers the essential functionality. Missing error handling or behavior for invalid IDs, but still adequate.

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 covers both parameters fully. The description merely restates the format parameter's purpose, adding no new meaning beyond what the schema provides.

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 retrieves audio for a voice memo and can return either a file path or base64-encoded data. It distinguishes itself from siblings like get_transcript (text) and list_voice_memos (listing).

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

Usage Guidelines3/5

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

The description does not explicitly state when to use this tool vs alternatives, leaving it to inference. However, the purpose is clear enough for basic selection.

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

get_transcriptA

Extract and return the transcript from a voice memo. Transcripts are stored by Apple inside the audio file. Returns plain text, structured JSON, or timestamped segments.

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesThe ID of the voice memo
formatNoOutput format: 'text' for plain text, 'json' for structured data, 'timestamped' for text with timestamps (default: text)

TDQS

A3.6/5.0
Behavior2/5

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

No annotations are provided, so the description must bear the full burden. It discloses that transcripts are stored inside the audio file by Apple, adding some context. However, it does not mention prerequisites (e.g., whether all voice memos have transcripts), error behavior, or side effects. The output formats are described but not the underlying data structure.

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?

Two sentences, no filler. The first sentence states the core function, and the second adds key detail about output formats and source. Front-loaded and efficient.

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 simple tool with two parameters and no output schema, the description covers the main purpose, source, and output formats. It could mention potential failure cases (e.g., no transcript available), but overall it is adequate for agent understanding.

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?

Schema coverage is 100%, so baseline is 3. The description adds context about the 'format' parameter values and the default ('text'), which is slightly beyond the schema's enum descriptions. However, it does not explain the 'id' parameter beyond what is in the schema.

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's action: 'Extract and return the transcript from a voice memo.' It specifies the source (Apple inside the audio file) and three output formats, distinguishing it from siblings like transcribe_memo (which likely generates transcripts) and get_audio (which returns audio).

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

Usage Guidelines3/5

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

The description does not explicitly state when to use this tool versus alternatives. It implies that it works on existing Apple-stored transcripts, but there is no direct guidance excluding transcription generation or when to prefer other tools.

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

get_voice_memoA

Get detailed metadata for a specific voice memo by its ID. Returns title, date, duration, and transcript availability.

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesThe ID of the voice memo to retrieve

TDQS

A3.8/5.0
Behavior3/5

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

No annotations provided, so description carries full burden. It describes return fields but does not disclose behavior like (likely) read-only, or error handling if ID not found. Adds context about return values but not beyond that.

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, no waste, direct and clear. Front-loaded with the action and what it returns.

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 simple retrieval tool with one parameter and no output schema, the description lists key return fields. May not be exhaustive (e.g., could there be other metadata fields?), but given the simplicity, it seems adequate.

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?

Only one parameter with full schema description coverage (100%). The tool description does not add new meaning beyond the schema parameter description. Baseline 3 is appropriate.

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?

Clearly states the action ('Get detailed metadata') and target ('specific voice memo by ID'). Lists specific return fields (title, date, duration, transcript availability), distinguishing from siblings like get_audio, get_transcript, list_voice_memos, and transcribe_memo.

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

Usage Guidelines3/5

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

Implied usage: you need the voice memo ID. But no explicit guidance on when to use this vs siblings like get_audio or get_transcript. No when-not conditions provided.

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

list_voice_memosA

List voice memos from Apple Voice Memos app with metadata. Returns memo IDs, titles, dates, durations, and whether they have transcripts.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of memos to return (1-100, default: 50)
offsetNoNumber of memos to skip for pagination (default: 0)
searchNoSearch term to filter memos by title or custom label

TDQS

A3.7/5.0
Behavior3/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 discloses that it returns metadata fields, but does not mention side effects, authentication needs, or rate limits. For a simple read-only list tool, it is minimally 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 a single, front-loaded sentence with no unnecessary words. It efficiently conveys the tool's purpose and return value.

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

Completeness3/5

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

The description provides basic information but lacks details on pagination behavior, how search works, or any potential limitations. Given the siblings and no output schema, it is minimally complete for a list operation.

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?

Schema coverage is 100%, so the schema already documents the three parameters. The description adds no additional meaning beyond the schema beyond stating the return fields. Baseline score of 3 is appropriate.

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 it lists voice memos with specific metadata fields. The verb 'list' and resource 'voice memos' are precise, and it distinguishes from siblings like 'get_voice_memo' which retrieves a single memo.

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

Usage Guidelines3/5

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

The description does not explicitly guide when to use this tool versus alternatives like 'get_audio', 'get_transcript', or 'transcribe_memo'. It implies usage for listing, but lacks explicit when-to or when-not-to guidance.

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

transcribe_memoA

Transcribe a voice memo using Apple's SFSpeechRecognizer. This generates a transcript for memos that haven't been transcribed yet. Note: The transcript is returned but not saved to the original file. Requires Speech Recognition permission and downloaded language packs.

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesThe ID of the voice memo to transcribe
languageNoLanguage code for transcription (e.g., 'en-US', 'es-ES'). Default: 'en-US'

TDQS

A3.9/5.0
Behavior3/5

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

Discloses crucial behavior: transcript returned but not saved. Also mentions permission requirements. However, without annotations, it should also cover error conditions and performance aspects.

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?

Two efficient sentences plus a note, all front-loaded with essential information. No wasted words.

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

Completeness3/5

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

Covers main points but lacks details on return format and error handling. With no output schema, these would be helpful. Adequate for a simple 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?

All parameters are documented in the schema (100% coverage), so description adds no extra parameter meaning beyond the schema.

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?

Clearly states the verb 'Transcribe' and resource 'voice memo', and distinguishes from siblings like 'get_transcript' by specifying it generates new transcripts for untranscribed memos.

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?

Provides context (for memos not yet transcribed) and prerequisites (permission and language packs). Lacks explicit alternatives or when-not-to-use, but the implication is clear.

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

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4/5.0
Disambiguation5/5

Each tool has a clear, non-overlapping purpose: listing memos, getting metadata, retrieving audio, retrieving existing transcripts, and generating new transcripts. No ambiguity between tools.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with lowercase and underscores (e.g., get_audio, list_voice_memos). Easy to predict and understand.

Tool Count5/5

With 5 tools covering listing, metadata retrieval, audio retrieval, transcript retrieval, and transcript generation, the set is well-scoped for the domain of voice memo management.

Completeness4/5

Covers essential read operations and transcript generation. One minor gap: the transcribe_memo tool does not save the generated transcript back to the file, but it is returned to the user.

Maintenance

ActivityInactive
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

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/jwulff/apple-voice-memo-mcp'

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