First, answer a question: What is an “AI-callable website”?
That is, a website's content and functionality are no longer only for human browsing, but are opened up to AI in the form of standard interfaces: AI can read your articles, case studies, and products, and can also, within the authorized scope, write content, upload images, and even generate full-site pages. The implementation method is MCP (Model Context Protocol)—configure an AI client once, and it can call all of the website's capabilities just like calling local tools.
Start with a small fact.
This article you're reading right now—from writing the first draft and generating the cover image to uploading images, creating the post, setting tags and categories, and publishing it live—was handled entirely by AI through the open interfaces of our digital platform. What people did was: set the direction, refine the wording, and click confirm.
This is not a demo, and it is not a proof of concept. Our official website content—articles, case studies, products, and visual-text notes—is maintained this way every day. AI is a formal part of the content production workflow, not a toy built for show.
What supports all of this is 38 MCP tools.
Why open websites to AI?
Let's start with what's happening in the industry.
The way users get information is changing. In the past, users searched with keywords and picked one result from the list to click into; now more and more users ask AI directly: "Recommend a company that builds corporate websites," "Help me put together this company's case studies." What AI bases its answer on is what it can read.
A website with only a human browsing interface is, in AI's eyes, just a pile of HTML that has to be crawled and guessed at. How much gets crawled and how much is understood correctly is all down to luck. Whereas with a website that exposes standard APIs, AI can retrieve structured data directly: title, body, category, tags, multilingual status — complete fields, no guessing required.
This difference directly determines: when users ask AI, will your content appear in the answer.
In the SEO era, the fight was over search result rankings; in the AI era, the fight is over being cited by AI. To be cited, the prerequisite is that AI can read it, understand it, and read it accurately. Open APIs are the most thorough solution — rather than letting AI guess, let it look it up directly.
What have we opened?
38 tools, divided into four categories by purpose:
Read content (17): Lists and details of articles, products, case studies, and image-text notes; categories, tags, teams, forms, and entity information. AI pulls public content to render pages or answer user questions about the enterprise—this is the category used.
Read structure (4): Content structure, template specifications, website building blueprint, and entity materials. This category is for "AI website building"—AI first reads the system's page contract and customer requirements, then generates the entire site template according to the specifications.
Write content (12): Create and update articles, products, case studies, and image-text notes, and upload media. Writing requires credentials and corresponding permission points; in an anonymous state, these tools are neither visible nor available.
System and identity (5): Connection status, language list, identity self-check, login, and map search.
Alongside these is a REST API layer: 26 public endpoints, with Swagger documentation. MCP is for AI clients, while REST is for traditional programs—the same set of content, two ways to call it.
Openness does not mean running naked.
Opening up the content raises security as the very first question. Our approach is three layers of isolation:
Identity layering. Anonymous visitors can only call read-only interfaces and see only content that is already public; writing content requires an employee Key with the corresponding permission points (someone who manages articles cannot touch products); template uploads and blueprint changes require an administrator or system-level Key. Every tool states its identity requirements in its definition, and out-of-scope calls are rejected outright.
Read/write separation. The 25 read-only tools touch no data at all, and the 12 write tools have permissions set one by one. What AI can read and what it can write is defined on the system side, not left to AI's self-discipline.
Media iron rule. All images, videos, and attachments must first be uploaded to the system file library and referenced using the URL returned by the system. Directly referencing temporary links from external sites is prohibited—including temporary addresses returned by AI image generation services. This rule closes off the risks of external links expiring and content being replaced.
In addition, one work discipline was written into the “Six Iron Rules” in the integration document: when information is incomplete, confirm with the user first; do not fill it in on your own. Writing an article or publishing a case study? Draft or publish directly? If it is not clearly stated, stop and ask. This rule was added after we actually ran into problems.
Templates can also be made by AI.
Opening up content is only the first step; going a step further means building websites.
Website templates on the digital platform come with a complete machine contract: each page type has a clear semantic id, a data field list, and placeholder syntax. The AI first calls tools to read the content structure and the site-building blueprint maintained by the client (what each page needs and what the prompts are), then generates a template package according to the spec and uploads it, previews it in a development slot, and switches it to the production environment after confirmation.
A good number of conventions have accumulated in this workflow: how to write a template's multilingual copy so that each language's pages output in a single language, how to mount membership features, and how to output the footer's filing information in compliance with requirements. The rules are written in the schema, and templates uploaded by the AI that do not conform to the spec are rejected outright.
For users, this means the way of communicating about building a site has changed: no more sending files back and forth or pasting screenshots—just converse directly in the AI coding tool, and the AI reads the real content and generates the pages.
What is it actually like to use in practice?
Here are a few scenarios that have actually happened:
Writing case studies.After a client's website goes live, give the domain to the AI. The AI opens the website, analyzes the design approach and section structure, captures interface images of key sections, writes the case study copy, prepares a cover, and publishes it—while a human handles the final review.
Maintaining the official website.The AI regularly checks the site's content, adds categories, attaches tags, and fixes errors and omissions; after a new product goes live, it adds the product page following the same process.
Building templates.According to the client's blueprint requirements, the AI generates, uploads, previews, and revises page by page, with the entire process completed in the conversation.
The common feature of these scenarios is:the AI uses real system data, not its own imagination. The articles cite cases from the library, and the templates are bound to real content contracts. In this system, the AI is a "certified operator," not a "storytelling bystander."
The significance of this step
Looking back, corporate websites have gone through several stages: static business card, dynamic official website, mobile-first, and content middle platform. Now it is the turn of the next stop—the website as a service, invoked by AI.
Not many people are doing this right now. If you search for "MCP websites" and "AI-invokable content," most of what you find is updates from overseas platforms; practical content in the Chinese-speaking world is almost nonexistent. We are making these 38 tools, this integration documentation, and our real-world experience public. On one hand, this is due to our product capabilities—the digital platform was designed this way from the ground up: a single content declaration simultaneously determines REST capabilities and MCP exposure. On the other hand, we also hope to provide peers and clients with a practical record for reference.
For enterprises, the judgment worth remembering is: who your content is written for is changing from "visitors" to "visitors + AI". Website redesigns, content planning, and digital asset development should all treat "whether AI can read, understand, and cite it" as a criterion of the same level as "whether users find it good-looking."
Open up one step earlier, and enter AI's answers one step earlier.