`archive_contact` is a soft delete and the database scripts archive before they reset, so the failure mode of letting an assistant tidy your contacts is a hidden record rather than a lost one. The trade is that this is single-machine by design: no sync, no sharing, one SQLite file. That is a good fit for a personal pipeline and a bad one for a team.
A small CRM that stores everything in a local SQLite database. Contacts, the history of calls, emails, meetings and notes against each one, follow-up todos, and CSV exports — all managed through tool calls rather than a web app.
- Contacts — `add_contact`, `update_contact`, `get_contact_details`, `list_contacts`, `search_contacts`, `list_contacts_by_organization`, `archive_contact` (a soft delete)
- History — `add_contact_entry` records an interaction typed as call, email, meeting, note or task; `update_contact_entry`, `get_contact_history` and `get_recent_activities` read and correct it
- Follow-ups — `add_todo`, `update_todo`, and `get_todos` with filtering by contact, completion, `days_ahead` and `days_old`
- Exports — `export_contacts_csv`, `export_contact_history_csv`, `export_full_crm_csv`, `export_todos_csv`
- The database lives at `data/crm.sqlite` and is created automatically on first run
- Command-line helpers archive, list and restore database snapshots, so a reset keeps the old data
Node.js 18+ and npm. Published as mcp-crm version 1.0.0; the documented path is clone, `npm install`, `npm run build`, then register node against `./build/crm-server.js` with `cwd` set to the checkout. No account, no key, no network — the database is a file in the project directory, and it is git-ignored by default.
Build from source — clone the repository and build it, then point your client at the binary