We Manage Our Website With an AI Assistant: Our MCP Experience
We do not manage the site this article is published on through an admin panel. We manage it by talking to an AI assistant.
What sits in between is MCP, the Model Context Protocol: an open standard that lets an AI model connect to your own systems. We wrote our own MCP server for internative.net. The result is that content, SEO, redirects, sitemap and analytics are all handled from one place, in plain language.
This is not a product pitch. It covers what it does, where it does not help, and why we built it rather than bought it.
A concrete case: wrong facts across 22 records
Last week we noticed that three different claims about the company's history were live at the same time. One page said "since 2017", an article said "for 16 years", a third quoted a different project count.
How does the conventional method fix that? Open the admin panel, work through 369 articles one at a time, search, correct. That is person-days of work.
What actually happened: a search across article bodies returned 22 records, each was replaced with the correct wording. Total time about twenty minutes. And because the rule went into the knowledge base, it will not recur.
The difference here is not speed. The difference is that the conventional method would not have happened. Nobody opens 369 articles hunting for an inconsistent number. The error would have stayed on the site.
A second case: pages that could not be reached
A sitemap check surfaced three pages in a "published but unreachable" state. The cause: redirect rules created months earlier during a migration were pointing those pages' own addresses somewhere else. The redirect resolved before the page rendered, so visitors landed on different content.
Worse, the hit counts on those rules showed this was not theoretical. Real visitors were being sent to the wrong page every month, and it had been running for four months.
An admin panel does not surface this. The panel tells you the page is published; the redirect table is a separate screen, and nobody cross-references the two.
What MCP does, mechanically
Technically, MCP gives a model the ability to use tools. On the server side each tool maps to one capability: create a record, update it, publish, search, add a redirect, submit the sitemap.
The model picks the tools itself. Say "change the author on that article" and it works out which tool to call with which parameters.
The important part: this is not a chat interface, it is an API layer. Tools validate input, check permissions and reject bad data. An SEO description over 158 characters is refused. Publishing is a separate permission from writing, so a token can draft without being allowed to go live.
Why we did not buy this
Off-the-shelf CMS platforms exist and some now ship AI add-ons. We wrote our own for three reasons.
A packaged tool does not know our rules. Bilingual content pairing, author assignment logic, the brand colour palette, the structure of our offer pages, the agreed company figures. These are specific to how we work and cannot be explained to a plugin.
We define the tools. When a capability is missing we add it. A bulk update tool did not exist at first; after updating 96 records one at a time we added it, and the same job now takes five calls.
The data is ours. Content, media, analytics connections all sit on our own infrastructure. A third party's pricing change or API restriction does not reach us.
This is the custom software argument we make on this site, applied to ourselves. Every internal tool we run is custom-built.
What it does not do
It has real limits, and they are worth stating.
It does not decide. Which topic to cover and which position to take is a human call. The model brings data and lays out options; the strategy is ours.
It does not publish unchecked. Write and publish are separate permissions. Important content is prepared as a draft, read, then made live.
It does not see everything. It sees whatever the server exposes. Site code, server configuration and third-party services are out of scope.
It does not make weak content good. It can produce text quickly, but knowing what is true and which figure is defensible is still a human job.
Is it worth it for you?
This approach pays off when you have a content estate of hundreds of records and consistency cannot be maintained by hand; when you publish in two or more languages; when you repeat the same operation regularly; or when you need to weigh several systems together, such as content, analytics and search data.
If you run a ten-page corporate site, you do not need this. An admin panel is enough.
If you want to start
Adding an MCP layer over your existing system is a far smaller job than replacing the system. In most cases it sits on top of the API you already have.
If you want to work out which of your processes fit, bring the content operation you repeat most often and we will start there.