Building an MCP Integration for a CRM: A Go and Flutter Case

Tg Apps · Published October 7, 2026 · Sources checked October 7, 2026

Tg Apps implemented an MCP adapter for an operational CRM with a Go backend, a Flutter management interface, and MariaDB persistence. This technical case explains how defined tools reuse business services, how access is delegated, and how read operations and updates are kept distinct.

The architecture: an adapter over the existing CRM

The MCP endpoint lives in the Go backend and uses the official Go SDK with Streamable HTTP. The Flutter interface manages application registration, consent, active connections, and revocation. MariaDB stores grants and operation records. The assistant consumes tools; the Flutter interface remains part of the CRM.

Request path: assistant client → MCP endpoint → authorization and input checks → existing CRM services → structured result. The adapter reuses the domain services that already implement CRM rules. It does not introduce a second set of business rules inside prompts.

The read catalog contains 11 tools covering companies, leads, projects, Kanban, activities, work logs, receivables, dashboard summaries, pending work, and events. Parameters and result shapes are defined per tool, with pagination and bounded access to operational data.

Delegated access rather than shared CRM credentials

The human user keeps the existing CRM login. A separate OAuth grant authorizes the assistant client. This implementation uses authorization code flow, PKCE S256, rotating refresh tokens, and revocation. The user reviews the requested scopes in the Flutter consent interface.

Delegation is limited to workspace owners in this case. The server derives the company boundary from the authenticated principal and checks the required scope for each operation. An identifier supplied by the assistant does not grant access to another company.

The authorization design follows the mechanisms described in the MCP authorization specification and PKCE specification. These references explain the mechanisms, not a certification of the implementation.

Read tools, proposals, and executable updates are different

The action catalog models 21 proposal types. Only record_payment has an executor in the reviewed implementation. The other 20 can produce proposals but cannot execute them. A supported proposal type is therefore not evidence that every CRM operation is available as a write tool.

The executable operation uses the existing financial service, validated inputs, an operation ledger, and idempotency controls. The direct path is enabled by policy and a specific write scope. It does not require a separate owner approval for each call, so it should not be described as universally human-confirmed execution.

This is an implementation boundary, not a recommendation to enable the same financial action in another business. Each client chooses the tools, access, and approval model needed for its own workflow. Consultation and task preparation can be useful starting points.

Validation evidence at each layer

Isolated tests: the recorded checks cover authorization, company separation, proposal versions, repeated requests, and financial consistency using an isolated local environment.
Published components: the adapter, OAuth support, management interface, persistence changes, and proxy correction are recorded as published.
Real-client authorization: a real OpenAI client completed consent and received a token.
Next acceptance check: real-client tool discovery and a read-tool call after the final proxy correction remain unconfirmed in the reviewed record.

These checks answer different questions. A registered grant proves delegated access; a listed tool proves discovery; a successful query proves the read path; an approved update needs its own result and consistency checks. No synthetic payment was created in the production financial system during this publication.

For a new integration, keep a compact evaluation set: permitted query, denied query, cross-company denial, expired or revoked access, repeated request, and the exact update flow being enabled. Run it against the assistant client the team will actually use, as described in OpenAI's MCP testing documentation.

What this case carries into another project

The reusable lesson is a small adapter with explicit tools over established business services. Keep identity and permissions on the server, separate read and write capabilities, preserve operation history, and verify the real assistant connection independently from local tests. Another CRM can apply those decisions without adopting Go, Flutter, or MariaDB.

Tg Apps offers MCP development as an optional service already included in the monthly plan, within agreed capacity and priorities. Contract and NDA precede kickoff, with no upfront payment. Delivery cycles follow the selected plan; production releases follow the agreed release plan. D-U-N-S 651029828 identifies the operating company.

Start with the buyer's guide to connecting AI to internal tools or explore AI and MCP integration services to define your first working delivery.

Implementation basis and technical references

The case is based on Tg Apps implementation records reviewed on October 6, 2026. The references below explain the protocol and authorization mechanisms; the project repository and operational records are private.