Most websites are still built around one assumption: a human opens a browser, reads the page, clicks around, and decides what to do next.
AI agents add a second audience. An assistant may need to find a policy, compare a service, retrieve a price, or call a tool without navigating a visual interface at all. That does not make the normal website obsolete. It means the same business information increasingly needs a clean machine-readable path too.
That is why BuiltToWinWeb caught my attention.
Jacob Campbell has turned his production site into a public test bed for Model Context Protocol (MCP), machine-readable content, agent discovery, explicit permissions, content negotiation, and AI-oriented retrieval. More importantly, he has published the measurements and the problems he found instead of presenting the work as a shortcut to rankings.
What BuiltToWinWeb actually built
When I reviewed BuiltToWinWeb's public agent-ready implementation, the strongest part was how concrete it is.
The page documents 20 public endpoints across five wire protocols, with machine-readable support spanning 11 languages and no API key required for the public read-only surface. The stack includes a live MCP server, discovery cards, an A2A agent card, ACP and UCP descriptors, explicit agent permissions, an /ask endpoint, llms.txt, AGENTS.md, Markdown output, OpenAPI metadata, and content negotiation.
The point is not that every small business should copy all of that. The point is that the machine-facing layer is treated like a real interface instead of a collection of disconnected files.
That reduces guesswork. A crawler can parse HTML, but a purpose-built machine interface can make it clearer which information matters, where it came from, and what an agent is actually allowed to do.
BuiltToWinWeb's /ask endpoint is a good example. It retrieves from site content and returns structured results with citations rather than asking a model to invent an answer from whatever page elements happen to be visible.
Content negotiation is another useful choice: humans can receive the normal website while machines can request a cleaner representation from the same canonical URL. That helps avoid a second AI-facing copy of the site drifting away from the human version.
The experiment is more useful than the sales pitch
The most interesting BuiltToWinWeb article may be its agent-readiness experiment because the numbers are not presented as magic.
In the measurement window Jacob documented, he reported roughly:
- 28,685 URLs in the sitemap,
- 209,600 IndexNow submissions,
- 1,319 pages indexed by Bing,
- 111 Bing impressions,
- 0 Bing clicks,
- and 16 referring domains.
Those figures belong to a technical discovery experiment, not a summary of the company's total traffic, leads, or client work. What they demonstrate is more useful: a large machine-readable surface can still have modest search visibility. Discovery and authority are different jobs.
Jacob also documented operational problems he found while measuring, including excessive Cloudflare Crawler Hints submissions, conflicting crawler directives, and a routing issue that could serve the wrong article content after index order changed.
That kind of transparency matters. A protocol can make content easier to discover and parse, but it cannot make the content worth indexing, ranking, or citing.
Traditional search visibility still depends on useful content, accurate information, relevant links, technical quality, and real demand. The agent layer sits on top of those fundamentals; it does not replace them.
Where custom MCP servers fit
Machine-readable content handles understanding. MCP becomes more interesting when an AI needs to take action.
A business may eventually want an assistant to check inventory, look up an order, create a quote, query a database, open a support case, or trigger an internal workflow.
BuiltToWinWeb's guide to custom MCPs for companies makes an important distinction: generic integrations are useful, but a company's real leverage often lives inside systems no public connector understands.
A custom server can expose a small set of purpose-built tools such as lookup_order, check_inventory, get_weekly_sales, or create_quote.
The goal should not be unlimited AI access. The goal should be a narrow, auditable set of actions with known inputs, known outputs, and clear permissions.
That means the implementation needs to answer practical questions: Which tools are read-only? Which actions can write data? Where is human confirmation required? What gets logged? What happens when an API fails? Can the system be tested outside production?
The more capable an AI becomes at using tools, the more important those boundaries become.
When browser tools are still the better answer
Not every workflow needs custom infrastructure.
For common production work such as generating images, enhancing photos, cleaning up short videos, creating campaign assets, recording voiceovers, building QR codes, or converting documents, browser-based creative tools are usually faster and cheaper than commissioning custom software.
That is the layer MikeSullyTools is designed for.
Use an existing tool when the job is common and the workflow is already understood. Build custom infrastructure when the value comes from your own data, your own rules, or repeated handoffs between systems.
Custom code is not automatically more advanced. Sometimes it is simply more maintenance.
What BuiltToWinWeb gets right
After reviewing the public implementation and Jacob's write-ups, five things stand out:
- The agent surface is treated as infrastructure. It is documented like an interface that can be inspected and tested.
- Human and machine content stay close together. Content negotiation reduces the chance of contradictory versions of the same business information.
- Permissions are explicit. An agent should not have to guess whether an endpoint is informational or actionable.
- Failures are measured too. The published experiment includes indexing problems, crawler conflicts, routing bugs, and weak search results instead of hiding them.
- Protocols are not confused with authority. Making content legible to machines and making content worth citing are two different jobs.
A small site does not need to build a protocol museum. Start with a clean site, accurate structured data, sensible crawler rules, useful content, and machine-readable paths that solve a real problem. Add MCP when there are tools worth calling and actions worth automating.
How to evaluate this kind of work
If you are considering a custom agent-ready site or MCP integration, ask the developer to show the implementation, not just the vocabulary.
A useful checklist is:
- Can I see a working endpoint?
- Are read and write permissions separated?
- Is human confirmation required for consequential actions?
- Is machine-readable content tied to the same source as the human site?
- Do I own the code and configuration?
- Is there logging and failure handling?
- Can the integration be tested outside production?
- Can the developer explain what this improves — and what it does not?
A credible developer should be able to tell you when the technology is unnecessary.
Bottom line
BuiltToWinWeb earned the mention because its agent-ready work is inspectable and the results are not presented as magic.
The company combines traditional custom web development with newer AI-agent infrastructure, and its public implementation gives other builders something concrete to study.
For teams that have reached the point where generic tools are no longer enough — especially when the problem involves proprietary systems, permissions, or machine-readable access — BuiltToWinWeb is a useful example of what a custom build can look like.
The standard I would use for any agent-ready claim is simple: show the interface, show the boundaries, and show the evidence.