How to configure authentication and round-level approval when an external AI client accesses the station-side MCP?

When the external AI client accesses the internal MCP, authorization solves the problem of 'who can call in,' and round-level approval solves the problem of 'whether this round of changes should be executed,' and the two cannot be substituted for each other. The recommended configuration order is to first receive the tool face, then configure authorization, and finally set approval: the tool face converges to the required capability domain according to the intention directory, authorization uses Bearer Token to be fixed, and finally let the write operation be unified confirmed at the round level.

Before access, first understand how the tool face converges

AnQiCMS built-in MCP Server, its tool interface does not open each background action separately, but unifies convergence based on the intent directory-a single business intent corresponds to a stable call entry.The significance of this layer's design becomes apparent when connecting to external clients: the capabilities of the client come from the set of tools it can see, you don't have to worry about the prompt words leading the model down an unprepared path, you just need to decide which domains to open at this layer of the intent directory.The AI Chat built-in and the AI toolset follow the same arrangement, external clients do not receive additional privileges after connecting.

Where is authorization configured

MCP access uses Bearer Token authentication, the configuration should be on the server side rather than the client side: the token is generated by the site, distributed to the access party, and can be expired at any time.Three practical requirements are easy to be overlooked in the pilot stage. One of them is that external clients (such as Claude, Cursor, and so on) should not use the same credentials as the in-site AI assistant, otherwise, both ends of the session will lose credibility if there is a leak.The second, credentials should not appear in shared prompts, screenshots, or ticket text. The third, verification should be real verification - confirm a request with no authorization header is rejected, rather than assuming the gateway has already blocked it.

What actions does round-level approval control

The merge confirmation of write operations is the core of this approval: the multiple changes generated by the model in one round will not be automatically saved one by one to the database, but will be aggregated into a round and executed after confirmation by a person. It blocks not malicious calls, but rather the common continuous incorrect operations of the model - batch renaming,连带 adjustment of categories, submitting drafts that should not be moved together. On configuration, pay attention to two points: the granularity of approval is a round rather than a single call, so the more actions packed into a round, the higher the cost of manual confirmation and verification; read-only queries do not need to occupy approval, leaving approval for actions that truly change the data.

The significance of default closing of high-risk areas

When setting the exposure range by intent domain, backup, upgrade, and multi-site operations belong to a category that is turned off by default and need to be explicitly enabled. The explanation to the outside is straightforward: the capability boundary of the external client should be equal to the responsibility range you are willing to automate. Daily content operations do not require full-site operations, so they should be left in the default state; if you do need to turn them on, they should only be temporarily turned on during the clear maintenance window and turned off after use. The order of collecting exposure range and discussing approval details should be reversed, or it will lead to a mismatch of 'strict approval but wide entry point.'

Minimum authority verification after connection

To conclude, use three questions to check if the configuration has been achieved: Can this client only complete content tasks without touching site-level operations? Is its write operation indeed stopped at the round confirmation step? Can the logs it calls be distinguished by the party accessing, and can this authentication be removed separately if there is a problem? If all three questions are 'yes', the connection is considered closed.

Common questions

Question: Does the external client support custom tool descriptions, and do we still need to collect the intent directory? Answer: Yes. Tool descriptions only affect how the model is selected, and do not limit what it can call; what truly sets boundaries is the exposed range set by the server according to the domain.

Can read-only access not be configured without approval?\nYes, but the scope needs to be restricted to read-only capabilities. Approval is prepared for write operations, and the risk point of read-only access is not in the execution confirmation but in the reading scope.

What should be done if the model is continuously damaged after being connected?\nFirstly, stop the changes that have not been executed by relying on round confirmation; for the parts that have been stored, recover according to the recycle bin and backup, with the scope of the two methods being different, the former being document level, and the latter being data and static file level.