What an MCP Server Does for a Small-Business CRM (and When It Is Worth Building)

An MCP server gives an AI assistant a fixed menu of things it is allowed to do with your CRM, each with a name, a description written for the model, and a schema for its arguments, behind a key that decides whether it may write. The Model Context Protocol, which Anthropic published as an open standard in November 2024, defines the menu format so that any assistant that speaks it can use any server that offers it.

For a small business the question is not whether to have one but whether to build one. As of September 2026, HubSpot and Zoho ship official servers, Salesforce has one, and Zapier and Composio bridge most of the rest. Build your own when the data already lives in a database you own, or when the tools need to speak your vocabulary. Otherwise use the one you are already paying for.

The example below is the server on WBX Creative's own CRM, built on Supabase and running at /api/mcp: 26 tools, API-key authentication with scopes, and a log of every write.

What is an MCP server made of?

The protocol has three parts. A host is the application the person talks to: Claude, ChatGPT, or a code editor. It runs a client for each server it connects to. The server is the thing you build: a process or URL that advertises tools (actions), resources (data the model can read), and prompts (templates), over standard input and output locally or Streamable HTTP remotely.

Revisions are dated 2024-11-05 through 2026-07-28, which is current as of September 2026 and made the core stateless, removed the initialize handshake and protocol-level sessions, and added a mandatory server/discover. The authorization model for remote servers is OAuth 2.1 with PKCE. Claude, ChatGPT's developer mode (which confirms writes with the person), Cursor, VS Code with Copilot, Gemini CLI, and Copilot Studio all connect as of September 2026, and Claude.ai and Claude Desktop cap a tool result at about 150,000 characters.

The difference from a plain API is not technical. The WBX CRM already has a REST API with an OpenAPI document an agent can be pointed at. What MCP adds is a description of each tool written for a model rather than a developer. The search tool's:

Full-text search across customers, contacts, deals, tasks, projects, and invoices. Call this FIRST to resolve a fuzzy name ("the Henderson site", "that overdue invoice") to a numeric id before any get_/update_/complete_/delete_ tool.

That sentence is the interface. (Henderson is the placeholder name the tool examples use.)

The 26 tools, grouped:

Group	Tools	Needs a read-write key
Orientation	agenda, search	No
Read	list_tasks, get_task, list_customers, get_customer, list_contacts, list_deals, list_projects, list_invoices, list_activities, list_recurring	No
Tasks	create_task, update_task, complete_task, reopen_task, snooze_task, delete_task	Yes
Customers and deals	create_customer, update_customer, create_deal, update_deal	Yes
Timeline	add_note, log_email	Yes
Recurring	create_recurring, set_recurring_active	Yes

agenda returns overdue tasks, tasks due today and this week, unpaid and overdue invoices, projects due within 14 days, and today's date in the owner's timezone so "next Friday" resolves correctly.

How does a request get through?

A request is one HTTPS POST to /api/mcp with a JSON-RPC 2.0 body and a bearer key. The server is stateless, so every request authenticates from scratch:

1. Authentication. The key is hashed with SHA-256 and looked up; the database holds the hash and a short display prefix, never the key. A revoked or expired key gets a 401.
2. Method. initialize, ping, tools/list, or tools/call.
3. Argument validation. Every tool has a JSON Schema for types, enums, required fields, and date and time formats. Nothing reaches a handler without passing it.
4. Scope. A key's scope is read-only or read-write (the schema also allows an admin value, which the route treats like read-write) and may carry an allow-list of record types. A write tool on a read-only key, or a task tool on a deals-only key, is refused.
5. Handler, then the record. The tool runs against the CRM's Postgres schema through PostgREST. Creates, updates, and deletes land in the audit log with before and after snapshots and on the record's timeline; notes and logged emails go to the timeline; recurring-task changes go to the audit log. The key is the actor on every entry.

