Making a PHP app legible to AI agents
Coding agents invent functions that don't exist because the app can't describe itself. Here are three ways to fix that, from someone who built one of them.
- Choose an instruction file if the app is small and stable, and you want something working today.
- Choose a separate MCP server if you have a good API and don't want to change the app.
- Choose a built-in MCP server if schemas and functions change every release and drift is what's hurting you.
The problem. Ask a coding agent to work on an app and it will sometimes write code against functions that don't exist — plausible names, plausible arguments, wrong. It isn't a bad agent. It's working from training data that's months or years old, and docs that may not match the version installed. Plausible code against a missing API is worse than a broken build, because it passes a quick review.
The fix lives on the app's side. The installed app already knows its schemas, its content, and which functions this version exposes. The question is how to let the agent ask. MCP — the Model Context Protocol, the open standard Claude, ChatGPT, Cursor and others use to talk to outside tools — is the usual answer.
There are three ways to do it, from cheapest to most thorough: an instruction file, a separate MCP server, or one built into the app. The cheapest is sometimes enough.
At a glance
Three worth your time.
| Product | Price | Best for |
|---|---|---|
| 1. Instruction files and pasted docs | Free | Small apps that rarely change, or a first step |
| 2. A separate MCP server | Free to build | Apps with a solid existing API you'd rather not change |
| 3. An MCP server built into the app Ours | Part of the app — Total CMS is $195–$395 one-time | Apps whose schemas, content and functions change release to release |
The options
Each one, with its tradeoffs.
-
Instruction files and pasted docs
Give the agent a written guide: an AGENTS.md or rules file, plus docs in context.
Strengths
- No code to write. A Markdown file in the repo and you're done.
- Works with every agent, including ones without MCP support.
- Good for conventions an API can't express — naming, style, what not to touch.
Tradeoffs
- It's a copy, and copies drift. The file is right until the next release, then quietly wrong.
- No live data. The agent can't see real schemas or content, so it still guesses about them.
- Advice, not enforcement. Nothing stops a bad write.
-
A separate MCP server
An MCP server that runs alongside the app and talks to it through its existing API.
Strengths
- No changes to the app itself. The server wraps the API you already have.
- Ships on its own release cycle, independent of the app.
- Live data. Agents read real schemas and content, not a description of them.
- Permissions come for free. If every call goes through your existing API with a user's key, the agent can never do more than that user could.
Tradeoffs
- Two things to install, update and keep in sync. The server can fall behind the app it describes.
- Only as good as the API underneath. Anything the API doesn't expose, the agent can't see.
- Docs still live elsewhere unless the server is built to serve them per version.
-
An MCP server built into the app
Ours — we make thisThe app serves MCP itself, from the same code that runs the site. Total CMS works this way.
Strengths
- Version-exact by construction. Docs and schemas come from the running install, so an agent on 3.6 reads 3.6.
- One permission system. Writes go through the same validation, events and access groups as a human save.
- Nothing extra to install. Every install has it.
- Instructions travel with the connection: look before acting, check the docs, change only the fields you mean to, never invent IDs.
Tradeoffs
- The most work to build. You're adding a protocol, auth and docs serving to the app itself.
- Moves at the app's pace. MCP improvements ship only when the app does.
- More surface to secure inside the app — OAuth, consent screens, client registration.
- In Total CMS, agent writes, OAuth and API keys need Pro; Standard gets public read access.
How to choose
The longer answer.
Start with the cheapest thing that stops the guessing. If an instruction file stops your agent inventing functions, you're done. Most people find it helps but doesn't hold past the next release, because the file is a copy.
Then ask where the truth lives. If your app already has a solid API, a separate MCP server is a fast win. If what drifts is documentation and schema — functions added, fields renamed, version to version — only serving them from the running code fixes it at the source.
Whichever you build, a few things hold:
- Serve docs from the running code, not a website. Version-matched docs fix more than any prompt.
- Reuse your permission layer. A second permission system for agents is one more thing to keep in sync, and it will be the weaker one.
- Send writes through your normal save path. Whatever a human save triggers — validation, events, hooks — an agent save should too.
- Put behavior instructions in the server. They apply to every client, whatever the user's own prompt says.
- Start read-only. Reading is useful on its own and carries little risk. Add writes once permissions are solid.
- Plain data formats help. Content as JSON or Markdown on disk makes it easy to see exactly what an agent changed.
Try the read side without installing anything. totalcms.co runs on Total CMS, and its MCP endpoint answers questions about the product. In Claude Code: claude mcp add --transport http totalcms https://totalcms.co/mcp. It's read-only: the product docs plus totalcms.co's public content. Watching an agent build needs a local install.
Questions
Common questions.
Is an AGENTS.md file enough?
Sometimes. For a small app that rarely changes, a well-written instructions file stops most of the guessing. Its weakness is that it's a copy, accurate until the next release. If your schemas or functions change often, the agent needs to read them from the app itself.
Can a PHP app be an MCP server?
Yes. MCP has an HTTP transport, so a PHP app can serve it directly, the way Total CMS does, or sit behind a separate MCP server written in any language that calls the app's API.
Is it safe to let an agent write to my app?
It can be, if the agent gets no special path. Route its writes through the same validation and events as a normal save, and govern them with the same permissions human users have. Start read-only and add writes once that permission story is solid.
What is MCP?
The Model Context Protocol is an open standard for connecting AI tools to outside systems. An app exposes tools, resources and prompts over MCP, and any compatible client — Claude, ChatGPT, Cursor and others — can use them without custom integration code.
Why do coding agents invent functions that don't exist?
They work from training data that's months or years old and documentation that may not match the installed version. The result is code with plausible names and arguments aimed at an API that isn't there. Better prompts help a little; letting the agent read the real app fixes it.
Sources
Where these facts come from.
Checked . Software and pricing change, so check each product’s own site for their current details.
- Model Context Protocol — the open specification
- Total CMS documentation — our own
All product names and trademarks belong to their respective owners. Total CMS takes the built-in approach described here. If anything on this page is wrong or out of date, tell us and we will correct it.
Keep comparing
Head to head, or zoom out.
- Hosted vs self-hosted Before you choose between Squarespace and Webflow, or between Kirby and Craft, there is a bigger question underneath: do you want to rent a website platform or own the software that runs it? Here is how to decide, from someone with an obvious stake in the answer.
- The best flat-file CMS in 2026 Five flat-file content management systems worth your time, what each is genuinely good at, and where each one will frustrate you.
- A PHP CMS without a database Running a CMS with no MySQL sounds like a corner-cutting exercise.
- WordPress alternatives for freelancers If you build client sites for a living, the CMS decision is really a decision about the next three years of your evenings.
Put it on your shortlist, then test it.
45 days, every Pro feature, no credit card. Install it next to the others and decide with a real site in front of you.