You can build this yourself. Here is when you should.
Open-source SuiteCRM MCP servers exist, and so do read-only database connectors for Claude Desktop. They are good work. This page is the honest comparison, including the cases where building wins.
| Open-source MCP server, self-hosted | Read-only database connector | SuiteMCP | |
|---|---|---|---|
| Hosting and updates | You run it, patch it and keep it up | Runs on each desktop | Hosted, updated for every customer at once |
| Sign-in | Usually a password or token in a config file | Database credentials in a config file | OAuth 2.1 with PKCE; the CRM password is used once and never stored |
| Permissions | Depends on the credential you configure | Whatever the database user can read | Every call runs as the signed-in CRM user under their SuiteCRM roles |
| Writes | Some | None | Yes, with read and write tools annotated separately and a read-only trial |
| Views inside the chat | No | No | Dashboards, boards, charts and forms from any module |
| Phone | Desktop only | Desktop only | Web, desktop and the Claude app |
| Custom modules | If you add code | If the table exists | Automatic, from the instance’s own metadata |
| Who to call | Your team | The vendor’s support | A person within one working day |
Build it yourself when you have an engineer who wants to own it, one instance, one user, and no need for writes or views. Otherwise the connector is a URL and a login.
The open-source and database options described are the public projects a search for “SuiteCRM MCP server” returns in September 2026. Their authors did honest work and this table describes their stated scope, not their quality.
What we learned building it, so you do not have to
The V8 API has edges. One filter operator per request. Only database-backed columns are filterable. Access denials arrive as HTTP 400. Numbers come back as strings. Concurrent writes touching related records can fail on the CRM side. Each of these cost us real time and is handled.
Tool count is load-bearing. We measured it: 26 tools left smaller models unable to answer at all; a core set of 5 worked and cut the prompt by 79%. The service exposes the right set per plan for that reason.
Sign-in is the hard part. OAuth 2.1 with PKCE, dynamic client registration, audience-bound tokens, rotation with reuse detection, and a login page that never stores the CRM password. That is most of the work, and most of the security review.
Views are the reason people keep using it. A paragraph about the pipeline is a novelty. A dashboard you can drag is a habit. Building the interactive views from live metadata, for any module, is the part nobody wants to maintain alone.
Say it.
Done.
Every CRM your team already has, now something they will use.