Validation and scope failures come back in-band, as a tool result flagged isError that says what to do instead. Send a lowercase stage name and the reply is "Allowed values: Lead, Proposal, Negotiation, Won, Lost." Try to create a task on a read-only key and the reply is "Read tools still work with this key."

Its limits:

• It speaks an older revision. The server negotiates protocol versions up to 2025-06-18. It is already stateless, so the move is mechanical, but as of September 2026 it has not been made.
• Static keys, not OAuth. A bearer key minted in the admin, not a public connector with a login screen.
• Tools only. No resources, no prompts.
• Whole-list reads. list_customers returns everything, right for a studio's client list and wrong at 10,000 rows.

When is a custom MCP server worth building (and when is it not)?

Start with what has gone wrong. In 2025: tool descriptions carrying hidden instructions, reported in April, and a Supabase MCP demonstration in July in which text in a support ticket, read by an agent holding a service-role key, was executed as instructions. In 2026, a cross-tenant token-reuse flaw in the Terraform MCP server was scored CVSS 10.0 in July. The OWASP MCP Top 10, still in beta, lists token mismanagement first and tool poisoning third.

no system is completely immune

The Supabase case matters here because my CRM runs on Supabase. The WBX server never hands the model SQL or a service-role key; it can call 26 named tools with validated arguments and nothing else. The lesson still applies one level up: text in the CRM is input to the model. A note that arrived through a contact form will be read by the next assistant that pulls that customer's timeline, which is why that assistant's key should be able to do no more than its job. The spec's security guidance says a server must verify every inbound request, must not treat a state handle as authentication, and must not accept tokens issued for something else. The WBX server keeps to those rules mostly because it has no sessions, no handles, and no OAuth yet; its own API key is the only credential it accepts.

The money, as of September 2026:

If your CRM is	You already have	Build a custom server?
HubSpot	An official server at mcp.hubspot.com behind OAuth (its developer page still says OAuth 2.0, with OAuth 2.1 and PKCE promised, as of 2026-09-23): read and write on contacts, companies, deals, tickets, and engagements; read-only on users, campaigns, and CMS pages	No
Zoho CRM or Bigin	Zoho MCP at no added charge over your subscription, covering 50-plus Zoho apps per its pricing page on 2026-09-23	No
Salesforce	The DX MCP server; Agentforce from $2 a conversation	No
Pipedrive	No official server listed on Pipedrive's pricing or developer changelog pages on 2026-09-22. Zapier MCP (9,000-plus apps) or Composio (free to 100,000 calls a month, then $29) bridge it	Rarely
A database you own	Nothing, until you write it	Yes, if the API and the data model already exist

In plain terms: HubSpot Sales Hub Professional is $90 a seat a month on annual billing plus $1,500 onboarding, so a five-person team pays $450 a month for a server with OAuth, maintained by people paid to maintain it. A custom server beats that on no axis except control. It wins when the CRM is custom, which for most companies of two to 20 people it should not be: the CRM playbook is the argument for buying one, and the stack piece is the confession of why I did not.

How I set it up

The server is one route file in the same Next.js app as the CRM. Beyond what the walkthrough above shows, two decisions:

1. One key per assistant or job, named for it, scoped to what the job touches, and set to expire, so the audit log says which key did what. That is a recommendation, not a record I can show; the schema's default scope is read-write, so read-only has to be chosen when the key is minted.
2. Tool descriptions are written as instructions. Resolve ids with search first, never guess an id, prefer complete_task or snooze_task over delete_task, use the agenda date for relative-date math.

Next, in order: the 2026-07-28 revision, then OAuth, for which Vercel's mcp-handler 2.x implements the current spec and ships an auth wrapper. Until then the server stays where a static key is appropriate: my own tools, my own data. The technical services page describes this kind of work, the bio covers the CRM years at Pravada on HubSpot, Zoho, and Pipedrive, and the Claude Code opinion piece is the wider account of building with agents. Ask me which row you are in.