Imagine Mina, a marketer planning a career change, asking the AI assistant on an online course site: “I only know spreadsheets, I’m free on weekday evenings, and I want to build automated reports within six weeks. Which course fits me? Which August classes still have places?”

That question hides three different kinds of work. Comparing courses and judging which one fits her background only requires reading the public course descriptions. Confirming whether August still has places requires looking up data that changes. Enrolling her and charging her card would mean acting on her behalf, and she hasn’t asked for that at all.

Many sites are now discussing whether to build an API or MCP so AI can “plug in.” The answer depends on which kind of job the AI has to do: read, look up, or act. The responsibilities behind these three entry points differ a lot, and what most sites should fix first is the least glamorous layer: public pages that AI can actually read.

First, be clear about what MCP solves

MCP (Model Context Protocol) is an open standard for connecting AI applications to external data, tools, and workflows. It answers “how to connect.” It doesn’t tell a site “what to open up.”

Cloudflare, which offers MCP development services, says plainly in its own documentation: don’t treat an MCP server as a wrapper around your full API; build tools optimized for specific user goals. A few well-designed tools often work better than many granular ones, and permissions should be narrow. In other words, even a vendor of this technology advises deciding what AI needs to accomplish before deciding which doors to open.

Read, look up, and act are not an upgrade path. Opening a read entry point doesn’t mean you should next open a lookup, and then an action. They correspond to three different responsibilities. When a read entry point goes wrong, AI gives a wrong description. When a lookup goes wrong, AI gives an outdated answer. When an action goes wrong, a wrong enrollment or payment now exists in the world. The deeper the entry point, the more consequences the site has to own.

Read: where most sites’ real gap is

The first answer Mina wants comes from public course descriptions; no database is needed. Whether AI can give a well-reasoned recommendation depends on whether those pages agree with each other. Do course names, prerequisites, learning outcomes, and schedules say the same thing on every page? Do page titles, descriptions, dates, and language versions point to the same content? Does a withdrawn course still show “Now enrolling”?

There are existing tools for this. Google Search Central explains that a sitemap, a file listing a site’s important pages and when they were updated, helps search engines discover pages and language versions, and that rel="canonical" tells search engines which page in a set of duplicates or near-duplicates is the preferred version. Neither is new technology, and neither needs to be built separately for AI.

If course pages contradict each other, adding MCP only lets AI read the contradictions faster. At the read layer, the job is to fix the content first.

Advertisement

Look up: open a window that answers one question

Places, stock, prices, and delivery status change. Letting AI guess these numbers from page layout breaks as soon as the site is redesigned. That’s when a stable, read-only lookup becomes worthwhile.

Keep that window narrow. In Mina’s case, AI only needs the candidate course codes, August classes, weekday evening times, remaining places, when the data was last updated, and a few states: “full,” “not yet synced,” “no such class,” and “temporarily unavailable.” Student lists, payment records, internal notes, and tools for changing capacity are not part of this task.

Those last states matter most. When a lookup fails, AI must be able to say “I can’t confirm this right now” instead of presenting old data as the answer. You can test this by removing the lookup tool on purpose: AI should still recommend courses from public content, but say honestly that it can’t confirm current availability.

Act: prepare approval and cleanup first

Enrolling, refunding, changing settings, and sending notifications all use someone’s permissions and change the state of the outside world. Before opening this kind of entry point, spell out whose account is used, who is affected, what the parameters are, whether it can be undone, whether the other party is notified, and how errors are fixed.

OpenAI’s Agents SDK, a toolkit for building AI agents, is concrete about this in its human-in-the-loop approval docs: pause before a sensitive tool runs, show the person the tool name and arguments, let them approve or reject that specific call, then resume from saved state. The key is “that specific call.” A vague blanket “OK” leaves no way to know later which target and which parameters were approved.

If a process can fail halfway, also record which effects have already happened, whether it’s safe to retry, and who is responsible for cleanup; see When Automation Stops Halfway, Find Out What Already Happened Before Rerunning If any of these is missing, the action entry point isn’t ready to open.

Start from one real task

Instead of holding a meeting on “should we build MCP,” pick one real task, write down what counts as done, and ask: which parts only need reading, which need a lookup, and which need action?

Mina’s task is done once she has the reasons for a recommendation and an August evening class she can join. Remove “act” and her answer loses nothing, which shows the lowest entry point this task needs is read plus a narrow lookup window. Only if she then says “enroll me in this class,” and identity checks, personal data, per-call confirmation, payment, duplicate prevention, and failure recovery all have an owner, is it worth reconsidering an action entry point.

For most sites, the next step usually isn’t building a new interface. It’s picking a few pages AI gets asked about most and checking whether they say the same thing. If your AI also changes code for your team, the same layered thinking applies; see Can a Coding Agent Take This Issue? Only If You Can Describe the First Diff.

AI handoff card

Ask AI which level of entry point a site task needs This prompt asks you to describe one real task, splits it into read, look up, and act, and recommends only the lowest entry point the task needs.

I want to decide whether my website needs to open a new entry point for AI (for example an API or MCP).
The method comes from this article: https://boosterminiclass.com/en/posts/agentic-web-needs-machine-readable-doors/
Its view: split one real task into "read public content," "look up changing data," and "act on someone's behalf," and open only the lowest level the task needs. What most sites should fix first is public pages AI can read.

Ask me 3 questions first:
1. What is one real task users would ask AI to do on my site, and what counts as done?
2. What data does the task need: what is already on public pages, and what changes over time?
3. Does the task use someone's account to enroll, pay, change, or send anything?

Based on my answers, give me:
- The task split into read, look up, and act, with the data or actions each part needs;
- For the read part: inconsistencies on my public pages that may need fixing first;
- For the look-up part: the fields and error states a read-only lookup for this task needs;
- A one-line conclusion: the lowest entry point this task requires;
- If an acting entry point is needed: the approvals, records, and recovery to prepare first, without designing the implementation for me.
Don't assume my site has data or features I haven't mentioned.

The suggestion is only a starting point. Which entry point to open is up to the people responsible for the data and its consequences.

Advertisement

Share

Share this mini class

If this lesson helps untangle a work bottleneck, share it with someone deciding how to use AI.

References