Add AI discovery routes to a custom PHP database app safely

Adding AI discovery routes to a PHP application is not just a matter of writing an llms.txt file. The app also needs to serve useful content in a format agents can read, and any live MCP endpoint must expose only deliberate, safe operations. The routing change should leave existing pages and APIs alone.

BuiltToWinWeb’s AI Indexing Pack is described as a downloadable set of files and endpoints that includes an MCP server, Markdown for agents, llms.txt and agent discovery files. The available product information does not establish compatibility with every custom PHP application. Before installing it, confirm that its requirements fit your app’s framework, routing and hosting setup. The pattern below is a general integration plan, not a claim about the pack’s installation process.

Start with a content boundary

Choose the content agents should be able to find before you add a route. For a public catalog or directory, that might mean published entries with a name, short description, canonical URL and last-updated date. Leave out customer records, unpublished drafts, internal notes, account identifiers and fields that are public only after login.

Build a narrow query for that approved content. Do not let a request supply a table name, SQL fragment or unrestricted search expression. Use prepared statements, apply a sensible result limit, and return only the fields the route needs. If the application already has a public-content service or repository, use it rather than duplicating database rules in a new endpoint.

Reserve routes before the catch-all

Many PHP applications send otherwise-unmatched requests to a front controller. Register discovery paths before that fallback, or an existing rewrite rule may treat them as page slugs and return the wrong response. Keep the route handlers small and pass data to a shared content layer.

• /llms.txt: return a plain-text map of the public sections and useful URLs.
• /content/example-slug.md: resolve a public record and render approved fields as Markdown.
• /mcp: handle the MCP transport and a fixed set of read-only tools, if the app needs live, structured access.

Use exact route matching where possible. Preserve the app’s existing 404 behavior for unknown paths, and test query strings, trailing slashes and URL encoding. A route that accidentally swallows an existing API prefix can be worse than having no agent route at all.

Make Markdown a controlled view

A Markdown route should fetch one published record by a stable public identifier, then render a predictable document: title, summary, canonical URL and the approved body fields. Escape or sanitize database content according to the renderer and output format. Return a not-found response for missing or non-public records; do not reveal whether a private record exists.

Keep browser and agent representations consistent. If a page changes its public title or status, its Markdown view should reflect that change rather than becoming a stale second copy. Set an appropriate content type and consider caching only when the update rules make that safe.

Keep MCP tools narrower than the database

An MCP server is not a reason to expose a general-purpose database query tool. Define a small set of read-only operations, such as retrieving one public listing or searching approved listings by a limited set of filters. Validate every argument, cap result counts, and return a documented shape. Never pass agent-supplied text directly into SQL.

Decide whether the endpoint is public or requires authentication. If it is reachable without login, restrict it to content that is already intended for public access, and add operational controls appropriate to the app, such as request limits and monitoring. Do not put credentials or private configuration in discovery files. An MCP endpoint that can change records needs a separate authorization and review design; it should not be smuggled into a read-only publishing task.

Test the integration as a routing change

Check the three new paths directly and verify their status codes, content types and output. Then test representative existing page URLs, API routes, login flows and not-found pages. Confirm that private records remain absent from both Markdown and MCP responses, including when a caller changes an identifier or filter. Repeat the checks after deployment and after changes to routing or database permissions.

For background on choosing between static discovery and live data, see how data change frequency affects the llms.txt-versus-MCP decision. The practical split is straightforward: use files to point agents toward stable public material; add a live endpoint only when current structured data justifies the extra code and operational burden.

The safest PHP implementation is deliberately small. Keep discovery routes outside the catch-all, reuse the app’s public-content rules, and expose an allowlist rather than a database. That gives agents a useful path into public information without turning a routing task into a new data-access layer.