Should you build an MCP server yet?
Somebody on your team has asked whether you need an MCP server. This post helps you answer: which businesses should build one now, which should wait, what to build first if you go ahead, what it costs and risks, and the cheaper fixes that usually come first.
What you'd be building
The Model Context Protocol site describes MCP as an open-source standard for connecting AI applications to external systems, and names Claude and ChatGPT among the AI applications that can use it. An MCP server offers three kinds of building blocks: tools (actions the AI can call, such as "search products"), resources (data it can read, such as a policy) and prompts (ready-made instructions).
WebMCP brings a similar idea into the web page. Its draft describes a JavaScript API that lets a web page offer its own functions to AI agents as tools, with plain-language descriptions. It is published by the W3C's Web Machine Learning Community Group as a draft report, and the document itself says it is not a W3C Standard and not on the W3C Standards Track. Treat it as an early proposal.
So the real question isn't "do we need MCP?" in the abstract. It's "should we give AI agents a direct, structured way into our catalog or service, alongside the website, and is now the time?" Our guide to MCP and WebMCP for websites covers how both work in more detail.
MCP server
- A service that runs alongside your site
- Used by AI applications that connect to MCP servers
- Published specification
WebMCP
- Tools registered inside your web pages
- Used by agents working in a browser that supports it
- Draft from a W3C community group, not a standard
Who should build one now
An MCP server makes most sense when agents already struggle to get what they need from your pages, and you have the people to run another service. Signs that you're in that group:
- Your catalog is hard to browse. Thousands of parts with compatibility rules, trade price lists, configurable products. An agent clicking through filters will often give up; a
search_partstool that takes a model number won't. See B2B ordering for AI agents. - You already have an API. A read-only server that wraps calls your site or app already makes is a much smaller project than one built from scratch.
- You're a software company with good docs. Tools that answer "which plan includes single sign-on?" or search your documentation suit MCP well.
- Your basics are already in good shape. Agents can get in, read your pages and find their way around. The direct lane is the next step, not a substitute.
Before building anything, ask your commerce platform whether it already offers an MCP server for the stores it hosts, and what it covers. Switching on what your platform provides is usually cheaper than building your own. Questions to ask your e-commerce platform includes the questions to send.
Who should wait
For many businesses the honest answer is "not yet". Waiting makes sense if:
- AI agents can't reliably use your website today. If bot protection blocks assistants or a cookie banner traps them, they won't get as far as discovering a server.
- Your product data doesn't agree with itself. A tool that returns a different price from your product page makes things worse, faster.
- Nobody can own it. A server is software. It needs monitoring, updates and someone who answers when it breaks.
- Your catalog is small and your pages are clear. An agent can already read a 40-product store well. A server adds little.
- Build now Complex catalog, existing API, developers who can own it, basics in place
- Switch on Your platform already offers an MCP server for your store
- Experiment Mark up one search form for WebMCP and learn
- Wait Basics failing, data inconsistent, or nobody to own it
Fix the cheaper things first
AgentScore gives a sense of proportion. Its check "Agents can use your site through MCP or WebMCP" carries a weight of 1, and a missing interface is only ever a warning, never a fail, because these conventions are young. The checks below carry far more weight and usually take hours or days, not weeks:
| AgentScore check | Weight | Usual effort |
|---|---|---|
| Bot protection lets AI agents through | 4 | Hours, in your bot protection or CDN settings |
| Buttons and links have names | 4 | Days, often a template change |
| Pop-ups and banners can be dismissed by agents | 4 | Days |
| robots.txt lets AI assistants and search agents in | 3 | Hours |
| Product pages give price and stock in a form agents can read | 3 | Days |
| Agents can use your site through MCP or WebMCP | 1 | Weeks |
These fixes help every agent that visits, whether or not it speaks MCP. Five agent readiness fixes you can ship this week walks through them, and reading your AgentScore report shows how to rank the rest.
If you build, start read-only
The safest first server answers questions and changes nothing. A good first set of tools for a store:
- First Search and product details Products, variants, prices and stock
- Then Policies Shipping, returns and warranty terms
- Later Signed-in lookups Order status, with proper authorization
- Last Actions Building a cart and handing it back to the person
Three rules make the difference:
- Return the same facts as your website. Have the tools call the systems your product pages use, not a separate copy. Your product page is now an API explains why consistency matters.
- Write tool descriptions for a stranger. The AI decides which tool to call from its name and description. "Search in-stock products by keyword, size and maximum price, in USD" beats "search".
- Leave payment with the person. A tool that builds a cart and returns a link for the person to check out keeps them in control. Agent payments are a separate, fast-moving area; see agentic commerce protocols and payments for AI agents.
The risks and costs
We can't give you a price, because it depends on your stack. We can tell you where the cost goes:
- Build and hosting. Usually small for a read-only server over an existing API. Larger if the data has to be assembled from several systems first.
- Security and sign-in. MCP's documentation says authorization is optional but strongly recommended when a server handles user-specific data, and it follows OAuth 2.1 conventions. Order lookups and accounts mean doing this properly.
- Untrusted input. The WebMCP draft gives a whole section to security risks, including prompt injection through tool descriptions and tool output. Assume anything an agent sends you could be hostile, as you would for any public API.
- Keeping up. MCP's specification is published in dated versions, and WebMCP is still a draft. Budget time to follow changes.
- Drift. Every new copy of a price or policy is another place for it to go wrong.
Watch out: a server doesn't make your website optional. Many agents will keep using your pages, and every agent hands back to a person who will. Fix the site first, then add the direct lane.
A decision in five questions
Before you commit:
- Does our AgentScore show agents can get in, read and navigate the site today?
- Does our platform already offer an MCP server we can switch on?
- Do our prices, stock and policies come from one source we can expose read-only?
- Who will own the server, its monitoring and its updates?
- Which customer question would a tool answer better than our pages do?
If you can answer all five, start with one read-only tool and measure whether agents use it. If you can't, the first two weeks are better spent on the fixes above. In the Ghost Agent Lab app, AgentScore shows whether an MCP server or WebMCP tools were found, and Ghost Agent tests show whether agents can finish the journey on your pages either way. For a wider view of where agents still fall short, see what AI agents can't do on websites yet.