How to connect your AI to your agency stack with MCP

To connect your AI to your agency stack with MCP, you generate a token in the MCP module, point your MCP client (Claude, Cursor, or any other) at the sSystm endpoint, and your AI can immediately read and act on your real CRM, projects and billing — 29 tools and 35 resources in all. Reads happen instantly; every write is staged as pending until a human approves it. This is a practical, step-by-step guide to doing it and understanding what happens at each step.

If you want the background theory first, start with what MCP is and how your AI uses it. This post is the hands-on companion: less about the standard, more about getting your own AI working your actual workspace.

What MCP is, in one line

MCP (Model Context Protocol) is an open standard that lets an AI client connect to an external system over a single endpoint and use two things it exposes: tools (actions it can take) and resources (data it can read). Think of it as a universal adapter — instead of every AI needing custom code to talk to every app, any MCP client can talk to any MCP server.

That is the whole idea. The rest of this guide is about what “tools” and “resources” mean in practice, and how connecting one gives your AI real reach into your agency’s data.

Tools vs resources: the two things your AI gets

When your client connects to sSystm, it discovers two kinds of capability. The distinction matters because it maps directly onto the safety model later.

	Resource	Tool
What it is	Data the AI can read	An action the AI can take
Addressed by	A URI, e.g. sstm://crm/deals	A name + typed schema, e.g. sstm_crm_add_contact
Example	Your live pipeline, a project’s full context	Create a contact, draft a component
Changes your data?	No — read only	Yes — and so it is human-gated
How many in sSystm	35	29

Resources are how the AI grounds itself in your real data before it acts — it reads your actual deals, tokens or project context rather than guessing. Tools are how it does something once it understands the situation. A good AI session almost always reads resources first, then proposes a tool call.

Step by step: connect your MCP client to sSystm

Here is the connection flow. The exact button labels evolve as the product does, so these are the conceptual steps rather than a fixed menu path — but the shape is always the same.

1. Open the MCP module in your workspace and generate a token. This token is what authorises your AI client to act as you. Treat it like a password: store it in your client’s secure config, never in shared code or a public repo.
2. Add sSystm as an MCP server in your client. In Claude Desktop, Claude Code, claude.ai (via a custom connector) or Cursor, you register a new MCP server by giving it the sSystm endpoint URL and the token you just generated.
3. Let the client discover the surface. On connecting, your client reads the list of available tools and resources automatically. You do not wire up each one by hand — the 29 tools and 35 resources appear as capabilities the AI can now choose from.
4. Ask for something grounded in your real data. Try a read first: “summarise my open deals” or “show me the full context of the Northwind project”. The AI reads the relevant resource and answers from your actual workspace.
5. Ask for a change, then approve it. Now try a write: “add a contact for the new lead from that email”. The AI proposes the sstm_crm_add_contact call — and it waits. Nothing is written until you approve it (more on this below).

That is the entire loop. Once connected, the same AI you already trust is working your CRM, projects and billing directly, not answering trivia about them from a bolted-on chat box.

What your AI can actually reach

The sSystm MCP surface is 29 tools and 35 resources covering the whole workspace, not a demo slice. A sample of what that spans:

Domain	Example tools	Example resources
CRM	sstm_crm_add_contact, sstm_crm_add_deal	sstm://crm/deals, sstm://crm/contacts
Projects	sstm_project_create, sstm_project_link	sstm://project/{id}/context, sstm://projects
Design system	sstm_design_add_token, sstm_component_create	sstm://design/tokens, sstm://component/recipe
Content & marketing	sstm_content_draft, sstm_campaign_create	sstm://content, sstm://newsletters
Documents & calendar	sstm_calendar_add_event	sstm://documents, sstm://calendar/events

For a worked CRM example — connecting an AI to contacts, companies and deals, and what it can and cannot do there — see how to connect your AI to your CRM. The full MCP story maps every tool and resource in detail.

How human approval keeps writes safe

This is the part that makes connecting an AI to live client data sane rather than reckless. Read access over MCP is immediate — the moment your client is connected, it can query your pipeline or a project’s context. Writes follow a stricter rule: every action that changes state is staged as pending, a human reviews exactly what it wants to do, and nothing executes until it is approved.

Concretely, the flow for a write looks like this:

1. Your AI proposes a tool call — say, creating a deal — with the exact arguments it intends to use.
2. sSystm stages that call as pending instead of running it.
3. A person on your team sees precisely what will happen and approves or rejects it.
4. Only on approval does the action execute. Every run, approved or rejected, is recorded so the whole team can audit it — not just the person who clicked.

Automations that run on Cloudflare get an extra guard: they are risk-classified before they run, so a low-risk read and a state-changing deploy are not treated the same. The principle is constant whether the AI acting is sSystm’s own platform agent or your externally connected client: the AI proposes, a human gates. For the full mechanics, see how it works.

Why the data stays yours the whole time

A fair worry when you connect an AI to your CRM is: where does all this data go? With sSystm the answer is nowhere new. sSystm is BYOC — Bring Your Own Cloud — which means there is no central vendor database. When you sign up, a dedicated Cloudflare D1 database is provisioned on your account, in the region you choose.

So every read and write your AI makes over MCP lands on that database, on your account, under your jurisdiction choice. You are not piping client records through someone else’s central store to make AI useful. The same ownership guarantee that applies to your team applies to your AI — a point explored in can AI build your software without locking you in?

A quick checklist before you connect

If you are wiring up a client for the first time, run through this:

• Generate a fresh token in the MCP module rather than reusing one — and store it in your client’s secure config, never in a repo.
• Start with reads to confirm the AI is seeing your real workspace before you let it propose writes.
• Decide who approves. Because writes are human-gated, agree on your team as to who reviews pending actions, so nothing sits waiting.
• Check the region your D1 database is pinned to if data residency matters to you or your clients.
• Revoke when done if you connected a client for a one-off task — the token is the AI’s key to act as you.

The short version

Connecting your AI to your agency stack with MCP is three real steps: generate a token, register sSystm as an MCP server in your client, and ask it something grounded in your data. From there your own AI — Claude, Cursor, or whatever you standardise on — reads across 29 resources and acts through 29 tools, with every write held as pending until a human approves it and every record living on your own Cloudflare account. It is the difference between an AI that talks about your agency and one that actually helps run it. See the full MCP surface to explore everything your AI can reach.