Skip to main content
Glama

Tamlil is a macOS menu-bar app that records your Zoom and Slack calls and turns them into clean, speaker-labeled transcripts — even when the conversation switches between Hebrew and English in the middle of a sentence. It starts recording on its own when a call begins, and the transcript is waiting for you the moment you hang up. Everything stays on your Mac; all that ever leaves it is the transcription request — the call audio plus a short recognition hint (meeting title, attendee names, learned terms) — and Tamlil deletes the upload from the provider as soon as the transcript comes back.

Why Tamlil

  • It records itself. Join a Zoom call or a Slack huddle and Tamlil starts capturing; hang up and the transcript builds automatically. Nothing to launch, click, or remember to turn on.

  • Built for Hebrew and English together. Most transcribers make you pick one language per meeting. Tamlil keeps up with real bilingual speech, tagging each word's language, so a sentence that starts in Hebrew and ends in English comes out right.

  • Every speaker labeled — and playable. Your side and the other side are separated and named, and the finished recording plays back inline with a waveform, so you can jump to any line and hear exactly what was said.

  • Correct it as you read; it remembers. Tamlil flags the words it was unsure of right in the transcript. Fix one and it learns the term for every future meeting, so your names, products, and jargon stop coming back wrong.

  • Private by default. Recordings, transcripts, and your learned vocabulary live only on your Mac. Your API key sits in the Keychain, never in a file. After each meeting Tamlil deletes both the audio and the transcript from the provider, so nothing lingers off your device.

  • Answers from your AI assistant. A read-only connector lets Claude Code or Codex read your finished meetings and answer questions or draft summaries.

Related MCP server: Meetings MCP Server

A look inside

Install

One command. You need macOS 15 (Sequoia) or later on an Apple-Silicon Mac and the Xcode Command Line Tools 16 or later (xcode-select --install; the build needs their Swift 6 toolchain); the installer handles everything else.

curl -fsSL https://raw.githubusercontent.com/Steven17D/tamlil/main/scripts/install.sh | zsh

It clones Tamlil, builds and installs the app, puts the transcript connector on your PATH, asks for your Soniox API key (from console.soniox.com), and launches. The first time a call records, macOS asks you to approve Microphone and System Audio Recording — say yes. Re-running the command updates an existing install. Optional meeting titles from Google Calendar need a one-time OAuth-client setup first — see Google Calendar setup.

git clone https://github.com/Steven17D/tamlil.git
cd tamlil
uv sync                                     # Python deps (install uv from astral.sh/uv)
make app                                    # build Tamlil.app
rm -rf /Applications/Tamlil.app && cp -R Tamlil/dist/Tamlil.app /Applications/
defaults write dev.dashevsky.tamlil repoPath "$PWD"
scripts/launch-agent.sh restart            # launch under crash supervision

# store your Soniox key in the Keychain (never in a file)
security add-generic-password -s tamlil-soniox -a soniox -w "<KEY>" -U

To read meetings from an AI agent, also put the connector on your PATH: uv tool install --force . then claude mcp add tamlil --scope user -- "$HOME/.local/bin/tamlil-mcp".

Updating. Click Check for updates in the menu, or re-run the install command — Tamlil pulls the latest, rebuilds from source, and relaunches.

How it works

  1. Join a call. When a call app (Zoom, or a Slack call or huddle) starts using your microphone, Tamlil records two local tracks: your mic and the meeting's system audio.

  2. Hang up. Recording stops with the call, and transcription runs automatically on the finished recording.

  3. Read the transcript. The two tracks are transcribed, merged and speaker-labeled, cleaned of mic echo, and rewritten through your learned vocabulary. The finished transcript appears in the menu-bar app and is saved under ~/Recordings/Tamlil/.

  4. Ask an agent (optional). Claude Code or Codex reads finished meetings over the read-only connector and writes its own summaries.

For how the menu-bar app, pipeline, transcription, lexicon, connector, and Google Calendar fit together, see the architecture overview.

