A useful website can now begin with a conversation. Describe a booking enquiry page, a calculator or a small dashboard, then try it, spot what is missing and ask for another pass. I like that change. It puts something tangible in front of the person who actually needs it much earlier.
The next questions are just as interesting. Where does the enquiry go? Who can change the prices? What happens when a deployment fails? Can the assistant check the real server before recommending a fix? Those are the questions I am building AceHost around.
MCP is one part of that setup. The more valuable part is connecting it to the site's existing tools, permissions and release process, so the next request improves what is already there.
What MCP adds to the conversation
The Model Context Protocol gives an AI application a common way to discover and use tools and context supplied by another system. A hosting tool might return the current PHP version or deployment status. A publishing tool might create a draft. The model chooses a relevant tool; the service behind it decides whether that request is allowed and carries out the operation.
That can replace a surprising amount of copying between screens. Instead of pasting a screenshot of an error into a chat, I can ask a connected assistant to inspect the relevant site's state. It can work from a named result with a time and a source, then explain what it found. MCP itself does not make that result accurate, grant the right permissions or provide a backup. Those remain responsibilities of the system we connect.
There are four separate jobs here: the model reasons about the request, MCP carries the tool exchange, the controller checks and routes it, and the hosting or application service does the work. Keeping those jobs clear makes it possible to change the assistant without rebuilding the website around it.
ChatGPT Sites, Claude Artifacts and the right home for a build
ChatGPT Sites lets you describe, refine and publish a website through ChatGPT or Codex. It is useful when you want to put an interface in front of someone quickly. Saved site versions and visitor data are separate concerns: a request tracker still needs storage and rules about who can see or change each record. Review the published link as the intended visitor, not only through the owner's preview.
Claude Artifacts offers another useful workspace for creating and sharing things such as interactive tools, dashboards and single-page websites. Features and sharing options depend on the artifact and account. A calculator or visual explanation can be valuable exactly where it is; it does not automatically need moving to another host.
For work in a source repository, Codex and Claude Code can connect to MCP servers alongside their development tools. That is a different workflow from sharing a hosted Site or Artifact. Check the actual client's authentication and connection support rather than assuming every GPT or Claude interface accepts the same configuration.
My decision is practical. Keep a hosted tool where it works well if its audience, storage, integrations and ownership fit the job. Consider a separately managed build when you need a particular runtime, release process or operational arrangement. Before moving anything, establish what source and assets are available, which platform services it relies on, and how its data can be transferred. A working preview is not evidence that the same app will run unchanged on another host.
What the AceHost controller wrapper does
AceHost is the control plane I build around our hosting operations. Its MCP endpoint exposes named operations for site inspection and, for authorised scopes, work such as cache purges, Git changes and deployment. The controller wrapper sits between the agent's request and those operations.
It checks the bearer credential, filters the available tools and checks the requested site before dispatching the call. The current key types include read-only access to one site, broader access to one site, reseller access to assigned sites and platform operator access. Reseller site ownership is checked again when tools are called, so the site list is not simply frozen into an old key.
That gives a client asking about their WordPress version a different set of tools from an operator investigating the server. A reseller's connection is limited to the sites in that reseller account. Write operations have confirmation handling, with previews where supported. A confirmation flag is only one part of the workflow: the person reviewing a change still needs to understand the target and effect.
I am extending this towards finer permissions for individual users, site admins and delegated groups of sites, alongside separate AI-provider allowances. Those extensions are development work. The useful foundation already in the code is scoped access through defined operations, which we can configure and test for the particular client rather than handing out a shared operator credential.
Server use: investigate before changing the application
Imagine a site becomes slow after a release. “Optimise my website” is too vague a starting point. I want to know which release is running, whether the request reaches PHP, whether the cache is behaving as expected, and whether the database or server is under pressure.
An operator connection can bring relevant hosting state and bounded diagnostics into the same investigation. The assistant can compare what changed, identify missing evidence and propose the next check. It should not treat a missing metric as a healthy one or assume an application rewrite will solve an exhausted server.
“Inspect the deployment and cache state for this site. Tell me what changed and what you still need to check. Do not restart services or edit files.”
That is a useful first request because I can inspect its answer before authorising a change. Once the cause is established, the next action can be narrow: correct a cache exclusion, roll back a release or fix a query. My guides to diagnosing Linux bottlenecks and making monitoring admit what it does not know explain that investigation in more detail.
WordPress: use the site's existing building blocks
For a site owner, the useful request might be “add a page for this new service” or “make this enquiry form easier to complete”. The assistant needs to know the theme, approved patterns, form plugin and publishing rules before it starts.
If the site already has a form system, I want the new form built there. If a suitable block pattern exists, reuse it. A small request should not leave the owner maintaining a second form plugin or a one-off page builder. Written project instructions help the assistant make that choice; application permissions must still enforce what it can do.
The WordPress MCP Adapter connects eligible WordPress abilities to an MCP client. It does not supply every editing operation merely by being installed. Discover what the actual site exposes and use a dedicated WordPress identity with appropriate capabilities. Hosting access and WordPress editorial access remain separate.
“Create a draft service page using our existing page pattern and form plugin. Preserve the current navigation. Show me the draft and tell me how you checked the form.”
I have already written the hands-on connection steps in Work with WordPress agentically without buying another plugin, so I will not repeat the installation tutorial here. After connection, the important test is the whole journey: edit, preview, submit and verify where the enquiry arrives. A working form includes email delivery, not just a green success message.
Static builds: a smaller runtime, with a proper release process
A brochure site, documentation hub or campaign page may work very well as generated HTML, CSS and a little JavaScript. An assistant can work on the content and templates in Git, run the build and check links and layouts before the files are published. MCP can supply hosting or deployment context where that is useful; the build itself can remain an ordinary, repeatable command.
This public AceMedia Host website is an example of that approach. Its page sources, metadata and generated output live together in a repository. A content change can go through the same checks each time, including its social preview, before it reaches the served site.
The handover from an AI prototype needs a dependency check. Browser code must not contain a private provider key. A contact form needs a real delivery service. Saved records need storage; a browser's local storage is not a shared customer database. If the prototype relies on a platform's sign-in or connector, moving its HTML alone will not move those services.
For a separately hosted build I want a reproducible build command, known runtime dependencies, a preview, browser checks, a release identifier and a recovery route. The details are in Deploys that cannot half-happen and Deployment configuration needs an owner. Keeping those mechanics ordinary makes the site easier for the next developer to maintain.
Access, payment and approval are separate decisions
Three credentials can be involved in one workflow. The MCP key controls access to hosting tools. A WordPress credential controls permitted application actions. A model-provider credential, where one is used, pays for and authorises model requests. One should never silently stand in for another.
For an agency managing several clients, that distinction matters. Someone may be allowed to review content for one site without deploying it, or inspect a group of sites without accessing another reseller's customers. A shared AI allowance also needs an agreed payer and limit. Those are explicit requirements for the finer tiered access and provider controls I am developing.
Good agent instructions describe how work should be done. Server-side checks decide whether it may be done. A page, log entry or document returned by a tool cannot be allowed to grant itself more authority. For consequential changes, the review should identify the site, the exact action and the recovery plan, then the result should be checked afterwards.
A useful first workflow is small enough to prove
- Choose one outcome. A read-only hosting report, a WordPress draft or a static page update is easier to verify than “manage everything”.
- Agree the access. Name the site, user, tools, environment and person who approves publication.
- Use what already exists. Keep the theme, form system and build process unless changing them is part of the brief.
- Check the visitor's result. Open the page on a phone-sized screen, try the relevant interaction and verify saved or delivered data.
- Keep the route back. Record the change, retain the right revision or backup and know who responds if it fails.
That is where I see the long-term value of MCP: an assistant working with the real systems behind a site, with enough context to be useful and clear limits on what it can change. The person asking for a new page gets a quicker route to a checked result. The person maintaining the service gets a change they can understand and support.
If you have already made something in ChatGPT or Claude, bring it along. We can look at what it needs, whether it should stay where it is, and what a maintained version would involve. Our custom hosting, WordPress hosting and cloud operations services cover different parts of that work.