Call.md: a local-first meeting recorder that feeds MCP tools mid-call

What Call.md actually is, and who it is built for

Call.md is a desktop meeting recorder with an agent loop attached. The README describes it as turning meetings into "live agent loops": it records screen and audio locally, transcribes in real time through VideoDB, and runs intelligence on top of the transcript while the call is still happening. It ships as an Electron 42 application with a React 19 renderer, TypeScript 5.8 across both processes, tRPC 11 over a Hono server, and Drizzle ORM against a local SQLite database.

The audience is narrower than the tagline suggests. This is for people who take meetings on a Mac and want structured output afterward: a narrative overview, key points attributed to participants, and a list of action items. It is also for teams that already run MCP servers, because the app detects information needs in conversation and calls those tools automatically, then renders the results inline during the meeting. If you just want a transcript file, the MCP layer is overhead you will not use.

Dual-channel transcription and the MCP auto-trigger loop

The mechanism that separates Call.md from a plain recorder is channel separation. The app captures microphone audio and system audio as two streams, so the transcript knows which side of the conversation a sentence came from. That separation is what makes talk ratio, speaking pace in words per minute, questions asked, and monologue detection computable at all; a single mixed track cannot attribute any of those numbers. The README states the transcription is "powered by VideoDB" and that audio is sent to VideoDB over WebSocket for real-time transcription.

On top of that stream, three things run concurrently. Metrics tracking computes the conversation statistics. Coaching nudges are rate-limited alerts, which is a deliberate throttle rather than a feature gap: an assistant that interrupts on every turn is worse than one that stays quiet. Live Assist generates contextual suggestions such as things to say or questions to ask. Separately, an MCP agent watches for information needs and calls the matching tool, with outputs rendered in an MCP results panel as markdown, links, or structured data.

The data flow has a hard dependency worth stating plainly. Settings, meeting history, transcripts, and generated metadata live in the local SQLite database, but transcription and the AI features require internet connectivity. Local-first here describes storage, not operation.

Installing Call.md on macOS and running a first recording

The README gives a single install command for macOS 12+ on both Apple Silicon and Intel. It downloads and runs an installer script from the project's artifact host:

curl -fsSL https://artifacts.videodb.io/call.md/install | bash

After that, launch Call.md from Applications or Spotlight, grant the system permissions when prompted, and register with a VideoDB API key from console.videodb.io. Microphone and screen-recording permissions are required before the first recording; Google Calendar is optional and can be skipped during onboarding.

For a source build, the prerequisites are Node.js 22.12+ and npm 10+. The package scripts cover the usual loop, and the platform-specific packaging targets are named explicitly:

npm run build
npm run dist:mac
npm run dist:win
npm run dist:linux

On first use, set the meeting language under Settings then Transcription, or leave it on Automatic. Start a recording and you should see two separate transcript channels rather than one merged feed. Bookmarking marks moments for later reference, and when the meeting ends the app produces the three-part summary and can export to markdown with the full transcript and metrics.

The 2 hour recording cap, and platforms where recording is refused

The most concrete constraint is the recording limit. Recordings stop themselves after 2 hours of active recording time, with a warning 5 minutes before the cutoff. Pauses and system sleep do not consume the allowance, so the limit tracks real captured audio rather than wall-clock time. For a long workshop this is a boundary you have to plan around; the README does not document a way to raise it.

Platform support is the second limitation, and it is blunter. The VideoDB capture SDK ships recording binaries for darwin-arm64, darwin-x64, and win32-x64 only. Windows x64 recording works from a source build, but no hosted Windows installer is published. Linux and Windows ARM64 builds can run the UI, MCP servers, workflows, history, settings, and exports, but the app rejects recording before launch because no capture binary exists for those targets. Call.md also verifies at startup that the capture executable and the SQLite native module are present in the packaged app, so a broken package fails early rather than mid-meeting.

There is also an account dimension. Transcription and AI features need connectivity, and the API key can be validated or rotated from Settings, or you can log out and clear persisted session and Google credentials. The README does not document offline transcription, so treat the hosted dependency as structural.

How Call.md differs from Granola and Otter-style note takers

Most meeting note takers are single-channel: they capture the call as one audio stream and produce a transcript plus a summary. Granola and Otter-style tools follow that model, and it works well for note capture. The difference in Call.md is architectural. Because the microphone and system audio arrive as separate channels, the app can attribute statements to you versus them, which is what makes the conversation metrics meaningful rather than decorative.

The second difference is where automation happens. A conventional note taker hands you a document after the call and stops there. Call.md runs an MCP agent during the call, detects an information need from the conversation, invokes the tool, and shows the result inline. Post-meeting it can also push data to n8n, Zapier, or a CRM through workflow webhooks. If your team already maintains MCP servers, that is the reason to pick this over a summary-only tool. If you do not, you are paying for an integration layer you will never call.

Licence, maintenance and what an upgrade costs

package.json declares "license": "MIT", while the repository metadata carries no licence identifier. The MIT text in package.json is the concrete statement available; if you need certainty for redistribution, that discrepancy is the thing to resolve before you rely on it. Nothing here is legal advice.

The repository is not archived, and the last push was on 2026-08-19, so it is recent enough to treat as a live project, though there are no retrieved releases to compare against the 1.0.4 version in package.json. Upgrade cost sits mostly in the native pieces. The postinstall script runs electron-builder install-app-deps, which rebuilds native modules, and better-sqlite3 plus the capture binaries are the parts most likely to break across an Electron or Node bump. The app's startup verification of the capture executable and SQLite module is what turns that from a silent failure into a visible one.

Editorial conclusion

Adopt Call.md if you are on macOS 12+ or Windows x64, already hold a VideoDB API key, and want meeting transcripts that can call your own MCP tools while the call is still running. Skip it if you are on Linux or Windows ARM64, because the app rejects recording before launch when no capture binary is present, or if you need a meeting assistant that works without sending audio to a hosted transcription service. Before installing, confirm your machine matches the supported capture targets (darwin-arm64, darwin-x64, win32-x64) and that the packaged app finds its capture executable and SQLite native module, since Call.md checks for both at startup.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. video-db/call.md on GitHub