Privacy and data handling

Tamlil records real meeting audio, so it is worth being precise about what leaves your machine and what does not. The transcription provider is Soniox; the facts below are grounded in Soniox's published Terms of Service and Privacy Policy (both last updated 2026-06-29). docs/soniox-data-processing.md has the full write-up and sources.

  • What is captured. Two local audio tracks per meeting: your microphone (raw/mic.wav) and the meeting app's system audio (raw/system.wav). Recording starts automatically when a call app begins capturing your mic.

  • What leaves your machine. Traffic to two services, nothing else. The two audio tracks are uploaded to Soniox's async speech-to-text API (default endpoint api.soniox.com), and each request carries a recognition hint — the meeting title, attendee names, and learned lexicon terms — so Soniox spells them correctly. If you connect Google Calendar, meeting titles and attendee names are read from it. The read-only connector serves agents locally and sends nothing anywhere.

  • Training and secondary use. Soniox commits, in its binding Terms of Service and again in its Privacy Policy, that it does not use customer content to "train, fine-tune, evaluate, benchmark, or improve" its models or services, and that it does not sell it. This is the default; no opt-in is required.

  • Retention. The async API is Soniox's storage service: uploaded audio and the resulting transcript are stored server-side with no automatic deletion, so cleanup is the caller's responsibility. After each run the pipeline deletes the stored transcription, which also removes the uploaded audio file, so under normal operation neither the audio nor the transcript text is retained by Soniox. (Deletion is best-effort: a failure is logged and does not fail the run. For a single-file tamlil-transcribe run, --keep-remote skips it.)

  • Data residency. Because the pipeline calls the default api.soniox.com, audio and transcripts are processed and stored in the United States, unless a regional Soniox project (EU or Japan) was explicitly requested and configured.

  • Legal basis. Usage is governed by Soniox's self-serve, click-through Terms of Service plus Privacy Policy. A data-processing agreement and a HIPAA BAA are available through the Soniox Console but are not automatic — unless one has been accepted for the account, neither is in force.

  • Calendar scope. Roster lookup is read-only and optional. It requests the single scope https://www.googleapis.com/auth/calendar.events.readonly and reads only meeting titles and attendee names. The per-user refresh token lives in your macOS Keychain (tamlil-google); without it, meetings still record and transcribe, just without titles or attendee names.

  • Local storage. Recordings, transcripts, and the learned lexicon stay on your Mac — recordings under ~/Recordings/Tamlil/<recording-id>/, the learned dictionary at the repo root. The Soniox API key lives in the Keychain (tamlil-soniox), never in a file. The connector opens the recording database read-only.

  • Deletion. To delete a recording locally, remove its directory under ~/Recordings/Tamlil/. On Soniox, both the uploaded audio and the stored transcription are removed automatically after each run, so nothing needs to be deleted there by hand under normal operation.

To report a security issue, see SECURITY.md.

Tamlil records your microphone and the meeting app's system audio together, so every participant's voice is captured. Recording a conversation is regulated by wiretap and eavesdropping laws that turn on who agreed to be recorded, and those laws differ by jurisdiction.

  • You are responsible for obtaining consent. Tamlil is a local tool that records on your behalf. The person running it — not the project's author and not the software — is responsible for obtaining whatever consent the law requires from everyone on the call, and for doing so before recording starts.

  • All-party versus one-party. Jurisdictions differ on how many participants must consent. In one-party jurisdictions (much of the United States) your own consent is enough. In all-party jurisdictions — often called two-party — every participant must consent: California requires the consent of all parties to a confidential communication (Penal Code section 632), and the EU generally requires a lawful basis and the participants' consent under the GDPR and national law. A call that crosses borders can leave you bound by the strictest rule that applies to anyone on it.

  • Not legal advice. The above is general information, not legal advice, and it is not exhaustive. Consent rules vary by country, state, and context and they change over time. Check the law in your own jurisdiction and in each participant's, and get your own legal advice, before you record.

