Clear agent actions make a public website usable by a model: search, contact, booking and a defined checkout step, instead of hoping the agent can click the right control in a messy layout. A person can recover from a confusing page. An agent often guesses, misses a field and stops, and the enquiry or the sale disappears with no record of which step failed.
Contents
The version you can ship now is ordinary web work. Pages use real HTML, addresses stay stable, and a small documented API returns the same facts the page shows: titles, prices, free times, and the URL where a person finishes. There is no separate site for agents, and a browser proposal will not do this for you.
This is for stores, clinics, hotels and service businesses that already have search, a form, a calendar or a cart. An assistant should take the first steps a customer would take, then hand back a link a person can trust. The assistant itself is a separate build, covered in our AI chatbot and agent development work. This article is about the public site the agent has to use.
Four agent actions worth exposing first
Start with four operations a customer already understands. Each one has a stable URL, a written result and a rule for who confirms it. Leave refunds, custom quotes and open-ended requests off the list until these four are reliable.
Search
Search is a read. /search?q=blue+coat must keep working when it is shared or fetched again tomorrow. The matching API, /api/search, returns the same hits the page shows: title, URL, price and whether the item can be bought or booked. The agent quotes those fields and does not invent a product the response did not include.
Contact
Contact is a message to a person on your side. The fields are the ones on the form: name, email, topic, body. The agent may draft the text with the visitor, and it may not post that draft until the visitor has seen it and agreed. Errors name the field. Success returns a reference, not a vague thanks.
Booking
Booking starts as another read: free slots for a service, with a timezone and an end time. A hold reserves one slot for a short window, and confirming that hold creates the appointment. A retry after a timeout must return the first appointment, not a second one. A slot missing from the availability response is not bookable.
Checkout
Checkout is a defined step, not a tour of the cart. The agent may add a known product and quantity, then read the server’s total and the checkout URL. The person pays on that page. The agent does not type card numbers, change the price, or mark the order paid. For how the store itself is built, see our e-commerce development work. Ship these agent actions before you add a fifth one.
Forms that are real HTML
An agent, a browser without JavaScript and a keyboard user need the same thing: a form with action, method, a label on each field and a submit button. Divs that only react to a click are invisible to anything that does not run your bundle. The HTML form element is the contract, and the API should accept the same field names.
Errors belong next to the fields, and the values the visitor typed should still be there. A confirmation that never changes the URL cannot be shared later. A confirmation URL can. Without real fields and a real action URL, agent actions have nothing stable to call.
- One form, one purpose. Contact is not mixed into newsletter signup on the same submit.
- Required fields are marked in HTML, not only by a coloured border.
- The success and error states have their own addresses or a clear response body.
- The page still posts if the script fails. The script may enhance the form. It is not the form.
Confirmation before agent actions send or charge
Reads can be immediate. Writes wait. Before a message is sent, a slot is confirmed or money moves, the visitor sees the exact payload: recipient, text, cost and what happens next. The agent prepares that preview. The visitor accepts it. A confident model is not acceptance.
| Action | Who confirms it | What the agent must not do |
|---|---|---|
| Search | No one. It is a read. | Invent products, prices or stock that were not in the response. |
| Contact | The visitor, before the message leaves. | Send text the person has not approved, or retry into a second email. |
| Booking | The visitor, then your rules for that slot. | Book a time that was not returned as free, or create a second appointment on retry. |
| Checkout | The visitor, on your payment step. | Enter card data, change the price, or mark an order paid. |
Put this table next to the agent actions in the documentation your team keeps. If a new feature does not fit a row, it does not ship as something an unattended model may call.
Idempotency for messages, bookings and carts
Agents retry. A timeout and a second click look the same from the outside. Idempotency means the retry returns the original result instead of repeating the side effect. The client sends one Idempotency-Key per intended operation. You store that key with the response for a window you choose, often about a day. The same key and body return the first booking. The same key with a different body is a conflict, not a new order.
POST /api/bookings Idempotency-Key: 7c1e0a2b-9f4d-4e1a-8c33-2b6d0e51a9f4 Content-Type: application/json { "slot_id": "2026-10-21T09:00", "name": "Ana", "email": "ana@example.com" }The visitor generates a new key only when they mean a new request. A timeout reuses the key. Idempotency stops a retry of agent actions from creating a second booking or a second email. It does not replace confirmation. It only makes confirmation safe to repeat.
Auth for account actions
Public search and public availability need no login. Rate limits and a narrow response are enough. Contact and booking can stay anonymous when you already accept anonymous leads, with confirmation and idempotency in place. Account-level agent actions run only as that visitor: their orders, their address, their own appointment. The session is one the person opened, or a token they granted for that scope.
- Do not put a staff password or an admin API key in a prompt, a widget or a public document.
- A token that can read one customer’s orders cannot read another’s, and it cannot refund.
- Revoking access is a normal path, not an emergency procedure you invent later.
- Internal tools stay off the public API. They belong on a private server, described below.
What stays with a person
Some work should not become a tool. Paying is outside the agent actions you leave unattended. So is a refund, a complaint, a price exception and any promise your staff must stand behind. If a request needs judgement, return a link to a person with the context filled in.
- Card numbers, one-time passwords and full account passwords never go through the model.
- Legal acceptance, where you require a person to agree, happens on your page.
- Medical, legal or financial advice stays with the professional who is allowed to give it.
- Anything the availability or catalogue API did not offer is a conversation, not a write.
A public site is not a private MCP server
The Model Context Protocol introduction describes how an assistant connects to tools: files, databases, internal APIs. That pattern fits work inside a company, where staff are known and the network is yours. A mistake is still serious, but the caller is not the whole internet.
A public website is the opposite caller. You did not install the agent. You do not see its prompt. Public agent actions stay few because the caller is not your colleague. The data is either public or belongs to the one visitor in front of the screen. Side effects wait for that visitor.
- Audience. A private MCP server serves your team. The site serves customers and their assistants.
- Credentials. Staff identity stays private. The public side uses no key, or a session the visitor created.
- Scope. Internal tools can be wide. Public tools are the four actions, each with a refusal list.
- Failure. A colleague can retry an internal tool. A public write must stay safe when the retry is automatic.
WebMCP is a proposal, not a launch requirement
WebMCP is an early browser proposal for letting a page expose tools to an agent through the browser, instead of each site inventing a private channel. It is worth knowing about. It is not a box to tick before a customer can use the site, and it is not something every public site has to ship now. What you can depend on for visitors today is HTML, URLs and HTTP.
We will not hold a launch on WebMCP, or call a site unfinished because it skips the proposal. If browsers later offer a stable way to register tools, register the ones you already documented. Registering the same agent actions in a browser API can wait until that path is real for your customers.
Until then the practical set is clean HTML, stable URLs, and a small API with confirmation, idempotency and auth where the action touches an account. A person and a script can test that set now. A proposal is not a test.
Mistakes that make agent actions fail
- The only path is a click handler, with no form, no URL and no API.
- Result pages use a session address that expires, so the agent cannot hand over a link.
- The docs list fields the API does not return, and the model fills the gaps.
- One endpoint can search, message, book and pay, so one mistake has the widest effect.
- Writes have no idempotency key, so a timeout becomes two emails or two appointments.
- WebMCP is treated as the project, while the contact form still fails without JavaScript.
Repair the HTML and the URLs before you publish more agent actions. A fifth tool on top of a broken form does not make the site easier to use.
How we work
- Discovery. We list the four paths, who confirms each write, and which data is public.
- Plan. We write the URL map, field names, errors and confirmation copy before building.
- Build. We implement the HTML forms, the small API, idempotency and rate limits so the page and the API agree.
- Test. A person completes each action. A scripted client then calls the same URLs, including a retry.
- Launch. The short doc names the agent actions, the fields and the errors. Monitoring watches writes, not only page views.
- Support. When a page changes, the action changes with it. A redesigned form that silently renames fields is a bug.
Why CodeWiz
- Page and API together. CodeWiz, founded in 2023 by Dragan Plavšić in Banja Luka, builds websites, APIs, e-commerce and SEO so the action matches the page people already use.
- Local and remote. We work with clients in Bosnia and Herzegovina and abroad, on the stack the site already runs.
- Search that is a real URL. Technical SEO and a stable search address are the same job.
- A defined checkout. The visitor pays on your payment step. The model is not allowed to pay.
- A short contract. Actions, fields, confirmation and errors, written so your staff can keep them. No ranking guarantee.
Frequently asked questions
What are agent actions on a website?
They are named operations a public site exposes on purpose: search, contact, booking and checkout. Each has an address, a result shape and a rule for who confirms it. They are not a hope that a model will understand a messy page.
Do we need to implement WebMCP?
No. WebMCP is an early browser proposal. Ship clean HTML, stable URLs and a small documented API. Revisit a browser tool API only when you can test it with your visitors.
Can an agent complete payment?
It can build the cart and open your checkout URL. The visitor pays on that page, through your payment provider. The agent does not collect card numbers and does not set the order to paid.
Is this the same as a private MCP server?
No. A private MCP server connects an assistant to internal tools for people you trust. A public site is called by visitors you do not control, so the list is shorter and every write waits.
Will this improve SEO?
Stable URLs and real HTML are what technical SEO already depends on. The same work helps a person share a result and helps an agent fetch it. We do not promise a search position.
Start with the four paths you already have
Tell us which of search, contact, booking and checkout already exist, and which one fails when the caller is not a careful person. We map the agent actions onto the pages you already have, including confirmation and a documented API. Contact CodeWiz to start, or look through our services.