Tutorials

How to Connect Claude Code to Your Website via MCP — Safely (2026 Tutorial)

Connecting Claude Code to your website via MCP means registering your CMS's MCP server in Claude Code's configuration with a scoped access token — after which Claude can read your site's pages, structure, and existing copy, and draft new content directly in the CMS, while publishing remains a human decision. No raw FTP access, no database credentials, no copy-pasting HTML between windows, and a token you can revoke in one click. This tutorial covers what actually happens under the hood, the exact setup with VibeMS's built-in MCP connector, the permission model to demand from any CMS, a library of twelve production-tested prompts, the multi-site agency workflow, and the troubleshooting table for when something sulks.

Key takeaways

  • MCP (Model Context Protocol) is the open standard through which AI assistants connect to external systems: the CMS exposes defined tools (actions) and resources (readable data); the AI never touches files or databases directly.
  • Setup is three steps: generate a scoped token in the CMS → register the server in Claude Code → verify with read-only prompts. Ten minutes, once per site.
  • The non-negotiable permission model: read + draft yes, publish never. If a CMS's AI integration can push straight to production, don't connect it.
  • Connected, Claude works in context: it reads your existing pages, matches tone and section structure, and writes into the CMS as reviewable drafts — the copy-paste era ends here.
  • One token per tool per site, treated like a password: individually revocable, audit-logged, rotated on doubt.
  • The same protocol serves Codex and Cursor — MCP is vendor-neutral, which is precisely its point.

Why connect Claude to the CMS at all?

Without a connection, the AI content workflow is a degrading copy-paste loop: generate text in one window, paste into the CMS, fix formatting, lose the structure, repeat per section — and the AI never knows what the rest of the site says. With an MCP connection, Claude Code sees the website the way the CMS sees it: pages, sections, components, statuses, existing copy. "Draft a services page matching the homepage's tone, using our existing section types" becomes one prompt whose result appears in the CMS as a draft, correctly structured, awaiting your eyes.

If MCP itself is fuzzy, read what MCP is and why it exists first — the two-line version: it's the USB-C port for AI, a standard plug through which assistants use real systems via defined, limited capabilities instead of raw access. Under the hood, an MCP server exposes primitives — chiefly tools (callable actions like create_draft) and resources (readable data like pages/) — and the client (Claude Code) discovers and uses exactly those, nothing more. That "nothing more" is the entire security story.

The permission model that makes this safe

Decide capabilities before the first token. The professional baseline:

CapabilityGrant?Why
Read pages, sections & structureContext is what makes drafts good
Read existing copy & metadataTone-matching, SEO passes
Create & edit draftsThe productive part
Upload mediaOptionalConvenient; review before publish
Publish to the live site✗ neverHuman judgment is the release gate
Change settings, users, structure✗ neverNot a content task
Raw file/DB access✗ neverThat's what MCP replaces

VibeMS enforces this structurally: its MCP connector issues private, per-integration tokens with explicit permission checkboxes, every AI write lands as a draft, publishing requires a human click in the CMS, and a full audit log records each AI action with timestamp and token identity. Whatever CMS you use, insist on those four properties — scoped tokens, draft-only writes, human publish, audit trail. They're the difference between an AI workflow and an incident report; the broader threat model (prompt injection included) lives in our vibe coding safety guide.

Setup: Claude Code → VibeMS in three steps

(The pattern is identical for any MCP-capable CMS; only menu names differ.)

Step 1 — Generate the token in the CMS. VibeMS: Settings → MCP Connector → New connection. Name it specifically — "Claude Code — Robin — Site X", because in six months "token3" tells you nothing. Tick permissions (read + draft; media if you want it), create, and copy the server URL and token. The token displays once; store it in your password manager like the credential it is.

Step 2 — Register the server in Claude Code. Two equivalent routes. CLI: run claude mcp add, give the connection a name, paste the server URL and token when prompted (consult the current Claude Code docs for the exact flags of your version — the command surface evolves). Or config file: add an entry to your MCP configuration JSON with the server's URL and an authorization header carrying the token, matching the remote-server schema in the docs. Either way: restart the Claude Code session — MCP servers are discovered at startup, and "it's configured but invisible" is almost always a missing restart.

Step 3 — Verify read-only before anything writes. First prompt: "List the pages of the connected site with their publish status." You should see the real page tree — proof of connection and scope. Second: "Read the homepage and summarize its tone of voice in three bullets." If both work, you're live: Claude has context, you never surrendered hosting credentials, and the CMS can revoke this exact token at any moment without touching the site.

Twelve prompts that make the connection earn its keep

The connection's value is context; these use it deliberately.

Content creation

  1. "Read the homepage and About page. Draft a new 'Team' page in the same tone, reusing the site's existing section types. Draft only."
  2. "Draft a 900-word blog post on [topic] following the structure of the two existing posts — including a Key Takeaways block and an FAQ section. Draft only."
  3. "Create a draft landing page for the spring campaign: hero, three benefit sections, testimonial, CTA — copy consistent with our services page."

SEO passes

  1. "Read all published pages. Propose a meta title (≤60 chars) and meta description (≤155 chars) for each, as a table. Change nothing yet."
  2. "List every page missing an FAQ section, and for the three most important, propose five questions each based on the page's content."
  3. "Audit internal linking: which published pages link to [URL], and where would contextual links to it fit naturally? Suggestions only."

