Most small teams already have a CRM. It is a Google Sheet. One tab for leads, one for contacts, a column called "Status" that three people update in three different ways.

This is not a failure of discipline. The sheet is genuinely good at the job: everyone can open it, nobody needs a login to a new tool, and the whole pipeline fits on one screen. The problem only shows up when you want an AI agent to actually work with it. An agent can read a sheet if you paste rows into the prompt. But ask it to add a lead, log a call, or tell you how many deals are stuck, and you are back to doing it by hand.

We built mcp-excel to close that gap. It is an open-source (MIT) MCP server that turns any Google Sheet into a working 4-entity CRM - leads, organizations, contacts, activities - that any MCP client can read and write. Claude Desktop, your own backend, an agent framework. The sheet stays the source of truth.

MCP in one paragraph

Model Context Protocol is an open standard that lets an AI agent call external tools. Instead of pasting data into a chat window, the agent gets a list of tools - "add a record", "search records" - and calls them the way code calls an API. An MCP server is the thing that exposes those tools. mcp-excel is such a server, and the tools it exposes operate on a spreadsheet.

What it actually does

Point the server at a Google Sheet and it manages four tabs: Lead, Organization, Contact, and Activity. Missing tabs get created on first connection; existing tabs are used as they are, and missing columns are appended without touching your data. If your sheet already has leads in it, the server works with what is there.

From your agent's side, a workflow looks like this:

"Add Priya from Acme as a lead, logistics segment." "Log a call with her - discussed pricing, follow up Friday." "How many leads are in negotiation this month?"

Each of those becomes a tool call: tool_add_record, tool_list_records with a filter, tool_get_pipeline_analytics for the breakdown by status and segment. There are ten tools in total, covering search, updates by ID, soft deletes, and foreign-key lookups like "all activities for this lead". There is also an optional one - tool_extract_business_card - that pulls contact fields from a photo of a business card using Claude Vision, if you set an Anthropic API key.

The design decision I care about: statelessness

Every tool call carries an explicit sheet_id. There is no session state, no "active sheet" variable sitting in memory. That sounds like a small thing, and it is the whole point.

It means one running instance can serve multiple teams safely, because nothing is shared between requests. It means the server can run as a plain HTTP service (FastMCP streamable-HTTP on port 5002) that your whole team points their agents at - or over stdio for a local Claude Desktop setup. No gateway, no ngrok, no subprocess babysitting.

A few smaller decisions came out of watching how real sheets behave:

  • Fuzzy header matching. Your column says "Company", the schema says "Organization Name". The server figures it out instead of refusing to work.
  • Auto-incrementing IDs that continue your pattern. If your leads go LD010, LD011, the next one is LD012. If there is no pattern, it falls back to UUIDs.
  • Soft deletes. Deleting a record sets a flag; the row stays. Spreadsheets are shared with humans, and humans ask where rows went.

Setup, briefly

You need a Google service account with the Sheets and Drive APIs enabled, and the sheet shared with that service account's email as an editor. Then:

pip install -r requirements.txt GOOGLE_APPLICATION_CREDENTIALS=creds.json python mcp_excel_server.py

Or run the Docker image with the credentials mounted as a secret. For Claude Desktop, set MCP_TRANSPORT=stdio and point the config at the script. The README has the full config blocks.

Why a spreadsheet and not a real database

Because the spreadsheet was never the problem. Small teams do not abandon CRMs because they love rows and columns; they abandon them because the CRM wants to own the workflow, and the sheet just holds it. Giving the agent structured access to the sheet keeps the part that works - everyone can see everything, all the time - and removes the part that did not: the manual entry.

At some scale you outgrow this, and that is fine. The teams this is for were never going to buy Salesforce this quarter.

If your agent could write to your spreadsheet CRM, what is the first chore you would hand it?

mcp-excel is open source under the MIT license: github.com/nifetency/mcp-excel. It comes from the same team building Nife; our hosted MCP server for deploying and managing apps is on the official MCP registry.