How Claude manages a company's site: Inside the Marcapony MCP server

At Marcapony, you manage a business site, its products, and blog from the panel. For some time now, AI clients like Claude can do the same: open pages, write sections, update products, prepare blog drafts. They do this through Marcapony's MCP (Model Context Protocol) server. In this article, we explain how we set up the server and the decisions we made along the way.

Why MCP?

We have our own assistant Marco inside the panel. But a significant portion of businesses and agencies already use Claude Desktop or Claude Code. Instead of pulling them into our own interface, we wanted to move the platform to the client they use. MCP does exactly that: the client connects once, discovers which tools are available, and calls them as needed.

A thin layer, a thick API

The MCP server is a Cloudflare Worker. It has no own data or business logic. Each tool consists of a single call to the RPC endpoint reserved for MCP in our API. The connection between the two Workers is a service binding, meaning the request never leaves the internal network.

We deliberately maintain this separation. Authentication, authorization, and logging live in the API. The panel, Marco, and MCP share the same rules. When we change a rule in one place, all three surfaces behave correctly. MCP sessions are stored in Durable Objects. Clients can connect via Streamable HTTP or the older SSE.

Authentication and tenant isolation

The client connects with an API key generated from the panel. We do not store keys as plain text. Each is hashed with PBKDF2-SHA-256 using its own salt. The OAuth flow is a thin layer on top of the same key. Clients that require OAuth, like Claude Desktop, use that path; clients that provide the key directly come via the header.

The most important rule is: the key determines which account is being worked on; the tool parameter does not. No tool receives an account ID. The account is derived from the verified key and written into the call context. If a tool ever accepted an account parameter, it would open a door from one tenant to another.

Read operations are free, write operations are logged. Every change is recorded with the source 'mcp' and the key used. Whether a human or an AI client made the change, its origin remains logged.

The main product: tool descriptions

The server currently offers about 100 tools: pages, sections, custom code blocks, navbar and footer, products and variations, blog, media search, offers, SEO audit, and more.

With so many tools, the thing we invested most effort into was not the code but the descriptions. The model learns a tool only from its description. The description is essentially a prompt. A wrong or outdated description misdirects every client using that tool at once. Therefore we scrutinize descriptions as carefully as code: which fields are required, where a value comes from, common mistakes.

Custom code blocks are the extreme example. Claude can write components inside the site using React and Tailwind. Its rules (no imports, first render on the server, texts defined as editable input) are present both in the tool's description and in a separate writing guide tool. The model reads the guide before the first component.

Everything is draft

Edits made via MCP do not go live on the site. Page and section changes are saved as drafts; a human in the panel decides when to publish. The only exception is blog posts: publishing a post is intentionally exposed to MCP. Site-wide changes like navbar and footer take effect immediately upon saving. The tool description states this explicitly, so the model can warn the user in advance.

Safely editing a large component

In the first version, to change a single color in a custom code block, the entire component had to be resent. This was both costly and risky: the model could overwrite a change made from the panel without realizing it.

Now editing is done with 'find and replace' parts. Each part must appear exactly once in the existing source. The model also sends the hash of the version it read. If the section has changed in the meantime, the request is rejected and nothing is written. The parts in a call are either all applied together or none at all.

The model can look at its own work

The biggest drawback of a model that writes code is that it cannot see what it wrote. For this, we added a preview tool. The tool renders the section as the tenant site renders it, with the theme's colors and spacing, and returns it as a PNG. It can be viewed at desktop and mobile widths. When the model sees double spacing, an overflowing title, or a wrong color, it corrects itself.

Two tools for long queues

Defining a separate tool for each operation on the platform would have enlarged the tool list beyond what the client could handle. Therefore frequently used tasks have their own tools. The rest go through two tools: one lists which operations exist, the other calls the selected operation. We deliberately did not expose irreversible operations like delete and cancel on this surface.

Remembering the user

When a user specifies a preference such as 'address me as you always do' or 'do not use emojis in titles', that preference is saved. The same memory is read by Marco inside the panel and by MCP clients. Thus the user does not have to repeat the same thing in two places.

This page was done the same way

The Marcapony section on creafolks.com and this blog's list and post templates were prepared with Claude over this server and reviewed by our team before publication. Next, we plan to turn this experience into a one-click installable Claude plugin. The first scope is custom code blocks.