The full upstream README, mirrored here for reference. Install config, tool schemas, adoption signals, and an original overview live on the Munin listing page.
Your whole customer operation, behind one MCP endpoint.
Website · See it in action · Documentation · MCP Registry
CRM, conversations, outreach, CMS, knowledge base, and analytics on one Postgres schema — exposed as MCP tools your agents drive, not screens you click through. Headless the way a headless CMS is: the dashboard owns settings, auth, and the human half of the work — an inbox where a person takes over a conversation, and a review queue where they approve what the agent proposed — but there is no admin UI to click your way through the data itself. Every action runs through MCP tools, callable from any MCP-compatible client (Claude, Cursor, ChatGPT, custom runners) — same tools, same permissions, same audit log, whether a human or an agent is driving. Munin even ships its own: an in-process, per-org agent runner that answers live conversations and works the curation queue against an LLM provider you configure — so the platform runs out of the box, with external MCP clients optional.

The console — settings, auth, the inbox, and the review queue. It drives the same MCP tools your agents call.

The review queue — outbound never sends itself. An agent drafts, files the evidence behind the draft, and waits; approving is the human's keystroke.

The embeddable chat widget — answering a live customer from the knowledge base, ready to hand off to a human and be picked back up by the agent.
| Module | Tools | What it does |
|---|---|---|
| Knowledge Base | kb_* | documents, hybrid search, audience scoping |
| Conversations | conv_* | channels, messages, handover |
| CRM | crm_* | contacts, companies, deals |
| CMS | cms_* | collections, entries, assets |
| Outreach | outreach_* | campaigns, drafts, propose-only |
| Analytics | analytics_* | page-view + search events |
These six modules aren't separate products — they share one Postgres schema, one permission model, and one audit log. Together with integrations and platform plumbing they add up to 223 MCP tools and 58 skills. Watch how they tie together:
Three kinds of integration, three homes. Which one you want depends on what the other system is.
Email over IMAP/SMTP, or a generated forwarding address you point your existing mailbox at. The embeddable chat widget, themeable and dark-mode aware, speaking 23 languages. Voice through Threll.ai or Vapi, SMS through Twilio or MessageBird. Each one is a channel adapter behind the same conv_* tools.
Slack mirrors each conversation into a thread: your team replies from the thread and the customer receives it, outreach proposals arrive with approve and dismiss buttons, and CMS publishes are announced with a link to the live article. The conversation, the approval, and the audit entry are the same ones the dashboard shows.
Read live over the vendor's API and never copied into Munin, so there is nothing to sync and nothing to go stale.
| Domain | Tools | Vendors |
|---|---|---|
| Commerce | commerce_* | Shopify, Magento 2 / Adobe Commerce |
| Bookings | bookings_* | Gastroplanner — availability, create, modify, cancel |
| Search Console | seo_* | Bing Webmaster Tools, Google Search Console |
| Anything proprietary | yours | any MCP server you run |
Commerce and bookings have a self-service half: an end-user agent in the chat widget looks up their own order or booking, bound to the caller's identity server-side rather than to whatever email the model was told. Search Console is operator-facing and admin-only. Connections are stored encrypted, authorize by API key or OAuth redirect depending on the vendor, and are managed from the dashboard's Integrations page.
Have a system no vendor adapter covers? Point Munin at an MCP server you run and its tools become connector tools, with per-connection allow-lists over which of them agents may call.
An in-process, per-org agent runner answers live conversations on every channel (chat widget, email, SMS, voice) against the LLM provider you configure — drafting and sending replies, and handing off to a human when needed.
The in-process agent runner also works a durable background job queue: scheduled KB curation, CRM hygiene, contact extraction, stale-content review, and outreach drafts, with retry and dead-letter handling.
Everything an agent proposes and a person decides lands in one queue — KB revisions, outreach proposals, merge proposals, drafted replies — and every decision is kept, so the Decided feed is a durable record of who approved what, not a list that empties as you work it.
Packaged markdown procedures (skill://module/<verb-object>) for multi-step, cross-module workflows, surfaced over MCP — followed both by Munin's own runner and by any external AI agent operating on the platform.
Symmetric *_export / *_import MCP tools (and /v1/<module>/export|import REST endpoints) per module, so an agent can move an org's data between a self-hosted server and the cloud in either direction. See skill://playbooks/data-migration.
One spine for the people on the other side of a conversation — a widget visitor, a caller's phone number, an email address, and your own system's user id resolving to the same person, addressable over MCP through identity_*.
Every action is written to an audit log, and webhooks fan those events out to your own endpoints with signed, replayable deliveries.
Operational issues surface as system alerts the agent can list, acknowledge, and resolve. An in-product feedback channel lets you file feature requests and vote on Munin's public roadmap.
Sign-in and access control run on BetterAuth, with OAuth 2.1 dynamic-client registration and team invites. Owners and admins reach the whole console; members reach the inbox and nothing else.
Lovable builds your frontend. Munin spins up your operations. One prompt, one MCP endpoint — and the agents do the rest.
Watch Lovable build a real website from a single prompt while Munin stands up everything behind it — the CMS the blog reads from, a seeded knowledge base, analytics, and a chat widget that already knows the business. No click-ops, no screens to wire up; the agent does the work, over one MCP endpoint. Then a real customer conversation plays out: answered from the knowledge base, handed off to a human when it matters, and picked back up by the agent to close.
Self-host (this repo): single-tenant, invite-only.
Secrets left at their .env.example placeholders are auto-generated on first boot and persisted in the munin-data volume — fine for local self-hosting. For shared or production deployments, set strong MUNIN_AUTH_SECRET + MUNIN_KEY_PEPPER + MUNIN_ENCRYPTION_KEY values (openssl rand -base64 48) in .env instead.
The first user to sign up becomes the org admin; subsequent users need an invitation token or an email whose domain is in MUNIN_ALLOWED_EMAIL_DOMAINS.
Hosted (https://www.getmunin.com): multi-tenant, one signup per org.
After docker compose up, the backend listens on :3001 and the dashboard on :3000.
http://localhost:3000 and register the first user — they become the singleton org admin.mn_admin_…). Shown once; treat like a password.The OpenAPI spec for the REST control plane is at packages/backend-core/openapi.json. To wire an MCP client like Claude or Cursor, see Connect your AI agent below.
Once you've signed up (hosted) or run docker compose up (self-host), point your MCP client at the URL — http://localhost:3001/mcp for self-host, or https://mcp.getmunin.com for hosted.
Claude Code (CLI):
Claude Desktop — add to your MCP config:
The first call triggers an OAuth consent screen in your browser, then your agent has the full tool surface — Knowledge Base, Conversations, CRM, CMS, Outreach, Analytics, and whatever connectors you've wired up.
Belong to more than one org? Every org also has its own endpoint at /mcp/o/<orgId>. Connect to that URL and the client is pinned to that org for good, instead of following whichever org you last made active.
Hosts that support MCP Apps get more than text back: proposals, curation candidates and connector results render as interactive panels served as ui:// resources, where a human clicks approve rather than asking the model to call the tool.
The same /mcp endpoint serves two distinct callers, audience-aware:
kb:*, conv:*, crm:*, cms:*, outreach:*, analytics:*, commerce:read, bookings:*, seo:*, connectors:*, identity:read, slack:*, webhooks:*.See packages/backend-core/src/control/delegated-token.controller.ts for the token-mint API. The @getmunin/sdk Node client wraps it.
Most of what these tools return is text nobody at your org wrote — inbound messages, CRM fields, imported articles, live records from a customer's store. Munin fences that content as data for its own runner, and tells external hosts the same thing in the server instructions; the real containment is still RLS, the audience gate, and per-skill tool allow-lists.
| Layer | Tech |
|---|---|
| Language & runtime | TypeScript, Node 24 LTS |
| Monorepo | Turborepo, pnpm |
| Backend | NestJS |
| Frontend | Next.js |
| Data | Postgres + pgvector, Drizzle |
| Protocol & auth | MCP Streamable HTTP, BetterAuth + OAuth 2.1 |
Developer docs live at getmunin.com/docs — guides, the REST API reference, the full MCP tool list, and the skill library.
Contributions are welcome. pnpm install, then docker compose up (or pnpm dev) gives you a full stack on :3001 (backend) and :3000 (dashboard). Branch from main as <type>/<kebab-summary> (e.g. feat/website-import-reconcile), keep PRs focused, and make sure CI (lint, typecheck, test, build) passes.
The screenshots above are generated, not hand-captured — see apps/web/capture/README.md to regenerate them after a UI change.
See CONTRIBUTING.md for setup, commit conventions, and PR guidelines.
Found a vulnerability? Please don't open a public issue — email security@getmunin.com instead. See SECURITY.md for scope and our response timeline.
MIT. See LICENSE.
Bundled third-party dependencies retain their own licenses — see THIRD_PARTY_LICENSES.md (generated by pnpm licenses:generate, verified in CI).