Maintenance & variants

  1. "Draft an alternative hero headline + subline for the holiday season as a draft variant of the homepage — don't touch the live version."
  2. "Check all pages for references to the old phone number [X] and prepare drafts replacing it with [Y]. List every change for my review."
  3. "Read the services page and draft a shortened version at 60% length, keeping all section types."

Analysis (read-only, zero risk)

  1. "Which published pages have the thinnest content (under ~200 words)? Rank them."
  2. "Summarize what this site says about [topic] across all pages — I'm checking consistency."
  3. "Compare the tone of the blog posts to the homepage. Where does it drift?"

Then the human half: open the CMS, review the draft on the actual rendered page, edit where your eye disagrees, publish. That deliberate last click is the point of the whole architecture — not a bottleneck, the feature.

The agency workflow: many sites, many tokens, one habit

Scaling this across a client portfolio without chaos: one token per site per tool, named {tool} — {operator} — {site}, so revocation is surgical when a laptop walks or a collaborator leaves. Register client servers in Claude Code with prefixed names (clientA-cms, clientB-cms) and say which one you mean in prompts — "on clientA-cms, list drafts" — because ambiguity plus write tools is how the wrong site gets a weird draft. Where a client's own staff will use AI drafting (the marketing person scenario), issue their token under their name, draft-scoped, and document it in the handoff email. Quarterly hygiene: skim the audit logs, revoke tokens with no activity, rotate anything old. Ten minutes; institutional-grade posture.

Troubleshooting

SymptomLikely cause → fix
Server configured but tools absentSession started before config → restart Claude Code
401 / permission deniedToken mistyped, expired, or under-scoped → regenerate in CMS, re-paste
Claude "can't see" a specific pagePage status/visibility outside token scope → check in CMS
Writes fail, reads workDraft permission not ticked on the token → edit connection
Draft looks unstyled in the terminalJudge drafts in the CMS preview — Claude writes structure, the CMS renders it
Claude edits the wrong siteMultiple servers, ambiguous prompt → name the server explicitly
Sluggish tool callsLarge sites: ask for filtered reads ("list drafts only") instead of full dumps

Codex and Cursor: same protocol, same posture

MCP is deliberately vendor-neutral. Codex and Cursor both speak it: create a separate token in the CMS for each (never share tokens across tools — revocability dies), add the server in the tool's MCP settings per its current docs, and run the same read-only verification before granting drafts. The permission model, prompt library, and audit habit above transfer one-to-one. That neutrality is strategic: your content workflow attaches to a protocol, not to a vendor's roadmap.

FAQ

Can Claude Code edit my live website?

Not in a correctly scoped setup. Through MCP, Claude holds only the capabilities the CMS granted — in a draft-first system like VibeMS that's reading content and creating drafts. Publishing to the live site always requires a human click in the CMS, and the token can be revoked instantly.

Do I need to run my own MCP server?

No. MCP-capable CMSs ship the server as part of the product — VibeMS includes its connector out of the box. You generate a token, register the connection in Claude Code, done. There's nothing separate to host, deploy, or patch.

How do I add an MCP server to Claude Code?

Either via the CLI (claude mcp add, then paste the server URL and token when prompted) or by adding the server entry to your MCP configuration file — then restart the session so the tools are discovered. Exact flags evolve; the current Claude Code documentation is the authority.

Does this work with Codex or Cursor too?

Yes — MCP is an open, vendor-neutral protocol. Create a separate scoped token per tool in the CMS, register the server in each tool's MCP settings, and verify read-only first. Per-tool tokens keep revocation surgical.

Is it safe to give an AI access to my CMS?

With scoped tokens, draft-only writes, human publishing, and an audit log: yes — and materially safer than the common alternatives (pasting AI output around, or handing tools FTP credentials). The token can be killed at any moment without touching the website.

What exactly can Claude do once connected?

Whatever the token allows and nothing else — typically: read pages, sections, and copy; create and edit drafts; optionally upload media. It cannot publish, change settings, manage users, or touch files and databases, because those capabilities were never exposed.

Can my client's team use this for their own content?

Yes, and it's a genuinely good pattern: issue the client's marketing person their own draft-scoped token under their name. Claude drafts their blog posts in their voice inside the CMS; a human — theirs or yours — reviews on the rendered page and publishes.

What happens if a token leaks?

Revoke it in the CMS — one click, immediate, site untouched — then mint a fresh one. Because tokens are per-integration and drafts-only, the worst-case blast radius of a leaked token is unwanted drafts, which the audit log attributes precisely.

Does the MCP connection slow my website down?

No. The MCP server is an admin-side interface between the CMS and AI tools; it isn't part of the delivery path visitors hit. Your site's performance profile — ours tests at 100 — is unaffected.

MCP vs. a plain REST API — why the fuss?

A REST API gives programmatic access; MCP gives AI-legible, permission-scoped access: the assistant discovers exactly which tools and resources exist, with schemas, and the protocol standardizes it across vendors. Practically: no glue code, no over-broad API keys, and any MCP client works with any MCP server.