Is the interface document and MCP tool face two types of entry points, which one to connect first when integrating?

Is the interface document and MCP tool face two types of entry points, which one to connect first when integrated? They are two types of entry points, and the dividing line of choice is 'Who is the caller'. The interface document serves your own program: fixed parameters, fixed return structure, and retry on failure; the MCP tool face serves the AI client: the model decides which capability to call at this step, how to fill in the parameters, and then continue to arrange the results. The judgment of which one to connect first is very simple - deterministic scripts go through the interface, and conversational automation goes through MCP.

Who do the two entry points serve?

The public interface on the AnQiCMS side covers high-frequency content capabilities: document lists and details, categories and tags, image upload, comments and replies, friend links, system settings and contact information, all of which can be found in the API documentation, and are the most commonly used parts in daily API calls. For batch content, use the import interface /api/import/archive, which supports querying whether a title already exists, for batch import, suitable for moving an external article library into the site in one go.

This side of MCP is different. The system has an integrated MCP Server, the tool interface is based on the intent directory for unified convergence, supports Bearer Token authentication and round-level operation approval, write operations will be merged and confirmed, and can be accessed by external AI clients such as Claude, Cursor, etc. It solves the problem of 'letting the model safely replace people in operating the system', not just 'letting the program read data.'

First look at who the caller is and then select the protocol

If the task is to 'sync the manuscript directory into the station at midnight every day', what is needed is a predictable, replayable, and auditable call sequence, and the interface should be used. Batch import actions of this kind are particularly suitable: the ability to check for duplicates by title can avoid duplicate entry, and the script can be rerun in case of failure without leaving dirty data.

If the task is 'During the conversation, the operation asks to mark and reply to the messages from last week that contain contact information', the steps themselves are unpredictable, making the cost of the script to enumerate branches higher, and this is when taking MCP is more cost-effective. The same action can also be mixed: the AI side is responsible for judgment and selection, and the final batch writing is still entrusted to the interface to execute, separating the uncertain arrangement and the certain database entry.

The difference between authorization and approval

The security boundary of the interface route is mainly in your own code: token management, request frequency, and parameter verification all need to be handled by yourself. The MCP route moves some boundaries into the system: the tool surface sets the exposure range according to the intent domain, and operations such as backup, upgrade, and multi-site are closed by default at the site level, and need to be explicitly enabled; then add round-level approval, and the model needs to pass the human before it can act.

This difference determines the approach: when connecting an AI client, first run the read-only capability in the default closed state, confirm the quality of arrangement, and then open the domain as needed; when connecting a script, issue tokens according to the minimum capability and isolate high-risk interfaces separately. Both routes share the same set of site permission boundaries, and do not let AI borrow the full permission credentials prepared for scripts for the sake of convenience.

Hybrid usage and precautions

The common combination in practice is: the interface as the data channel, MCP as the operation channel, AI Chat and the accompanying skills as the human-machine interface. The system built-in AI Chat intelligent dialogue, with a set of AI tools covering content, SEO, operations, business and other domains, can be freely arranged and called by AI Agent, this part is the same as the intention convergence result of MCP, there is no need to develop a separate internal command set.

Three points to note: Firstly, do not pass credentials in the prompt, the authentication configuration should remain on the server; secondly, before batch writing, do a duplicate check and dry-run, the ability of the interface to query whether it already exists by title is prepared for this; thirdly, the writing action initiated on the AI side should leave an approval record for easy traceability of who changed what.

How to judge the order of access, you can self-check with a sentence: Should this action be retried or reviewed by a person? For retries, access the interface, for reviews, access MCP.

Common questions

Do you still need to access MCP after accessing the interface?Is there a need for conversational operation? Data read and write do not require MCP; it is more suitable for MCP when the AI client needs to execute background actions directly and requires round-by-round approval.

Can MCP replace the interface document for batch import?Not recommended. The stability of batch tasks comes from fixed parameters and replayability; the import interface supports duplicate checking by title, which is more suitable for script execution. MCP is suitable for judgment and orchestration, not suitable as a high-throughput data channel.

Should the permissions of the two routes be separated?To. Send the token of minimum capability convergence to the script, retain the default closed high-risk areas for the AI client, and enable round-by-round approval, so that the impact is controllable when there is a problem.