For developers

Tamlil is two halves that share a recording database: a SwiftUI menu-bar app in Tamlil/ and a Python transcription pipeline in src/tamlil/ (run through uv). The commands below assume the checkout the installer creates at $HOME/Library/Application Support/Tamlil/repo; substitute your own path if you cloned elsewhere.

REPO="$HOME/Library/Application Support/Tamlil/repo"
cd "$REPO"

Run the pipeline by hand

uv run tamlil-pipeline ~/Recordings/Tamlil/<recording-id>

The mic track is labeled with your macOS first name; override with --me-name. Transcribe a single file with uv run tamlil-transcribe path/to/audio.wav. If a run fails, the audio is preserved under raw/ — fix the cause (usually the Soniox key or balance) and re-run; --skip-transcribe reuses an existing merge and only redoes the cheap local stages.

The pipeline, in order: look up the meeting roster and build recognition context; optionally denoise the mic track; transcribe both tracks concurrently; merge by timestamp with per-track speaker labels; suppress mic echo from the system track; apply learned lexicon rewrites; save clarification cards from low-confidence spans; and write final/transcript.{json,md}.

Read meetings from an AI agent

The connector (an MCP server) is read-only over the recording database and transcript files, exposing list_meetings, get_meeting, get_transcript, and search_transcripts. The installer registers it with Claude Code for you; to add it by hand:

claude mcp add tamlil -- uv run --project "$REPO" tamlil-mcp

For Codex (~/.codex/config.toml), point it at an absolute path:

[mcp_servers.tamlil]
command = "uv"
args = ["run", "--project", "/Users/<you>/Library/Application Support/Tamlil/repo", "tamlil-mcp"]

It honors TAMLIL_DB_PATH / TAMLIL_RECORDINGS_ROOT overrides and never writes — the database is opened read-only.

Recording storage

Each recording is a directory under ~/Recordings/Tamlil/<recording-id>/: raw/ holds the captured mic.wav and system.wav; work/ holds pipeline intermediates (denoised audio, per-track transcripts, the merged draft, the echo report); final/ holds transcript.json and transcript.md; logs/ holds the pipeline log. transcript.json keeps segment text, speaker diarization, language IDs, word timings and confidence, low-confidence spans, and the echo report.

Google Calendar setup (bring your own OAuth client)

The calendar feature — meeting titles and attendee names, also fed to the recognizer as context — is optional and stays off until you register your own Google OAuth client and point Tamlil at it (Tamlil ships none of its own). It's a five-minute, one-time setup: see docs/google-calendar-setup.md.

Source-first delivery

Tamlil is built and installed from source, not shipped as a notarized binary. Two consequences are deliberate:

  • Ad-hoc code signing. Tamlil/build.sh signs the app with codesign --sign - (no Developer ID, no notarization). Because you build it yourself, macOS runs it without a Gatekeeper detour, and the microphone and system-audio permission grants — keyed to the bundle id — survive every rebuild as long as the signature stays consistent.

  • Pull-and-rebuild updater. Check for updates runs scripts/update.sh, which pulls the latest source into your checkout, rebuilds, reinstalls, and relaunches. There is no Sparkle feed or separate update channel to trust; the source you can read is the source that runs.

Because the app runs from your checkout, its repo path is a first-run setting (Settings → Pipeline → tamlil repo); the installer sets it for you.

Troubleshooting

  • No permission prompts / silent recordings — check Tamlil is enabled under System Settings → Privacy & Security → Microphone and System Audio Recording, then relaunch. Grants are keyed to the bundle id and need re-approval if it ever changes.

  • swift build fails immediately — install or update the Command Line Tools with xcode-select --install; the build needs CLT 16+ (Swift 6). swift test is not supported (the package defines no test target); use make test-swift, which runs the app's built-in self-check.

  • Pipeline error on a meeting — the audio is preserved under raw/; re-run uv run tamlil-pipeline <dir> after fixing the cause (usually the Soniox key or balance).

  • Empty roster / no meeting titles — run uv run tamlil-auth to connect your Google account; see the Google Calendar setup above.

