MCP for Websites: Audits, Product Selection and Business Data for AI Clients

Why a website needs MCP

A crawler normally visits pages and builds its own index. An MCP-connected client works differently: it requests the server capabilities first and then selects a tool or resource. Instead of extracting services from navigation and HTML, it can call list_services and then get_service for one page.

Practical jobs: who benefits from MCP

MCP is not an AI system and does not replace an API. It is a standard way to give an AI client explicitly allowed tools and data. The value comes from good source data and narrowly scoped operations that a client can combine.

Architecture without direct database access

The AI client sees only allowed tool schemas and results. It receives no database credentials, arbitrary SQL or unrestricted internal-service access. A public visitor MCP and an employee-only internal MCP should use separate access boundaries.

Two real ifreework.com scenarios

1. Find relevant material

Question: “What material covers local LLMs and RAG?” The client calls search_content with a language and sections, receives titles, snippets and canonical URLs, and can read a selected result with get_blog_post. Unlike a plain search result, these are defined content objects that can be used in a continued conversation.

2. Prepare and send an enquiry

Question: “Send an enquiry about building an MCP server.” get_contact returns contact options. The client then shows the exact message and reply-to address. Only explicit user approval allows send_message to submit it through the same backend used by the website form.

Product selection, order status and business analytics are potential scenarios for websites that implement those protected tools. They are not capabilities of the public ifreework.com MCP server.

The layers of a production implementation

1. A published-content source

   A dedicated read-only layer reads only public CMS content: pages, services, portfolio items and articles. Drafts, internal fields, passwords, sessions and administration data must never reach MCP.

2. An MCP endpoint

   Streamable HTTP is suitable for a remote website, for example https://example.com/mcp. The endpoint accepts JSON-RPC and handles initialize, tool and resource listing, calls and reads.

3. Narrowly scoped tools

   Every tool needs a clear name, description and JSON Schema. Several domain operations such as list_blog_posts, get_blog_post and search_content are safer than arbitrary SQL or URL access.

4. Resources

   Published pages can also be exposed as MCP resources with a URI, MIME type and textual content. Tools work well for parameterized requests; resources work well for reading a known document.

5. Discovery metadata

   A server card defines the name, version and remote endpoint. AI Catalog or ARD associates it with the website, while an HTTP Link header points to the catalog.

6. The public Registry

   Official Registry publication uses a schema-valid server.json, domain verification through DNS or /.well-known/mcp-registry-auth, and the mcp-publisher CLI.

Designing reliable tools

A tool name should communicate the result without requiring implementation knowledge. Its input schema should be strict: object type, allowed properties, string lengths, numeric ranges and additionalProperties: false. Empty properties must serialize as an object {}, not an array []; a strict SDK may reject the entire tools/list response because of one invalid schema.

• Canonical URLAllows the AI to cite the original page.
• LanguagePrevents Russian and English content from being mixed.
• Stable identifierSupports repeatable reads of a selected document.
• Result boundariesPagination, maximum limits and allowed sections.
• Explicit annotationsRead-only, idempotency and side-effect hints.
• Safe errorsUseful error codes without SQL, stack traces or secrets.

Read-only by default, confirmation for actions

Content websites should begin with read-only access. Do not expose arbitrary CMS edits, command execution, unrestricted database queries or unpublished documents.

If the server performs an action, separate it clearly from reading. On ifreework.com, send_message is the only exception: it sends a message to the site owner and requires the exact text, a reply-to email and confirmed_by_user=true. The server describes it as side-effecting rather than hiding it behind a general “read-only” label.

A confirmation flag is not sufficient on its own. Use least privilege, read-only access where writing is unnecessary, authentication and role separation for private data, confirmation for every mutation, rate limits, request and field size limits, strict validation, an idempotent request ID, duplicate protection, timeouts, audit logging and safe error responses.

What MCP does not solve

MCP does not guarantee that ChatGPT, Claude, a search engine or another client will discover and connect to the server automatically. A user or platform owner still needs to add the endpoint or select the server from a registry.

It does not replace website quality either. HTML remains the source for people and crawlers, a sitemap assists crawling, Schema.org describes entities, llms.txt provides concise navigation, and MCP provides an executable contract. These layers work together.

How ifreework.com implements it

The public endpoint is ifreework.com/mcp. Content tools read published Russian and English pages and return Markdown with canonical URLs. Dedicated operations list services, projects and articles, read a selected page, search the site and return contact details.

Discovery is available through AI Catalog, ARD and the server card. Human-readable instructions are published on the iFreeWork MCP server page, and com.ifreework/content is listed in the official MCP Registry.

The contact form can also be submitted through MCP. The send_message tool uses the same server-side delivery mechanism as the website form: it accepts a name, reply-to email and message, validates the data, limits duplicate submissions and delivers the request to the owner. An AI client may call it only after the user has reviewed and approved the exact text and reply address.

The core principle is simple: the AI does not receive “access to the whole website.” It receives a small set of verifiable contracts over public content. That boundary is what makes MCP useful in production rather than merely an impressive demo.