What can the AI Chat, skills, and MCP access in CMS do respectively?

What can the AI Chat, AI Skills, and MCP integration in CMS do respectively? One-sentence division: AI Chat is responsible for 'dialoguing and acting in the background', AI Skills (Skills) is responsible for 'writing reusable procedure manuals', MCP Server is responsible for 'opening backend capabilities to external AI clients'.Three are not three independent products, but three entrances of the same set of tools; a common consequence of misconfiguration is treating an entrance as a capability, for example, thinking that by integrating MCP, SEO analysis will be done automatically, in fact, it still requires skills and permissions two levels.

What each of the three layers is responsible for

AI Chat: The toolset behind the dialogue entry

Built-in AI Chat intelligent dialogue with a set of AI tools covering content, SEO, operation and maintenance, business and other fields, which can be autonomously scheduled and called by the intelligent body. The difference in actual use lies in whether there is actually a hands-on approach: the entry value of answering questions is limited, and only by directly falling into actions such as creating drafts, changing categories, and checking statistics can it truly save the time of clicking on the back-end.

Tasks that are suitable for priority verification are three types of high-frequency tasks: bulk creation and status modification, content planning by category, and checking site health and troubleshooting clues. These tasks require crossing multiple pages to be manually done in the background, and it is most intuitive to link them with a dialogue entry.

Skills (Skills): Write the process into a reusable manual.

The AI skill system provides scalable skills covering content planning, SEO analysis, batch operations, site health checks, troubleshooting, template development, and API development. Its value does not lie in being able to talk, but in solidifying the method of getting it right in one go: who does what, in what order, check what points, and how to retreat on failure.

There are two constraints when writing skills. First, it should be clear in the skill text which ability is being called, not a specific interface path, as interfaces change while abilities are relatively stable. Second, the same skill should work both locally and in online environments to avoid repeatedly using a writing style that only works on one machine.

MCP Server: Intent Directory and External Client Access

The tool interface of the built-in MCP Server is based on the intent directory for unified convergence, supporting Bearer Token authentication and round-level operation approval, and can be accessed by external AI clients such as Claude, Cursor, etc. This means that the backend capabilities can be called within their familiar clients without the need to replicate content between multiple systems.

The purpose of this layer of intent directory is worth mentioning separately: it converges 'what can be called' from scattered interface lists into intent classification by business domain, and each intent is then matched to a specific endpoint. The benefit of this approach is that permissions and exposure ranges can be set by domain, and when tightening, it is enough to change one configuration without having to process each interface individually.

The approval of write operations is organized by rounds: multiple writes in a single dialogue are merged into one confirmation, rather than confirming each change separately. This design is aimed at batch scenarios - confirming item by item would make the approval process itself a burden, while merging confirmations retains the position of humans to supervise at key points.

Permission boundary: Default closed and explicitly enabled

The MCP interface sets the exposure range according to the intent domain, and the high-risk areas for operations such as backup, upgrade, and multi-site are closed by default. You need to explicitly enable them to call. There is a point that is easy to misunderstand: visibility of capability does not equal to callability. Even if the domains configured as read-only appear in the tool list, write requests will still be blocked.

Configure the order as follows: First, only open the read intent process to ensure that the external client can correctly retrieve the data; then, open content writing as needed and confirm on the client side that the approval prompt really appears; keep the high-risk areas closed and only temporarily open them when there is a clear need to perform a whole-site operation, and then withdraw them.

Implementation sequence and common issues

First skills, then integration: write the internal process into skills and verify it once for reusability, and then integrate MCP to allow external clients to call it, so that the method integrated is one that has already been tested and not an idea waiting to be verified.

Frequent question 1: Connected MCP but unable to access a certain ability? First check the current exposure settings of the intent domain, the default closure of high-risk domains is design rather than a defect.

Frequent question 2: Will AI mistakenly delete content? Write operations go through round-by-round approval, and deleting formal documents in the system is moved to the recycle bin, which can be restored; what truly needs to be worried about is batch replacement operations, which should be backed up before execution.

Question three: Do you need both skills and MCP? If you only need to use AI Chat in the background, there is no need to rush to connect external clients; only when there is a need for cross-system orchestration or to repeatedly execute fixed processes through external clients, the value of the last two layers becomes apparent.