How to publish AI agent tools from your own website: a remote MCP server and in-page WebMCP, what each surface is for, the two failures that cost a day each, and whether a business in Jordan, Saudi Arabia, or the GCC should build this yet.
What is an MCP server for a website, and does my business need one?
Publish agent tools when your site does something a person would otherwise have to click through to get: a search, a lookup, a stock check, a calculation. If your site is mostly pages to read, an MCP server has nothing useful to expose, and the time is better spent making sure the AI crawlers can reach those pages at all. The two surfaces cover different situations: use a remote MCP server to reach assistants working from a chat window, and WebMCP when an agent is driving a browser on your own pages.
- Two surfaces: a remote MCP server any assistant can connect to, and in-page WebMCP for agents already browsing your site.
- MCP is stable and usable today. WebMCP is a W3C draft in a Chrome 149 and Edge 150 origin trial.
- Ijjad publishes both on ijjad.com. The endpoint is at /mcp and you can connect a client to it yourself.
- If robots.txt still blocks the AI crawlers, none of this matters yet.
TL;DR
- • Being found and being used are now two different capabilities. Fixing one does nothing for the other.
- • A remote MCP server reaches assistants that never load your site. WebMCP reaches agents that do.
- • Two failures cost us a day each: WebMCP has no unregisterTool, and it fails silently in production without one response header.
- • Most regional businesses should not build this yet. The section below says who should.
Search “MCP server” this week and almost every result is a list of servers to install: Shopify, Stripe, Slack, HubSpot. That is the consumption side. Very little covers the publishing side, which is the one that matters if what you own is a website rather than an inbox.
So this is written from the other direction. We shipped both agent surfaces on ijjad.com on 27 August 2026. The endpoint is live at www.ijjad.com/mcp, the install config is on our agent tools page, and you can connect a client and poke at it while you read this.
Being found and being used are now two jobs
Retrieval is the job everyone already knows. An assistant answers a question by fetching pages, so robots.txt has to let OAI-SearchBot and Claude-SearchBot through on the path they want, the content has to exist in the server-returned HTML, and the structured data has to describe what a reader can actually see. We have covered that side properly in what generative engine optimization actually is and the bilingual LLM SEO checklist.
Action is the newer job. When a customer asks an assistant “does this store ship to Dammam, and how long does it take”, the assistant has two options. It can fetch your shipping page, parse prose written for humans, and infer an answer that may be a year out of date. Or it can call a function you published that returns the current answer for that city.
Same website. Different capability. Good SEO buys you the first one and none of the second.
What a remote MCP server actually gives a business site
The Model Context Protocol is the standard assistants use to call tools, and its 2026-07-28 revision made publishing one much cheaper than it used to be. Protocol-level sessions are gone. Every request now carries its own version and client information, which means the server does not have to remember anything between calls and an ordinary serverless function is a correct place to run it rather than a compromise.
What you gain is narrow but real: an assistant helping someone choose a supplier can query you directly rather than working from whatever it scraped last month. Ours exposes five tools. One searches every page on the site so an assistant citing us links to a URL that exists. One runs a live technical check on any public site. One turns a project description into a WhatsApp message and a pre-filled enquiry form, and hands both back for a human to send.
That last design choice is the one worth copying. An agent that can submit your contact form will eventually fill your inbox with messages nobody chose to send.
WebMCP is the other half, and it behaves differently
WebMCP is a browser API. A page calls document.modelContext.registerTool() and any agent driving that browser sees a callable function instead of a screen it has to interpret. It is a W3C Web Machine Learning Community Group draft, currently an origin trial in Chrome 149 and Edge 150 according to its own implementation-status page.
Being honest about what that means commercially: browser-agent traffic to a regional business site today is close to zero, and nothing about WebMCP will change your traffic this quarter. We built it anyway, for two reasons that have nothing to do with visitors. It is genuinely cheap when the tool definitions already exist for the server. And the API is early enough that implementing it teaches you things the guides have not written down yet.
The two failures that cost us a day each
Both of these are in the specification. Neither appeared in any implementation guide we read first, and both fail in ways that do not look like the cause.
There is no unregisterTool. Reasonable people go looking for one, because every other registration API has a matching removal. WebMCP scopes a registration to an AbortSignal you pass in, so the tool lives until that signal fires. In a component-based site this is actually the better design once you see it, since the framework already knows when to abort. Until you see it, you write a cleanup function that does nothing and end up with duplicate tools after every navigation.
Registration fails without Origin-Agent-Cluster: ?1. This is the expensive one. The spec requires an origin-keyed agent cluster, and without that response header registerTool rejects with a SecurityError. The trap is the environment split: your development server is very likely origin-keyed already, so everything works locally, you deploy, and the tools silently never register in production. There is no console error a normal user would see and nothing on the page looks broken. Add the header before you write a line of tool code.
| If your site is… | Build this | Why |
|---|---|---|
| Pages to read, no lookups | Neither yet | There is no action to publish. Spend the time on crawler access and server-rendered content. |
| A catalogue, or anything worth searching | Remote MCP server | Assistants can answer stock, spec, and availability questions from live data instead of a stale scrape. |
| A calculator, checker, or configurator | Both | The logic already exists. Exposing it as a tool is a wrapper, and it is the clearest reason for an assistant to reach for you by name. |
| A booking or account flow | MCP server, read-only tools first | Publish lookups now. Keep anything that writes, sends, or charges behind a human confirmation. |
Should a business in Jordan, Saudi Arabia, or the GCC build this yet?
Mostly no, and the reason is specific rather than cautious.
When we run the free checker across regional business sites, the problems that come back are the ordinary ones. robots.txt blocking a crawler on the exact path that matters. A page whose content only exists after JavaScript runs. Structured data describing a product the visible page never mentions. Publishing agent tools on top of a site an assistant cannot retrieve in the first place is building the second floor before the first.
The businesses that should move now are the ones where a customer question has a factual answer sitting in a database: retailers with real catalogues, clinics with appointment availability, logistics companies with coverage by city, anyone running a configurator. For those, the tool is a thin wrapper over logic you already maintain, and it is the difference between an assistant describing you and an assistant using you.
There is also a timing argument that only holds for a while. Almost nothing in this market publishes an agent surface, and being first in a category nobody has entered is a cheaper position than being tenth in a crowded one. That advantage shrinks every quarter.
How to check where your site stands
Start with retrieval, because it is the part that pays today. Ijjad's free AI Visibility Checker takes any public URL and reports which AI crawlers robots.txt allows on that exact path, whether the content is in the server-returned HTML, and what structured data the page carries. Since August 2026 it also reports whether the site publishes an agent tool surface at all, which as far as we can tell no other checker does. That check is informational and does not affect the score, because penalising sites for lacking a draft browser API would be unfair.
If you want to see a working implementation before deciding, connect a client to our endpoint. The tool list, the install config, and the WebMCP code are all on the agent tools page.
Questions we get asked
What is an MCP server for a website?
The Model Context Protocol is the standard AI assistants use to call tools. An MCP server for a website publishes that site's useful actions — search, lookups, checks — as tools an assistant can call directly rather than reading pages and inferring an answer. Most published MCP servers today belong to platforms like Shopify or Stripe. Publishing one for an ordinary business site is still rare, which is most of the reason it is worth doing.
What is the difference between MCP and WebMCP?
An MCP server is remote. An assistant connects to it over HTTP without ever loading your site, so it reaches people who are talking to Claude or ChatGPT rather than browsing. WebMCP is in-page: it hands your tools to an agent that is already on your site through a browser API at document.modelContext, so the agent calls a function instead of clicking your interface. MCP is stable and usable now. WebMCP is a W3C Web Machine Learning Community Group draft running as an origin trial in Chrome 149 and Edge 150.
Do I need an MCP server if my site already has good SEO and llms.txt?
Not necessarily, and probably not yet. Retrieval and action are different capabilities. Good SEO, open robots.txt rules for the AI crawlers, server-rendered content, and accurate structured data are what get your pages read and cited. An MCP server is only useful once your site can do something a person would otherwise have to click through to get: check stock, look up a booking, run a calculation, search a large catalogue. If your site is mostly pages to read, fix retrieval and stop there.
Is it safe to let an AI agent use my website?
It is, if you decide what the tools can do. The risk is not the protocol, it is publishing an action nobody sanctioned. Read-only tools are safe by construction. For anything that writes, sends, or charges, the safer pattern is to have the tool prepare the action and hand it back for a human to confirm. Ijjad's enquiry tool does exactly this: it writes the brief into a WhatsApp message and a pre-filled form and returns both links. It never submits anything.
How do I know whether my site is already reachable by AI agents?
Run any public URL through Ijjad's free AI Visibility Checker. It reports which AI crawlers robots.txt lets through on that exact path, whether the content is in the server-returned HTML, what structured data is present, and — since August 2026 — whether the site publishes an agent tool surface at all. That last check is informational and does not affect the score, because almost no site has one yet.
Where this leaves you
Get retrieved first. Check the crawler access, get the content into the HTML the server returns, and make the structured data honest. That work pays this quarter and it is the foundation for everything else.
Then look at what your site can actually do for someone. If there is a lookup, a search, or a calculation in there, publishing it as a tool is a small piece of work with a long shelf life, and right now you would be one of the few in the region who has done it.
Ijjad builds both surfaces for clients across Jordan, Iraq, Saudi Arabia, and the GCC, along with the crawler and structured-data work that has to come first. If you want to know which of those your site actually needs, run the free check and send us the result.
Source note
Protocol details are taken from the primary specifications and verified against a running implementation: the Model Context Protocol 2026-07-28 revision, the W3C WebMCP draft, and its browser implementation status. The Ijjad implementation described here is first-party and checkable: the endpoint is live at www.ijjad.com/mcp. Both specifications are moving, so re-check version-specific details against the primary source before you build.
