MPP goes MCP: we built our own Model Context Protocol servers

Today we are launching three Model Context Protocol servers inside the MPP Portal. Connect them to Claude and it can work in our systems directly: our CRM, the client websites we host, and the WordPress installs we manage.

This is the piece that ties the summer's work together, so it is worth explaining what MCP is, why it matters commercially, and what we actually built.

The problem with AI in a marketing business

Every agency has been experimenting with AI for two years, and almost all of that experimentation has the same shape: a person copies context into a chat window, gets output, and copies it back into the system where the work lives.

That loop is useful, and we would not give it up, but it has a ceiling. The assistant has no access to your actual data, so you spend your time being a courier. It cannot see that the client's site is mid-migration, that the contact went quiet three weeks ago, or that the page it is rewriting has a form embedded in it. And nothing it produces lands anywhere; it produces text, and a human performs the change.

Model Context Protocol is the open standard that removes the courier. It is a common way for an AI assistant to discover and call tools on a server you control. Instead of pasting your CRM data into a chat, you connect the CRM, and the assistant queries it, with your permissions, as you.

What we built

Three servers, each hardened for a system we depend on.

MPP HighLevel. Nineteen tools across the CRM: search contacts, read and write notes and tasks, list pipelines, search and move opportunities, read conversations, send an SMS or email, manage calendars and appointments, and enroll contacts in workflows. "Which opportunities have not moved in thirty days, and what did we last say to each of them?" is now a question you ask rather than a report you build.

MPP Netlify Sites. Eleven tools over the client websites we host: list every connected site, inspect deploys, read and search the repository, make an edit, and publish. Crucially, edits follow the same safety model our CMS uses: writes land on a staging branch that builds to a preview URL, and the live site only changes when someone explicitly says to push it live.

MPP WordPress Connector. Thirty tools for the WordPress sites we manage. Posts, pages, media, comments, and support tickets over the REST API. Plus, on sites running our companion plugin, real editing: theme and plugin files with automatic backups and a PHP syntax check before anything is written, plugin activation, settings, and cache flushing.

That last one deserves a note. Core WordPress REST can move content around but has no concept of editing a template. Our plugin adds that, with the guard rails on the site where they belong: writes require administrator capability, file paths are confined to wp-content with an extension allowlist, PHP is parsed before it is saved so a bad edit is refused rather than published, and every overwrite is backed up.

The part that took the longest

Not the tools. The authorization.

An AI assistant with credentials to your CRM and your clients' websites is a serious object. Getting that wrong is not an embarrassing bug; it is an incident involving other people's businesses.

So the servers do not hold a shared key that anyone who connects inherits. Connecting one sends you through an OAuth flow that signs you in with your normal portal account and issues a token bound to you. Claude then acts as you. It can never do more than your own account allows. Read access is open to the team. Write access is limited to cleared addresses. Anything a client would see is described first and executed only on an explicit yes.

We also built the same thing into the portal itself: a prompt box on the dashboard that runs against the identical toolset. Same code, same permissions, whether you prompt from Claude or from our own interface. Two front doors, one set of rules.

An assistant that can act inside your systems is only as safe as the identity model behind it. That is the engineering, not the tool list.

Why this matters beyond our own convenience

Three reasons we think this is a structural change rather than a productivity tweak.

The context problem inverts. For two years the constraint was that models did not know your business. Connecting real systems removes it. The advantage shifts to whoever has the cleanest, most connected data, which is exactly why we spent the summer consolidating eleven tools into one portal. The consolidation was not the point; it was the prerequisite.

The work moves from producing to reviewing. Our people increasingly describe an outcome and check a diff, rather than performing the change. That is a real change in what a marketing operator does all day, and it favors judgment over throughput.

It is a standard, not a platform. MCP is open. The servers we built work with any client that speaks the protocol. We are not betting the company on one vendor's roadmap, which is a lesson this industry has learned repeatedly and expensively.

What we are watching for

We are deliberately cautious about two things.

Blast radius. Every write tool is marked, gated, and logged with the email of the person who triggered it. Publishing to a live site requires an explicit instruction. We would rather the assistant be occasionally annoying than occasionally catastrophic.

Over-delegation. An assistant that can do the work is not an assistant that should decide what work to do. The number a person owns is still owned by that person. The tools remove the typing, not the accountability.

Where this goes

We will keep publishing what we learn, including the failures. The near-term work is broadening the WordPress plugin's capabilities and making site connection self-service, so a new client site becomes available to the whole system in a couple of clicks.

If you want a marketing partner operating at this level of engineering seriousness, and paid on results rather than hours, apply for partnership. If you would rather start smaller, run your site through the free grader and see what a machine currently makes of it.