What is MCP, and how does your AI use it in sSystm?

MCP (Model Context Protocol) is the open standard sSystm uses to let your own AI read and write your workspace — instead of shipping a built-in chatbot. Your CRM, projects, design system and documents are exposed as 29 tools and 35 resources over one endpoint, so any MCP-compatible AI client (Claude, Cursor, or otherwise) becomes a genuine collaborator in your agency’s actual data, not a bolted-on Q&A box.

The problem with built-in AI chatbots

Most “AI-powered” SaaS products follow the same pattern: a chat bubble in the corner, backed by a generic model with a system prompt, charging a markup on every token. It answers questions about your data but rarely acts on it — and when it does, it’s locked to whatever the vendor decided to build this quarter.

That model has three structural problems:

1. You’re stuck with the vendor’s model choice. If you already trust Claude, or your team standardises on a specific client, a vendor’s bolted-on chatbot doesn’t care — you get theirs, at their price.
2. The AI only does what the vendor shipped. A chatbot is a fixed set of pre-built flows. New capability means waiting for the vendor’s roadmap.
3. It rarely writes anything real. Most built-in assistants are read-only Q&A over your data, because giving a chatbot real write access safely is a hard problem most vendors don’t solve.

What MCP actually is

MCP inverts this: instead of the platform embedding an AI, the platform exposes itself to whatever AI you bring. A client (Claude Desktop, Claude Code, claude.ai, Cursor) connects to one endpoint and gets two kinds of capability:

• Tools — actions the AI can call, like sstm_crm_add_contact or sstm_wireframe_build. Each tool has a typed schema, so the AI knows exactly what arguments it needs.
• Resources — data the AI can read, addressed by URI, like sstm://crm/deals or sstm://project/{id}/context. Resources are how the AI grounds itself in your real data before it acts.

Because it’s an open protocol, the same AI client that works with sSystm also works with every other MCP server it’s configured for — there’s no per-vendor integration to build or maintain.

What sSystm exposes over MCP

sSystm’s MCP surface is 29 tools and 35 resources, covering the whole workspace, not a curated demo slice:

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
Wireframes	sstm_wireframe_build	sstm://wireframe/{id}, sstm://wireframe/recipe
Content & marketing	sstm_content_draft, sstm_campaign_create	sstm://content, sstm://newsletters
Documents & calendar	sstm_calendar_add_event	sstm://documents, sstm://calendar/events

A concrete flow looks like this: ask your AI to “build a pricing card component in our brand”, and it reads sstm://design/tokens and sstm://component/recipe to learn your actual token vocabulary and prop conventions, then calls sstm_component_create — the result lands in your shared component library, on-brand, reviewable by your team. sSystm never generates on the AI’s behalf; it serves the recipe, and your AI is the builder. See the full MCP story for the resource map in detail.

Human-in-control: how writes are gated

Read access over MCP is immediate — an AI can query your pipeline or a project’s context the moment it’s connected. Actions that change state follow a stricter rule inside sSystm’s own agent mode: every write is staged as pending, a human reviews exactly what it wants to do, and nothing executes until approved. Every run — approved or rejected — is recorded in the Agent Log, so the history is auditable by your whole team, not just the person who approved it.

That’s the same principle whether the AI acting is sSystm’s built-in platform agent or your own MCP-connected client: the AI proposes, a human gates. Read more about the mechanics in Security & data model.

Built-in chatbot vs. MCP surface

	Built-in chatbot	sSystm’s MCP surface
Which AI you use	Whatever the vendor chose	Any MCP client you already trust
What it can do	Fixed set of pre-built flows	29 tools, extended as the platform grows
Pricing model	Per-token markup baked into your bill	Bring your own AI subscription
Write access	Usually none, or narrow	Full workspace, human-gated
Data grounding	Vendor’s context window	Real resources — your actual pipeline, tokens, docs

How to connect your AI to sSystm

1. Open the MCP module in your workspace and generate a token.
2. Point your client — Claude Desktop, Claude Code, claude.ai, or Cursor — at the endpoint using that token.
3. Ask it something grounded in your real data: summarise open deals, draft a component in your brand, or list a project’s full context.

Because sSystm has no central database, every read and write your AI makes over MCP lands on the database provisioned on your Cloudflare account — the same BYOC guarantee that applies to your team applies to your AI. Explore the full module catalogue to see everything your AI can reach.