Call.md: a local-first Electron recorder that turns meetings into agent loops
Turn meetings into live agent loops. Record, transcribe, and analyze meetings with real-time AI intelligence — before, during, and after calls.
At a glance
- What is it?
- Call.md records dual-channel audio, transcribes you versus them through VideoDB, and runs MCP tools mid-call. It is a macOS-first desktop app, not a hosted meeting bot, and its recording path is the part that constrains everything else.
- Who is it for?
- Adopt Call.md if you are on macOS 12+ and want transcripts, talk-ratio metrics and MCP tool output in the same local SQLite store, with a VideoDB API key already in hand. Skip it if you need Linux or Windows ARM64 recording, or a hosted bot that joins calls without local capture binaries.
- Can I use it commercially?
- Not without permission. GitHub finds no licence file in the repository, and without a licence all rights are reserved by default: you may read the code but not reuse it. Check the README, or ask the authors, before using it.
- Is it still maintained?
- Yes. The repository last received commits 28 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Call.md targets: meetings that need tools, not just notes
Most meeting recorders produce a transcript and stop. Call.md is built for a narrower case: a call where you need information fetched while the call is still happening. The README describes an MCP agent that detects information needs from the conversation and calls your MCP tools automatically, with results rendered inline in a panel during the meeting. That is a different job from summarization. It means the app has to hold a live model of what is being discussed, decide that a tool call is warranted, run it, and display structured output without breaking the recording.
The intended user is someone on a technical or sales call who already has MCP servers configured for the things they look up: internal docs, a CRM, a pricing table. It also suits people who want to review their own conversation habits. The metrics list is explicit about this: talk ratio, speaking pace in words per minute, questions asked, monologue detection, plus rate-limited coaching nudges. Nothing in the material suggests team dashboards or shared workspaces. Storage is a local SQLite database holding settings, meeting history, transcripts and generated metadata.
Dual-channel capture and the WebSocket path to VideoDB
The mechanism that separates Call.md from single-stream recorders is channel separation. The app captures microphone audio and system audio as two channels and sends them to VideoDB over WebSocket for real-time transcription, with the README framing the output as you versus them. That split is what makes the conversation metrics meaningful: talk ratio and monologue detection need to know which side of the call a sentence came from, and a mixed stream cannot give you that reliably.
Screen capture runs alongside both audio channels. Transcription and the AI features require internet connectivity, which the README states directly, so the local-first claim applies to storage rather than to processing. Settings, history, transcripts and metadata sit in SQLite on disk; the audio leaves the machine for transcription. Anyone reading local-first as offline-capable should correct that expectation before installing.
After a recording ends, the app runs three parallel extractions: a short narrative overview, key points by topic attributed to participants, and action items. Markdown export bundles the full transcript, the summary and the metrics. Workflow webhooks can push meeting data to n8n, Zapier or a CRM on meeting end. The three-part split is a reasonable design choice, since a narrative summary and a list of attributed key points fail in different ways, and running them separately stops one from flattening the other.
Install commands and the platform table you should read first
The README gives one hosted install path, for macOS, as a curl pipe to bash from artifacts.videodb.io. After installing, you launch the app, grant microphone and screen-recording permissions when prompted or later from Settings, and register with a VideoDB API key obtained from console.videodb.io. Google Calendar is optional and can be skipped during onboarding.
Everything else is a source build. Windows x64 uses npm run dist:win and recording is supported, but the project does not publish a Windows installer. Windows ARM64 does not support recording at all. Linux uses npm run dist:linux; the app features work, recording does not. The reason is stated plainly: the VideoDB capture SDK ships recording binaries for darwin-arm64, darwin-x64 and win32-x64 only. On platforms outside that set, the app rejects recording before launch rather than failing partway through a call.
The app also verifies at startup that the capture executable and the SQLite native module are present in the packaged app. That check is the practical thing to test on Windows x64 source builds, because a missing native module is a packaging problem, not a code problem. Development requires Node.js 22.12+ and npm 10+. The stack is Electron 42, TypeScript 5.8, React 19, tRPC 11 over Hono, Drizzle ORM on SQLite, with the VideoDB SDK at 0.3.0, MCP SDK at 1.0.0 and OpenAI SDK at 6.19.0. There are no retrieved releases, so version pinning means tracking the main branch rather than a tagged artifact.
The two-hour cap and other limits that shape how you use it
Recordings stop themselves after two hours of active recording time, with a warning five minutes before. Pauses and system sleep do not consume the allowance. That is a deliberate ceiling, and it is the constraint most likely to bite: a long workshop, a full-day interview loop, or a training session will be cut. The pause behaviour softens this, since you can stop the clock during breaks, but it does not remove the ceiling. If your meetings routinely run past two hours, this is the wrong tool regardless of how well the rest fits.
Transcription language is set in Settings under Transcription, or left on Automatic. The README does not describe what Automatic does with code-switching or with a call where participants speak different languages, so treat that as unverified.
There is a second limitation worth naming: the intelligence layer depends on a remote service. Live Assist, coaching nudges, MCP triggering and the post-call summaries all route through VideoDB and its OpenAI-compatible API. A dropped connection does not just cost you a transcript; it costs the parts of the product that justify choosing it over a plain recorder. The README states that transcription and AI features require internet connectivity, and does not describe an offline queue or a retry path for missed segments.
On the MCP side, automatic triggering is a double-edged default. The agent decides when a tool call is warranted. The material does not describe a confirmation step before a tool runs, nor a per-tool allowlist, so the practical risk is an unexpected call to a tool with side effects during a live meeting. Anyone connecting a write-capable MCP server should test triggering behaviour on a throwaway call first.
Where it sits against transcript-first note takers
The closest category is the cloud note taker that joins the meeting as a participant and returns a summary afterwards, with Granola and Otter occupying that space. The difference is architectural, not cosmetic. Those tools take a single mixed audio stream from the conferencing platform and do their work after the fact. Call.md captures locally through the OS, keeps mic and system audio on separate channels, and runs part of its intelligence during the call. That buys you talk-ratio metrics that a mixed stream cannot produce, and it buys you tool output mid-conversation. It costs you platform coverage, because local capture is exactly what limits the app to macOS and Windows x64.
A second comparison is the DIY route: a local Whisper model plus a script. That gives you no per-speaker channel split without extra work, no live MCP loop, and no metrics, but it runs offline and has no two-hour cap. Call.md is the better fit when the live loop is the point. The DIY route is better when the transcript is the point and connectivity is a problem.
A third is the general-purpose agent desktop, which can call MCP tools but has no meeting capture pipeline at all. Call.md's contribution is the wiring between capture, transcription and tool invocation, not the tool invocation itself.
Maintenance cost, licence status and what to check before adopting
The repository lists no releases, so there is no versioned artifact to pin to and no changelog to read before upgrading. Updates arrive through the curl installer on macOS or through rebuilding from source elsewhere. The last push recorded is 2026-08-19, which tells you the project is active but says nothing about how often the capture binaries are refreshed. Since the app hard-fails when a capture executable is missing, a VideoDB SDK bump that changes binary layout is the failure mode to watch.
The licence is not stated in the supplied material, and the README's license shield links to a generic license URL rather than naming a licence. That is a genuine gap. It affects redistribution, internal forking and commercial use, and it cannot be resolved by reading the README. Check the repository for a LICENSE file before you build anything on top of it. This is not legal advice; it is a note that the information is absent.
The API key is a recurring cost and a recurring operational concern. The app supports validating and rotating the key from Settings, and logging out clears persisted session and Google credentials. Rotate the key if a machine is handed on. Google Calendar sync is optional and its credentials are part of what logout clears, which is the right default.
Editorial conclusion
Adopt Call.md if you are on macOS 12+ and want transcripts, talk-ratio metrics and MCP tool output in the same local SQLite store, with a VideoDB API key already in hand. Skip it if you need Linux or Windows ARM64 recording, or a hosted bot that joins calls without local capture binaries. Before installing, check two things: whether the installer at artifacts.videodb.io publishes a licence file, since the repository does not state one, and whether the capture executable plus SQLite native module actually land in the packaged app on your machine, because the app refuses to record without them.
Community notes