Contributing and stack

See CONTRIBUTING.md. The stack: uv (Python 3.12), Soniox stt-async-v5, requests, numpy, static-ffmpeg, SwiftUI, and SQLite.

License

Apache-2.0 — see LICENSE. Bundled third-party components are credited in NOTICE and THIRD_PARTY_LICENSES.

Available Tools

4 tools
get_meetingA

Full metadata for one meeting: roster, named speakers, transcript availability, and pending clarification count.

ParametersJSON Schema
NameRequiredDescriptionDefault
meeting_idYes

TDQS

A3.9/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 indicates a read operation on meeting metadata and enumerates the included data, but it does not disclose error behavior, permissions, or return format. This is acceptable for a simple get, but leaves some room for improvement.

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 one sentence, front-loaded with the core purpose, and every word adds value. It is extremely concise without losing important information.

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 one-parameter tool with no output schema, the description adequately scopes the result by listing key metadata components. It omits potential error cases or exact return shape, but given the simplicity, it is fairly complete for an agent to use correctly.

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

Parameters2/5

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

Schema description coverage is 0%, and the description adds no explanation of meeting_id beyond its name. Since the tool has one parameter and the description does not compensate for the lack of schema descriptions, the agent must infer the intended meaning from the parameter name alone.

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 full metadata for one meeting, listing specific components (roster, named speakers, transcript availability, pending clarification count). This distinguishes it from siblings like list_meetings and get_transcript, which have clearly different functions.

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 gives clear context on what this tool returns, implying it should be used when detailed metadata for a specific meeting is needed. It does not explicitly mention alternatives or when not to use it, but the focus on 'one meeting' differentiates it from list_meetings and get_transcript.

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

get_transcriptA

The meeting transcript, with resolved speaker names and clock timestamps.

By default this does NOT return the transcript text — a long meeting would
flood your context. It returns metadata plus `path`: a rendered transcript
file you should open with your own file tools, reading only the ranges you
need. To pull lines inline instead (e.g. no filesystem access), pass `limit`
(and optional `offset`) to get that slice of segment lines directly.
ParametersJSON Schema
NameRequiredDescriptionDefault
limitNo
offsetNo
meeting_idYes

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description carries the burden and does well: it discloses that by default it does NOT return the transcript text, returns a `path` to a rendered file, and warns about context flooding. It also clarifies the inline alternative, providing essential behavioral expectations beyond the schema.

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?

Every sentence provides value: the first states the core output, the second explains the default and the reasoning, the third explains the inline alternative. Well-structured in two readable paragraphs with no redundancy.

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 read-only tool with 3 parameters and no output schema, the description covers the essential behavior, default vs. inline modes, and the file path usage. It could be more explicit about when to prefer search_transcripts, but given the sibling list, the description is sufficiently complete for effective invocation.

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?

Schema coverage is 0%, so the description must compensate, and it does: `limit` and `offset` are explained as controlling a slice of segment lines, and `meeting_id` is implied via 'meeting transcript'. The distinction between default (no text) and passing `limit` clarifies the meaning of the parameter effectively.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool provides 'the meeting transcript, with resolved speaker names and clock timestamps' and distinguishes itself by describing its default behavior (metadata plus path, not text). The lack of an explicit verb like 'retrieves' is compensated by the tool name and the detailed description of what is returned.

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?

It explains when to use the default mode (avoid flooding context) versus when to pass `limit`/`offset` for inline text (e.g., no filesystem access). This gives clear usage context, though it does not explicitly name sibling tools like search_transcripts as alternatives.

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

list_meetingsA

List recorded meetings, newest first.

from_date/to_date are inclusive ISO dates (YYYY-MM-DD); app filters on the
meeting app name (case-insensitive substring, e.g. "zoom").
ParametersJSON Schema
NameRequiredDescriptionDefault
appNo
limitNo
to_dateNo
from_dateNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior3/5

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

