dealloop
All Posts
ProductDeveloper ToolsMCPAPI

Your Meeting Data Should Be Yours to Program Against

Launching dealloop's Developer API and MCP Server

Will Czubakowski·Co-founder & CTO··6 min read

There's a growing conversation right now about meeting tools and data portability. People are realizing that their meeting notes, transcripts, and conversation data are locked inside products that don't let them get it back out — at least not easily, and not on their terms.

We've been watching this play out and decided to ship something we've been building: a local Developer API and a local MCP server for dealloop.

This isn't a reaction to any single event. It's a reflection of how we think about the relationship between a product and the person using it. Your data should be yours to work with.

What We Shipped

A Local Developer API

The Developer API gives you a clean REST interface over localhost. It's designed for the tools you already use: shell scripts, curl, Postman, local agents, and custom tooling.

# Health check
curl http://127.0.0.1:6070/v1/health

# List conversations
curl -X POST http://127.0.0.1:6070/v1/list-conversations \
  -H "Authorization: Bearer <your-api-key>" \
  -H "Content-Type: application/json" \
  -d '{"limit": 10}'

It binds only to 127.0.0.1, not a public interface. It runs with a locally-generated bearer token, and it's started explicitly from dealloop itself.

Developer API settings showing localhost endpoint, API key, and example requests

A Local MCP Server

The MCP server is designed for AI tools that speak the Model Context Protocol — Claude Desktop, Cursor, and other MCP-compatible clients. But it follows the same principle: it doesn't bypass the dealloop app.

The headless MCP process talks to the running desktop app over local IPC (Unix socket), and the desktop app is still the authority on whether data access is allowed. If you turn off MCP data access, connected clients get a clear, actionable error — not a silent failure.

A Single Control Point

The controls live in the product, not in a config file buried somewhere on disk.

You can:

  • Allow or block MCP data access — one toggle, immediately enforced
  • Enable or disable the Developer API — starts and stops the local HTTP server
  • Require an API key for the REST surface
  • See the local connection details directly in the app

Developer Tools settings — MCP data access and Developer API controls, all in one place

Why Local-First Matters

The easiest way to ship a feature like this would have been to create a remote API, dump tokens into a config file, and call it a day.

We chose the harder path because it's the better product.

By keeping the signed-in dealloop desktop app at the center, you get a cleaner trust model:

  • No remote credentials to manage. Both the REST API and MCP server are powered by the same authenticated session running on your machine.
  • No new attack surface. The API is localhost-only. The MCP bridge uses owner-only Unix socket permissions.
  • No silent access. If you disable MCP data access, it's disabled. Period. The client gets a human-readable explanation, not an opaque transport error.
  • No config file archaeology. Everything is visible and controllable in the app.

The desktop app isn't just a UI shell. It's the enforcement point. It knows who you are, what company you belong to, whether you're signed in, and whether you've chosen to allow external tools to access your data.

The Engineering

We treated this like infrastructure, not a demo feature.

Both the Unix-socket IPC path and the localhost REST API share the same handler layer, so request semantics stay aligned across transports. That gave us one place to enforce:

  • Strict method checks
  • Content-type validation
  • Bounded request body sizes
  • Unknown-field rejection
  • Consistent error envelopes
  • Explicit auth-state handling

On the transport side:

  • The Developer API is localhost-only
  • The MCP bridge uses owner-only Unix socket permissions
  • Stale or unsafe socket state is handled defensively
  • Developer settings are persisted with atomic writes
  • Local auth is ephemeral and memory-only when enabled

We put real care into failure modes. If the app is signed out, access fails explicitly. If MCP access is disabled, the client gets a human-readable explanation. If the desktop app is unavailable, local clients see that clearly.

Local integrations are still integrations. They deserve the same engineering discipline as any public API surface.

The Bigger Idea

This release isn't just about REST or MCP.

It's about building developer tools that respect the person whose data is being exposed. "Developer-friendly" shouldn't mean "quietly permissive." It should mean secure defaults, explicit controls, understandable behavior, and architecture that makes those promises real.

The Developer API and MCP server make dealloop data easier to work with — but they do it in a way that keeps you in charge. For us, that's the actual feature.

The Developer API and MCP server are available now in dealloop for macOS. Download dealloop to get started.