MCP Servers and Agent-Readiness for Websites

The Model Context Protocol (MCP) is an open-source standard for connecting AI applications such as Claude or ChatGPT to external data, tools and workflows ([MCP](https://modelcontextprotocol.io/docs/getting-started/intro)). For a website, an MCP server lets agents use your product, for example searching inventory or checking an order, instead of just reading pages. It's agent readiness, not an SEO tactic: crawlable pages still drive AI search citations.

Facts are from the Model Context Protocol documentation, accessed 30 Oct 2026 (latest spec version 2026-07-28). Points marked "Our view" are interpretation.

On this page

• What does an MCP server expose?
• How is this different from GEO?
• When does a public MCP server make sense?
• What should you do before building one?
• How do you plan one?
• What security risks matter?
• How do you measure success?
• Which pitfalls should you watch for?
• How do you describe tools well?
• Exercise
• Checklist
• From MentionX data: what agents still rely on
• Worked example: Ledgerline scopes a read-only MCP server
• What should a first server expose?
• How do you keep public data consistent?
• Who needs to be involved?
• How do you document it?
• When should you wait?
• How do you test before launch?
• How do you retire or change a tool?
• How do MCP servers relate to other agent standards?
• What does it cost to run?
• Common questions
• Related
• Sources

Checked on 31 October 2026. "Our view" marks MentionX opinion. Ledgerline is a fictional company used for illustration.

What does an MCP server expose?

MCP servers provide functionality through three building blocks (MCP):

Servers can run locally or remotely. Remote servers are hosted on the internet and many clients support them, such as Claude via custom connectors (MCP). The specification defines standard transports, including Streamable HTTP (MCP).

How is this different from GEO?

Our view:

Discovery is a real difference. Users or developers connect MCP servers to clients; there's an official MCP Registry listing servers (MCP Registry). AI search engines don't crawl MCP servers the way they crawl pages, as far as any provider has published.

When does a public MCP server make sense?

Our view: when agents need to act or need live, structured data:

• SaaS products: let users' assistants create, query or update records.
• Ecommerce: search, availability, prices; checkout flows need care, see agentic commerce.
• Docs-heavy developer products: search docs from coding assistants.
• Data publishers: query datasets with filters.

It makes less sense for brochure sites, where clean HTML, structured data and llms.txt cover what agents need.

What should you do before building one?

Our view: get the basics right first, because they help every agent, including those that never connect to your MCP server. Make sure pricing, specs and docs are public and in the HTML, structured data is valid, and your public API, if you have one, is documented. Many agents browse pages or call documented APIs directly. An MCP server is the next layer, worth it once users actually ask assistants to do things with your product. A simple signal is support tickets or community posts asking "can I do this from Claude or ChatGPT?"

How do you plan one?

1. List the top three tasks users ask assistants to do with your product.
2. Map each to a tool with clear inputs and outputs. Keep tool names and descriptions plain; models choose tools from them.
3. Decide what's read-only. Start with read tools; add writes only with user authorization.
4. Choose hosting: remote server over Streamable HTTP for public use.
5. Add authorization for any user-specific data, following the spec's authorization section (MCP).
6. Test with real clients such as Claude or ChatGPT developer tooling, and the MCP Inspector.
7. List it in the MCP Registry and your developer docs.

What security risks matter?

MCP's security best practices cover attacks including the confused deputy problem, token passthrough, server-side request forgery and session hijacking (MCP). Our view: the basics for a website team:

• Never pass user tokens through to downstream APIs; validate tokens issued for your server.
• Scope tools narrowly. A search_orders tool shouldn't be able to delete orders.
• Require explicit user confirmation for writes and purchases.
• Rate-limit and log every tool call.
• Treat any text returned from tools as untrusted by the client; don't embed instructions in data.

How do you measure success?

Our view: track tool calls per day, success and error rate per tool, tasks completed (such as orders checked), and which clients connect. Compare support tickets for tasks the server handles. Expect small numbers at first; adoption depends on users adding the server.

Which pitfalls should you watch for?

• Exposing your whole API as hundreds of tools; models choose poorly from long lists.
• Vague tool descriptions.
• No authorization on user data.
• Treating MCP as a replacement for crawlable pages.
• Shipping without monitoring.

How do you describe tools well?

Our view: write each tool description as you would for a new colleague: what it does, when to use it, what each parameter means, and what it returns. Include units and formats ("price in EUR, including VAT"). Return compact, structured results, not full HTML. Good descriptions reduce wrong tool choices more than any other change.

Exercise

Write a one-page spec for an MCP server for your product: three read-only tools, their inputs and outputs, authorization needs and the metrics you'd track. Review it against the security list above.

Checklist

• Top tasks identified
• Read-only tools first
• Authorization for user data
• Narrow scopes and confirmations for writes
• Logging and rate limits
• Listed in registry and docs

From MentionX data: what agents still rely on

Method. Read-only aggregate queries over MentionX scans from 22 August to 29 October 2026 (UTC): 2,217 engine runs (2,154 completed) across 18 anonymised projects and six engines.

Most AI answers are still built from public web pages. In our sample, cited URLs spread across these page types:

Engines vary a lot in whether they link to sources at all:

Our view: an MCP server serves agents that act, not engines that answer. Docs and pricing pages already appear among cited URLs, so keep those pages accurate first. An MCP server is a second step for teams whose buyers increasingly use agents to do tasks.

Limits. A convenience sample of mostly B2B software projects, run through engine APIs, which can behave differently from the consumer apps. Perplexity, Copilot and DeepSeek figures come from a single day (26 October 2026), so treat them as a snapshot, not a trend.

Worked example: Ledgerline scopes a read-only MCP server

Ledgerline is a fictional accounts-payable tool. Figures are illustrative.

Ledgerline's customers ask AI assistants to check invoice status and approval queues. The team considers an MCP server that exposes two tools: look up an invoice's status and list pending approvals for the signed-in user.

They decide both tools need user authentication, because they touch customer data. They also plan one public, read-only tool that returns current plan names and list prices from the pricing page. Before building, they confirm their docs and pricing pages are accurate, because agents and engines will still read those. The security review limits each tool to the smallest scope, adds rate limits and logs all calls. Success is measured by tool calls, error rates and support tickets, not by AI visibility.

What should a first server expose?

Start small. Pick one or two tasks agents are already trying to do for your customers, such as checking availability, looking up a status or retrieving current prices. Expose them as narrow tools with clear inputs and outputs. Avoid exposing broad search or write actions in the first version. A small, reliable server is easier to secure and easier for agents to use correctly.

How do you keep public data consistent?

If your server returns prices, plan names or feature lists, they must match your website. Pull them from the same source of truth, not a separate copy. Inconsistent answers between the site and the server confuse agents and buyers, and they make support harder. Add a check that compares server outputs with the live pages after each release.

Who needs to be involved?

Product, engineering and security own the server. Marketing should be involved because tool names, descriptions and public outputs shape how agents present your product. Legal should review terms of use and data handling. Support should know the server exists, because customers will ask about it.

How do you document it?

Publish a short page explaining what the server does, which tools it exposes, how to authenticate and what limits apply. Keep the page in your docs, with a changelog. Developers and agent builders look for that page first, and engines may cite it when users ask whether your product works with AI agents.

When should you wait?

If your public pages are out of date, fix them first. If your product has no clear task an agent would perform, a server adds cost without benefit. If you can't commit to maintaining it, don't launch it; an unreliable server does more harm than none. Our view: most companies should start by making their docs and pricing pages agent-friendly, and add an MCP server once there's clear demand.

How do you test before launch?

Connect the server to a few MCP clients and ask realistic questions. Check that agents pick the right tool, pass sensible inputs and handle errors. Try unexpected inputs, missing permissions and very large requests. Fix confusing descriptions before launch, because they're the main reason agents misuse tools.

How do you retire or change a tool?

Version your tools and announce changes in the changelog. Keep old versions working for a set period so agent builders can update. Remove tools that nobody calls; each one adds maintenance and security work.

How do MCP servers relate to other agent standards?

MCP is one of several ways agents can interact with a business. Others include public APIs, structured product feeds and checkout protocols. Many companies will use more than one. Choose based on what agents need to do: read data, perform account actions or complete purchases. The underlying rule is the same in every case: the data agents receive must match what people see on your site, and every action must be secure and logged.

Keep a short internal note explaining which standard you use for which job, so product and marketing teams don't duplicate work or publish conflicting information.

What does it cost to run?

Beyond the build, plan for hosting, monitoring, security reviews, documentation updates and support. Each new tool adds to that load. Estimate the ongoing effort before you start, and agree who pays for it. A server that launches well and then decays is worse for your reputation than waiting until you can support it properly.

Common questions

Does an MCP server improve AI visibility? Not directly. Engines still build answers from public pages.

Do I need authentication? For anything involving user or account data, yes.

Can marketing build one alone? No. It needs engineering and security ownership.

Related

• Agentic commerce: preparing your site for AI agents
• Markdown versions of pages for LLMs

Sources

• Model Context Protocol, What is MCP; Server concepts; Remote servers; Specification; Security best practices; MCP Registry

All accessed 30 Oct 2026.