With no annotations provided, the description carries the burden of behavioral disclosure. It adds useful context like 'newest first' sorting, inclusive date boundaries, and case-insensitive substring matching for the app filter. However, it does not mention pagination behavior, what happens when filters are omitted, or any permissions needed, leaving some behavioral aspects unclear.

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 two short paragraphs. The first sentence states the primary purpose, and the second paragraph details parameter behavior. There is no redundant information or filler; every sentence contributes to understanding how the tool works.

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 that an output schema exists, the description does not need to explain return values. It adequately covers the core behavior (listing recorded meetings with optional date and app filters, sorted newest first). The only minor gap is the lack of explicit mention of the limit parameter's behavior, but the schema provides a default, making the tool usable without further detail.

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?

The schema has zero parameter descriptions, so the description must compensate. It adds meaning for three of the four parameters: from_date/to_date are described as inclusive ISO dates, and app is described as a case-insensitive substring. The 'limit' parameter is left entirely to the schema, but its meaning is obvious from its name and default value, so the description covers most parameter semantics effectively.

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 'List recorded meetings, newest first,' which clearly states the action (list) and resource (recorded meetings). It also distinguishes itself from siblings like get_meeting (which retrieves a specific meeting) and get_transcript (which retrieves a transcript) by focusing on the list operation.

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 explains the filtering semantics (from_date/to_date inclusive, app as case-insensitive substring) and implies usage for listing meetings with optional filters. However, it does not explicitly state when to use this tool vs alternatives (e.g., search_transcripts) or mention any exclusions or prerequisites, so the guidance is implied but not fully explicit.

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

search_transcriptsA

Search all transcripts for a phrase (case-insensitive). Returns matching meetings, newest first, with the matching transcript lines as excerpts.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNo
queryYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description carries the burden and provides meaningful behavioral details: case-insensitive matching, newest-first ordering, and inclusion of matching transcript lines as excerpts. It does not cover limit behavior or edge cases, but the core behavior is disclosed.

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: two sentences with no filler, immediately stating the action and key return characteristics. Every word adds value.

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 search tool with an output schema, the description covers purpose, scope, sorting, and excerpt behavior. It does not need to explain return structure since the output schema exists, though limit behavior is not addressed.

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

Parameters2/5

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

Schema coverage is 0%, so the description must compensate but only implicitly covers 'query'. It does not explain the 'limit' parameter's meaning or effect, leaving a gap in parameter semantics.

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 specifies a unique action ('Search all transcripts for a phrase') with scope, case-insensitivity, and return format. It distinguishes from sibling tools (list/get) by focusing on search across all transcripts.

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 its use for finding content within transcripts, clearly distinct from listing or retrieving specific meetings. However, it does not explicitly mention exclusions or alternative tools when other actions would be more appropriate.

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. Dates show when Glama detected each change.

  1. 4 tool updatesv1.0.0
    • First observedget_meeting
    • First observedget_transcript
    • First observedlist_meetings
    • First observedsearch_transcripts

TDQS

A4.3/5.0
Disambiguation5/5

Each tool has a clearly distinct role: list_meetings filters and lists, get_meeting fetches metadata for one meeting, get_transcript retrieves transcript content, and search_transcripts finds phrases across transcripts. No two tools overlap in purpose.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with lowercase and underscores: list_meetings, get_meeting, get_transcript, search_transcripts. The naming is uniformly readable and predictable.

Tool Count5/5

With 4 tools, the server is well-scoped for a meeting/transcript archive. Each tool covers a core operation, and the count is neither too sparse nor excessive.

Completeness5/5

The server provides a complete read-only lifecycle: list meetings, get metadata, get transcript, and search content. There are no obvious dead ends for the stated purpose of retrieving meeting recordings and transcripts.

Maintenance

ActivitySlowing
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/Steven17D/tamlil'

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