MCP server application method and system for domestic operating system

Abstract

This application discloses an MCP server application method for domestic operating systems, belonging to the field of intelligent service technology for domestic operating systems. It addresses the problems of complex deployment, poor instruction compatibility, lack of verification mechanisms, and insufficient security adaptation of existing MCP services in domestic operating systems. The method involves constructing and deploying a local MCP server that encapsulates the unique interfaces and general instruction sets corresponding to the domestic operating system, achieving automatic configuration through a preset installation package; managing an instruction system containing "verified instruction sets" and verifiable newly added instructions; and adaptively switching execution modes based on user permission verification and network status detection to complete tasks. This invention is adaptable to various scenarios such as government affairs and scientific research, and can improve the intelligence and security of domestic operating systems.

Description

Technical Field

[0001] This application relates to the field of intelligent service technology for domestic operating systems, and in particular to an MCP server application method and system for domestic operating systems. Background Technology

[0002] Currently, the domestic operating system system is gradually maturing. Among them, the openKylin application ecosystem of the Kylin operating system continues to expand. The intelligent needs of the terminal side are showing a trend of localization, lightweighting and modularization. There is a demand for services with intelligent command execution capabilities to be directly deployed in the openKylin system in order to achieve automated and semantic execution of system operations such as network configuration, system updates, Bluetooth control, and screen brightness adjustment.

[0003] MCP (ModelContextProtocol) technology, with its unified model invocation standard and lightweight interface mechanism, has been used to build a middleware framework for "natural language commands - system operation execution". However, traditional MCP services are mostly developed for general Linux distributions or cloud model platforms, lacking a local deployment solution that is deeply compatible with the openKylin underlying system. On the one hand, existing MCP services are mostly provided in the form of Python scripts or container images, and installation and deployment require manual configuration of dependent environments, ports and authentication parameters, which ordinary users cannot directly complete deployment and operation. On the other hand, when executing commands, the service generally relies on the general Linux command set, which differs from openKylin-specific components (including the Wayland display layer, kylin-actuator command interface, UKUI interface, system settings center API, etc.), and some system commands cannot be called or executed correctly.

[0004] Meanwhile, existing solutions suffer from security and scalability deficiencies. Some automation tools obtain system command sets by scanning the / usr / bin directory, a method that poses security risks and suffers from insufficient indexing accuracy, easily leading to erroneous execution or abnormal permissions. Furthermore, a scalable "verified command set" mechanism has not yet been established, and newly added commands lack structured management and verification. In addition, the openKylin system is widely used in government, research, and closed intranet environments. Traditional MCP services rely on external networks or cloud model interfaces, lacking network state adaptive mechanisms, resulting in functional failure in offline or intranet environments. Moreover, the lack of permission hierarchies and security isolation for different levels of system commands poses risks of unauthorized execution and misoperation. In summary, the application of MCP technology on the openKylin system faces problems such as complex deployment, poor command compatibility, lack of verification mechanisms, and insufficient security adaptation. Summary of the Invention

[0005] This application provides an MCP server application method for a domestically developed operating system. The technical solution is as follows:

[0006] On the one hand, a method for applying MCP servers to domestically developed operating systems is provided, the method comprising:

[0007] In a domestic operating system environment, a local MCP server is built specifically for system instruction calls. The local MCP server encapsulates the unique interfaces of the domestic operating system and the general system instruction set.

[0008] The local MCP server is distributed in the form of a preset installation package;

[0009] After the preset installation package is installed, it automatically completes the configuration of dependent environments and local endpoint registration.

[0010] In response to the startup of the local MCP server, a preset "verified instruction set" is loaded. The "verified instruction set" stores system instructions that have been tested and verified for security. The local MCP server has an open configuration interface to support the addition of new system instructions. The newly added system instructions are enabled after verification.

[0011] In response to the local MCP server receiving the task execution request, the current user permissions and the network status of the domestic operating system are detected;

[0012] Perform permission verification based on the detected user permissions, and switch the corresponding execution mode according to the detected network status.

[0013] Based on the permission verification result and the execution mode, the task is executed by calling the "verified instruction set" or the newly added system instructions.

[0014] Optionally, the local MCP server is built based on the Python FastMCP framework;

[0015] The general system instruction set includes instructions for implementing Bluetooth control, volume adjustment, display mode switching, network configuration, and system updates;

[0016] The local MCP server uses a unified encapsulation of the MCP protocol interface to standardize and integrate the unique interface and the general system instruction set, and exposes the call interface to the outside world in the form of a service.

[0017] Optionally, the preset installation package is a .deb installation package;

[0018] After the preset installation package is installed, it automatically completes the configuration of dependent environments and local endpoint registration, including:

[0019] Create a dedicated user and directory to run the local MCP server;

[0020] Write to the default configuration file, which records the service name, local endpoint information, and log level;

[0021] The local MCP server daemon is started by executing the command "systemctlenable--now";

[0022] Perform health checks on the availability of local endpoints and log the results.

[0023] Optionally, the local endpoint is a loopback address or a Unix socket, and the local endpoint is used for natural language command calls or script command calls after the local MCP server starts.

[0024] Optionally, the "verified instruction set" is stored in JSON or SQLite format, and each system instruction corresponds to a record of command path, parameter format, execution level, security policy, and enabled status;

[0025] The configuration interface supports adding system commands via YAML or JSON format configuration files. The configuration files are placed in a preset directory of the domestic operating system. The local MCP server monitors the updates of the configuration files in the preset directory in real time, and automatically triggers the verification process for the newly added commands when an update is detected.

[0026] Optionally, newly added system commands are enabled after verification, whereby the verification includes:

[0027] Check the validity of the command path, the compliance of the parameter format, and the matching of the execution level with the preset permission range for newly added commands;

[0028] After verification, the local MCP server automatically updates the "verified instruction set" so that the new instructions take effect immediately.

[0029] Optionally, the step of responding to the local MCP server receiving the task execution request and detecting the current user permissions and the network status of the domestic operating system includes:

[0030] In response to the local MCP server receiving a task execution request, the user's UID is read using the os.getuid() function of Python, the user's GID is read using the os.getgid() function, and permission verification is performed based on a preset permission policy. The permission policy is stored in the preset permission file of the domestic operating system, and the permission policy records the executable instruction level corresponding to different UIDs / GIDs.

[0031] The connectivity between the public network address and the internal network gateway address is checked sequentially using the ping command. The network status is determined as online, restricted, or offline based on the connectivity results. The network status detection period is a preset duration, and the detection results are stored in a preset status file of the domestic operating system. The local MCP server reads the preset status file to obtain the network status before executing the task. The preset permission file is / etc / openkylin / mcp / permissions.json, the preset status file is / var / lib / openkylin / network_status.json, and the preset duration is 15 seconds.

[0032] Optionally, the execution mode includes local mode and cloud mode;

[0033] The step of switching the corresponding execution mode based on the detected network status includes:

[0034] If the detected network status is restricted intranet or offline, switch to local mode and only call the "verified instruction set" and the local components of the domestic operating system to execute the task;

[0035] If the detected network status is online, switch to cloud mode, enable cloud enhancement capabilities, and call the "verified instruction set" while calling the cloud model interface to assist in the execution of tasks.

[0036] On the other hand, an MCP server application system for a domestically developed operating system is provided, which is applied to the aforementioned MCP server application method for a domestically developed operating system. The system includes:

[0037] The server building module is used to build a local MCP server dedicated to system instruction calls in a domestic operating system environment. The local MCP server encapsulates the unique interfaces of the domestic operating system and the general system instruction set.

[0038] The server distribution module is used to distribute the local MCP server in the form of a preset installation package;

[0039] An automatic registration module is used to automatically complete the configuration of dependent environments and local endpoint registration after the preset installation package is installed;

[0040] The instruction set loading module is used to load a preset "verified instruction set" in response to the startup of the local MCP server. The "verified instruction set" stores system instructions that have been tested and verified for security. The local MCP server has an open configuration interface to support the addition of new system instructions. The newly added system instructions are enabled after verification.

[0041] The request detection module is used to detect the current user permissions and the network status of the domestic operating system in response to the task execution request received by the local MCP server.

[0042] The mode switching module is used to perform permission verification based on the detected user permissions and switch the corresponding execution mode according to the detected network status.

[0043] The task execution module is used to combine the permission verification result and the execution mode to call the "verified instruction set" or newly added system instructions to execute the task.

[0044] This application discloses an MCP server application method for domestic operating systems, belonging to the field of intelligent service technology for domestic operating systems. It addresses the problems of complex deployment, poor instruction compatibility, lack of verification mechanisms, and insufficient security adaptation of existing MCP services in domestic operating systems. The method involves constructing and deploying a local MCP server that encapsulates the unique interfaces and general instruction sets corresponding to the domestic operating system, achieving automatic configuration through a preset installation package; managing an instruction system containing "verified instruction sets" and verifiable newly added instructions; and adaptively switching execution modes based on user permission verification and network status detection to complete tasks. This invention is adaptable to various scenarios such as government affairs and scientific research, and can improve the intelligence and security of domestic operating systems. Attached Figure Description

[0045] Figure 1 This is a schematic diagram of the overall system architecture based on openKylinOS;

[0046] Figure 2 This is a schematic diagram of the instruction set verification and custom extension process of the present invention;

[0047] Figure 3 This is a schematic diagram of the adaptive control mechanism for execution permissions and network status of the present invention;

[0048] Figure 4 This is a detailed diagram illustrating the unified custom interface adaptation layer of this invention. Detailed Implementation

[0049] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0050] In this article, "multiple" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0051] This invention relates to the field of intelligent service technology for domestic operating systems, specifically a web search optimization method that runs on a domestic operating system and achieves intelligent recognition of user query intent and adaptive selection of the optimal search and content generation strategy by deeply utilizing the system's underlying security and hardware acceleration features.

[0052] To better illustrate the specific implementation of each embodiment, the following embodiments use the domestic operating system openKylin as an example for illustrative purposes. By constructing a system-level MCP server, natural language control and intelligent task execution of the core functions of the operating system are realized.

[0053] Example 1

[0054] like Figure 1 The diagram illustrates a flowchart of an MCP server application method for a domestically developed operating system. This application's embodiments include the core flow of the MCP server application method for a domestically developed operating system, covering the following key steps.

[0055] Step 1, System-level MCP server construction and packaging, including steps 101 to 103.

[0056] Step 101: In the domestic operating system environment, build a local MCP server dedicated to system instruction calls. The local MCP server encapsulates the unique interfaces of the domestic operating system and the general system instruction set.

[0057] In the openKylin environment, a local MCP server dedicated to system command calls is built based on the Python FastMCP framework. The server encapsulates the openKylin-specific kylin-actuator interface and a general system command set (including Bluetooth control, volume adjustment, display mode switching, network configuration, and system update commands). The server's main program registers utility methods, and all system operations are uniformly issued through kylin-actuator, ensuring consistency and stability with native openKylin commands.

[0058] By unifying and encapsulating the MCP protocol interface, the function calls scattered across different modules of the system are standardized and integrated, and the call interface is exposed to the outside world in the form of a service. It supports the transmission of natural language commands or script commands through the MCP channel to complete semantic parsing, module matching and result feedback (for example, when the user enters "turn on Bluetooth", the system calls the kylin-actuator Bluetooth module interface to execute the command and return the device status; when the user enters "adjust the brightness to 80%", the display control module is called to modify the brightness and the result is fed back).

[0059] Step 102: Distribute the local MCP server in the form of a preset installation package.

[0060] The local MCP server is packaged and distributed as a .deb installation package, which users can download directly from the openKylin system software center without relying on third-party package management tools, thus adapting to the native openKylin installation ecosystem.

[0061] Step 103: After the preset installation package is installed, the dependency environment configuration and local endpoint registration will be completed automatically.

[0062] The installation process also includes a pre-loaded set of verified basic command capabilities, which can be run directly in the openKylin desktop environment without any scripts or manual intervention.

[0063] Step 2, instruction set verification and custom extension mechanism, including step 104.

[0064] Step 104: In response to the startup of the local MCP server, load the preset "verified instruction set" (also known as "verified instruction index library").

[0065] The "Verified Instruction Set" stores system instructions that have been tested and verified for security. The local MCP server has an open configuration interface to support the addition of new system instructions. After the new system instructions are verified, they are enabled and included in the instruction management scope. After the system receives natural language or script input from the user, it first matches the registered instructions in the "Verified Instruction Set" according to the instruction name and parameters.

[0066] In one example Figure 2 This diagram illustrates the instruction set verification and custom extension process of the present invention, showcasing the workflow of the "instruction set verification and custom extension mechanism" in the MCP server based on the openKylin operating system. The system first receives natural language or script input from the user, then passes the input to the instruction index retrieval module. This module matches the instruction name and parameters against the registered "verified instruction sets" (i.e., secure instruction sets) within the system. If the retrieved instruction exists and is valid, the system enters the instruction validity verification stage, checking the validity of the instruction's command path, the compliance of its parameter format, and its execution permissions. Upon successful verification, the underlying kylin-actuator interface is invoked to execute the corresponding operation. If the retrieved instruction is not registered, the developer loads a YAML or JSON configuration file through the custom extension module. After loading, the configuration file undergoes format validation and security verification (including instruction path detection, parameter judgment, and permission comparison). Upon successful verification, the instruction is written into the "verified instruction set" and takes effect immediately, making it callable. Regardless of whether the instruction is newly added, after execution, the result feedback and log module will return the execution status (success / failure reason) to the front end, realizing the secure invocation and dynamic expansion of system-level instructions, which not only ensures the security of instruction execution, but also meets the personalized expansion needs of developers.

[0067] Step 3, execution permission and network status adaptive control, including steps 105 to 107.

[0068] Step 105: In response to the local MCP server receiving the task execution request, check the current user permissions and the network status of the domestic operating system;

[0069] Task execution requests are triggered by users through natural language input or custom script interfaces, and structured calls are generated after front-end intent parsing.

[0070] Step 106: Perform permission verification based on the detected user permissions, and switch the corresponding execution mode according to the detected network status;

[0071] Permission verification requires matching the current user's identity with system policy entries. Network status switching uses atomic markers and triggers capability list reloading.

[0072] In one example, if the network status is restricted intranet or offline, switch to local mode, only call the "verified instruction set" and openKylin local lightweight components, block external network dependencies such as online updates and remote fetching, and enable the least privilege set;

[0073] In one example, if the network status is online, switch to cloud mode and enable cloud enhancement capabilities (such as calling cloud-based large models to optimize natural language parsing) to assist in performing complex tasks while calling "verified instruction sets".

[0074] Step 107: Combining the permission verification result with the execution mode, call the "verified instruction set" or the newly added system instruction to execute the task.

[0075] Combining the permission verification result and the execution mode, the system execution module calls the underlying tools (specific execution tools, web search tools, system operation tools) to execute tasks. All operations record the instruction identifier, parameter summary, execution result and timestamp. The logs are stored locally for auditing and backtracking. The execution result is fed back to the front end (for example: if the user inputs "the environment is dark and it is inconvenient to read", the front end parses it as "reduce brightness + switch to dark mode", the server executes set_brightness(40) and set_display_mode("dark"), and returns "brightness has been reduced and dark mode has been enabled").

[0076] In one example, as in another example, Figure 1 As shown, Figure 1This diagram illustrates the overall architecture of the MCP server application system based on openKylinOS. The system comprises five main parts: a calling module, an interface module, a model management module, an MCPServer service application module, and a system execution module, all supported by openKylinOS. Users can trigger task requests via natural language input or custom script interfaces. These requests are then passed to the MCPServer service application module via the calling module. The MCPServer service application module contains four core functional modules: the MCP core scheduling engine, the MCP command verification module, the MCP permission control module, and the network status detection module. The MCP core scheduling engine is responsible for unifying the task execution process; the MCP command verification module verifies the legality and security of commands; the MCP permission control module implements hierarchical management and execution isolation; and the network status detection module determines the system's network connectivity in real time to decide whether a task runs in online or offline mode. During the task execution phase, the system invokes underlying execution tools through the system execution module. These tools include specific execution tools, web search tools, and system operation tools, enabling direct operation of openKylin operating system functions (such as Bluetooth control, volume adjustment, and network configuration). Execution results are collected, recorded, and fed back to the user by the result return and log recording module, and can also be synchronized to the local large model for further semantic optimization or learning. The overall system features "plug and play, semantic invocation, security and controllability, and online / offline adaptiveness," achieving a closed-loop process from natural language input to system function execution, providing a unified intelligent instruction invocation and service framework for domestic operating systems.

[0077] Example 2

[0078] Optionally, the local MCP server is built on the Python FastMCP framework;

[0079] The general system instruction set includes instructions for implementing Bluetooth control, volume adjustment, display mode switching, network configuration, and system updates;

[0080] The local MCP server uses a unified encapsulation of the MCP protocol interface to standardize and integrate unique interfaces and general system instruction sets, exposing the call interface externally as a service. In one example, the openKylin system-specific interface is defined as the kylin-actuator interface.

[0081] Natural language commands or script commands can be transmitted to the local MCP server via the MCP channel, where the server performs semantic parsing, module matching, and result feedback. For example, when a user inputs "turn on Bluetooth", the system automatically recognizes the intent and calls the Bluetooth module interface of kylin-actuator to execute the underlying command and return the current device status. When the user inputs "adjust brightness to 80%", the display control module is called to dynamically modify the screen brightness and provide real-time feedback on the operation result.

[0082] Example 3

[0083] Optionally, the default installation package is a .deb package. After the default installation package is installed in step 103, it will automatically complete the dependency environment configuration and local endpoint registration, including:

[0084] S31, Create a dedicated user and directory to run the local MCP server;

[0085] For example, a dedicated user "mcp" and directory " / opt / openkylin-mcp / " are created to prevent the service from running with high privileges and reduce security risks.

[0086] S32, write to the default configuration file, the default configuration file records the service name, local endpoint information, and log level;

[0087] For example, write the default configuration file " / etc / openkylin / mcp / server.json" to record the service name (openkylin-mcp), local endpoint information (loopback address or UnixSocket), and log level.

[0088] S33, start the local MCP server daemon by executing the command "systemctlenable--now";

[0089] In one example, the systemd unit configuration for the daemon is as follows:

[0090] [Service]

[0091] ExecStart= / usr / bin / python3 / opt / openkylin-mcp / server.py

[0092] User=mcp

[0093] Restart=always

[0094] Environment=QT_QPA_PLATFORM=offscreen

[0095] S34 performs health checks on the availability of local endpoints and logs the results. It comes pre-loaded with a set of verified basic command capabilities and can run directly in the openKylin desktop environment without manual intervention, achieving "plug and play".

[0096] In addition, sample code for the local MCP server's service entry point ( / opt / openkylin-mcp / server.py) is provided below:

[0097] ① Sample code for service entry point

[0098] # / opt / openkylin-mcp / server.py

[0099] frommcp.server.fastmcpimportFastMCP

[0100] import subprocess

[0101] mcp=FastMCP("KylinTools")

[0102] @mcp.tool()

[0103] defset_brightness(percent:int)->str:

[0104] subprocess.call(['kylin-actuator',f'{{setbrightness{percent}}}'])

[0105] return "Brightness has been set to {percent}%"

[0106] @mcp.tool()

[0107] defset_display_mode(mode:str)->str:

[0108] #modein{"light","dark"}

[0109] subprocess.call(['kylin-actuator',f'{{set{mode}}}'])

[0110] return "The mode has been switched to {'light'ifmode=='light'else'dark'}"

[0111] if__name__=="__main__":

[0112] mcp.run() # Start the local MCP endpoint

[0113] ②Example code for the systemd unit

[0114] # / etc / systemd / system / openkylin-mcp.service

[0115] [Service]

[0116] ExecStart= / usr / bin / python3 / opt / openkylin-mcp / server.py

[0117] User=mcp

[0118] Restart=always

[0119] Environment=QT_QPA_PLATFORM=offscreen

[0120] ③ Key actions of the installation script: Create the running user and directory; write the default configuration and endpoint information to / etc / openkylin / mcp / server.json; after installation, execute systemctlenable--nowopenkylin-mcp to start the daemon process; perform a health check on endpoint availability and log the results.

[0121] Example 4

[0122] Optionally, the local endpoint can be a loopback address or a Unix socket. The local endpoint is used for natural language command calls or script command calls after the local MCP server starts up.

[0123] Once the local MCP server is started, the front-end or script can send structured calls to the local endpoint via the MCP protocol to trigger the corresponding system operation. After installation, users do not need to perform any additional configuration and can call system functions through any front-end / client that supports MCP.

[0124] Example 5

[0125] Optionally, the instruction set is stored in JSON or SQLite format. Each instruction records the command path, parameter format, execution level (normal / restricted / administrator), security policy, and enabled status. After receiving user input in natural language or script, the system first uses the instruction index library to search for and match registered instructions. The specific process is as follows.

[0126] Command verification: If the command is registered and enabled, verify the validity of its command path, the compliance of its parameter format (e.g., brightness adjustment requires integer parameters), and the matching of its execution level with user permissions. If the verification is successful, call the kylin-actuator interface to execute it. If the command is not registered or is disabled, return exception prompts such as "command not verified" or "command disabled" to avoid the risk of accidental execution.

[0127] Custom extensions are available, with an exposed server configuration interface supporting the addition of commands via YAML / JSON format configuration files (located in the " / etc / openkylin / mcp / " directory). An example configuration file (custom_commands.yaml) and its corresponding script are shown below:

[0128] open_my_workspace:

[0129] path: / home / user / scripts / open_workspace.sh

[0130] params:{}

[0131] level:normal

[0132] enabled:true

[0133] The corresponding custom script ( / home / user / scripts / open_workspace.sh) contains the following:

[0134] #! / bin / bash

[0135] #! / bin / bash

[0136] #Custom script: Open a specific workspace folder and launch the application

[0137] xdg-open / home / user / Documents / project

[0138] libreoffice--writer&

[0139] Example 6

[0140] Optionally, in step 104, the newly added system command is enabled after verification, wherein the verification content includes:

[0141] S41, check the validity of the command path, the compliance of the parameter format, and the matching of the execution level with the preset permission range of the newly added command;

[0142] If the instruction is not registered or is disabled, the call will be refused and an exception message will be returned.

[0143] S42. After verification, the local MCP server automatically updates the "verified instruction set" so that the new instructions take effect immediately.

[0144] New instructions must be included in the index system of the "verified instruction set" to generate corresponding index entries.

[0145] In addition, if the command is not registered in step 104, the developer loads the YAML / JSON format configuration file through a custom extension module, writes it into the index after the above verification process, and it takes effect immediately.

[0146] In one example, optionally, the verification process for calling the "verified instruction set" in step 104 includes the following example code logic:

[0147] importjson

[0148] import subprocess

[0149] # Load the verified instruction index library

[0150] withopen(' / etc / openkylin / mcp / verified_commands.json','r',encoding='utf-8')asf:

[0151] verified_commands=json.load(f)

[0152] defexecute_verified_command(cmd_name,args=None):

[0153] ifcmd_namenotinverified_commands:

[0154] The command `returnf` is not registered or validated; execution is refused.

[0155] command_entry=verified_commands[cmd_name]

[0156] ifnotcommand_entry.get("enabled",False):

[0157] The `returnf` directive `{cmd_name}` is currently disabled.

[0158] #Parameter validation

[0159] ifargsandcommand_entry.get("params"):

[0160] expected=command_entry["params"]

[0161] forkeyinargs:

[0162] if key not in expected:

[0163] return "Illegal parameter: {key}"

[0164] #Execute system commands

[0165] subprocess.call([command_entry["path"],*args.values()]ifargselse[command_entry["path"]])

[0166] The command `returnf` was executed successfully.

[0167] Example 7

[0168] Optionally, step 105 responds to the local MCP server receiving the task execution request by checking the current user permissions and the network status of the domestic operating system, including:

[0169] S51 responds to the task execution request received by the local MCP server, reads the user's UID through the os.getuid() function of Python, reads the user's GID through the os.getgid() function, and performs permission verification based on the preset permission policy. The permission policy is stored in the preset permission file of the domestic operating system openKylin, and the permission policy records the executable instruction level corresponding to different UID / GID.

[0170] The permission verification is a dual verification: first, the user's identity is verified, and then the command level (normal, restricted, or administrator) is determined based on the "verified command set". High-sensitivity operations (such as network routing changes, system upgrades, and driver loading) require secondary confirmation or token verification. If the conditions are not met, execution is refused and a reason is returned.

[0171] In one example, after receiving a task execution request, the user's UID / GID is read using Python's os.getuid() / os.getgid() functions. This is then matched against the preset permission policy file " / etc / openkylin / mcp / permissions.json" (which records the executable command levels corresponding to different UIDs / GIDs). Highly sensitive operations (such as network routing changes or system upgrades) require secondary confirmation or token verification.

[0172] S52 uses the ping command to sequentially check the connectivity between the public network address and the internal network gateway address, and determines the network status as online, internal network restricted, or offline based on the connectivity results.

[0173] The public IP address is 8.8.8.8, and the internal network gateway address is 10.0.0.1. The detection logic is as follows: try pinging 8.8.8.8 (-c1, -W2). If the connection is successful, the network is online. If the connection fails, try pinging 10.0.0.1 (-c1, -W2). If the connection is successful, the network is restricted within the internal network. If the connection fails, the network is offline.

[0174] The network status detection is performed by a custom network status detection service that runs independently in the background. The detection period is a preset duration, and the detection results are stored in a preset status file in the domestic operating system openKylin. Before executing the task, the local MCP server reads the preset status file to obtain the network status. The preset permission file is / etc / openkylin / mcp / permissions.json, the preset status file is / var / lib / openkylin / network_status.json, and the preset duration is 15 seconds.

[0175] The sample code for the custom network status detection service ( / usr / lib / openkylin-mcp / network_monitor.py) is as follows:

[0176] import os, json, time, subprocess

[0177] defcheck_network_status():

[0178] try:

[0179] subprocess.check_output(["ping","-c","1","-W","2","8.8.8.8"])

[0180] return "online"

[0181] except subprocess.CalledProcessError:

[0182] try:

[0183] # Detect intranet reachability

[0184] subprocess.check_output(["ping", "-c", "1", "-W", "2", "10.0.0.1"])

[0185] return "intranet"

[0186] except subprocess.CalledProcessError:

[0187] return "offline"

[0188] def update_status_file(status): <​​​​​​​​​​​​​​​​​​​​​​​​​​​Therefore, the detection results are written to " / var / lib / openkylin / network_status.json" for the server to read and determine the network status (online / restricted intranet / offline). It should be noted that S51 and S52 are not in any particular order.

[0199] Example 8

[0200] Optionally, if the execution mode includes local mode and cloud mode, then in step 108, switching the corresponding execution mode based on the detected network status includes:

[0201] S81, if the detected network status is restricted or offline, switches to local mode and only calls the "verified instruction set" and local components of the domestic operating system to execute tasks;

[0202] Among them, external network dependencies (such as online updates, remote fetching, etc.) are blocked, and when in "internal network isolation mode", only the local channel is retained and the least privilege set is forcibly enabled.

[0203] S82, if the detected network status is online, switches to cloud mode, enables cloud enhancement capabilities, and can call the cloud model interface to assist in the execution of tasks while calling the "verified instruction set".

[0204] All executed operations record the instruction identifier, parameter summary, execution result, and timestamp. The logs are stored locally for auditing and backtracking.

[0205] In one example Figure 3This diagram illustrates the flow of the adaptive control mechanism for execution permissions and network status in this invention. It shows the complete process of the "adaptive control mechanism for execution permissions and network status" on the MCP server based on the openKylin operating system. At the permission control level, the system implements hierarchical authorization during runtime by loading the local permission configuration file (path: / etc / openkylin / mcp / permissions.json) and reading user identity information (UID / GID). It performs double verification on command execution: first, it verifies the identity of the requesting user before the call, confirming the user's permission level; then, it determines the execution level of the command (normal, restricted, administrator) based on the "verified command set." If the user's permissions do not match the command level (e.g., a normal user calling an administrator-level command), execution is refused and a reason is returned, preventing unauthorized access or accidental operation. At the network status control level, a custom network status detection service installed with the MCPServer runs continuously in the background. This service checks network connectivity by periodically pinging the public IP address (8.8.8.8) and the internal network gateway address (10.0.0.1). Based on the connectivity result, it determines the network status as online, restricted within the internal network, or offline, and writes the detection results to a status file (path: / var / lib / openkylin / network_status.json) in real time. The MCP server reads this status file before executing tasks and adaptively switches the execution mode according to the network status (calling the local model when offline, and enabling cloud collaboration when online). All execution results and status changes (such as mode switching and permission denial) are ultimately fed back to the log feedback module for system auditing and operation recording, ensuring that operations are traceable and secure.

[0206] Example 9

[0207] The local MCP server also includes a unified custom interface adaptation layer. This layer is responsible for receiving structured tasks after intent parsing and distributing them according to task type: general system operations are executed by the MCP general instruction processing unit, which calls the standard instruction set after verification; for openKylin-specific instructions, the dedicated API adaptation unit calls the underlying kylin-actuator interface to execute them; the adaptation layer has built-in instruction verification and permission verification mechanisms, and has network status awareness capabilities, and can adaptively switch between online and offline modes.

[0208] In one example Figure 4 This diagram illustrates the working principle of the unified custom interface adaptation layer in the MCP server application of this invention.

[0209] The core function of this adaptation layer is to receive structured tasks after front-end intent parsing and to accurately distribute them according to task type: For general system operations such as Bluetooth control and volume adjustment, the adaptation layer assigns the task to the MCP general instruction processing unit, which verifies the task (matches the "verified instruction set") and then calls the standard instruction set to execute it; For instructions involving openKylin-specific functions such as the Wayland display layer and UKUI interface (such as adjusting resolution and switching system themes), the adaptation layer assigns the task to the dedicated API adaptation unit, which directly calls the underlying kylin-actuator interface to perform the operation, ensuring compatibility with openKylin's native functions.

[0210] Meanwhile, the adaptation layer incorporates a built-in command verification and permission check mechanism. Before task distribution, it performs preliminary verification of command validity and user permissions, reducing the processing pressure on subsequent modules. The adaptation layer also has network status awareness capabilities. It can read the network status file ( / var / lib / openkylin / network_status.json) to obtain the current network status and adaptively switch execution logic between online and offline modes (such as calling cloud interfaces to assist in parsing when online, and relying only on local components when offline). This ensures the security, stability, and efficiency of task execution and achieves unified management and adaptation of general and specific commands.

[0211] Example 10

[0212] On the other hand, an MCP server application system for a domestically developed operating system is provided, which is applied to the aforementioned MCP server application method for a domestically developed operating system. This system can be integrated into the terminal device used for operation. The system includes:

[0213] The server building module is used to build a local MCP server dedicated to system instruction calls in a domestic operating system environment. The local MCP server encapsulates the interfaces unique to the domestic operating system and the general system instruction set.

[0214] The server distribution module is used to distribute the local MCP server in the form of a preset installation package;

[0215] An automatic registration module is used to automatically complete the configuration of dependent environments and local endpoint registration after the preset installation package is installed;

[0216] The instruction set loading module is used to load a preset "verified instruction set" in response to the startup of the local MCP server. The "verified instruction set" stores system instructions that have been tested and verified for security. The local MCP server has an open configuration interface to support the addition of new system instructions. The newly added system instructions are enabled after verification.

[0217] The request detection module is used to detect the current user permissions and the network status of the domestic operating system in response to the task execution request received by the local MCP server.

[0218] The mode switching module is used to perform permission verification based on the detected user permissions and switch the corresponding execution mode according to the detected network status.

[0219] The task execution module is used to combine the permission verification result and the execution mode to call the "verified instruction set" or newly added system instructions to execute the task.

[0220] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0221] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware, or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk. The above descriptions are merely optional embodiments of this application and are not intended to limit the application. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A method for applying MCP servers to domestically developed operating systems, characterized in that, The method includes: In a domestic operating system environment, a local MCP server is built specifically for system instruction calls. The local MCP server encapsulates the unique interfaces of the domestic operating system and the general system instruction set. The local MCP server is distributed in the form of a preset installation package; After the preset installation package is installed, it automatically completes the configuration of dependent environments and local endpoint registration. In response to the startup of the local MCP server, a preset "verified instruction set" is loaded. The "verified instruction set" stores system instructions that have been tested and verified for security. The local MCP server has an open configuration interface to support the addition of new system instructions. The newly added system instructions are enabled after verification. In response to the local MCP server receiving the task execution request, the current user permissions and the network status of the domestic operating system are detected; Perform permission verification based on the detected user permissions, and switch the corresponding execution mode according to the detected network status. Based on the permission verification result and the execution mode, the task is executed by calling the "verified instruction set" or newly added system instructions; The step of responding to the local MCP server receiving the task execution request and detecting the current user permissions and the network status of the domestic operating system includes: In response to the local MCP server receiving a task execution request, the user's UID is read using the os.getuid() function of Python, the user's GID is read using the os.getgid() function, and permission verification is performed based on a preset permission policy. The permission policy is stored in the preset permission file of the domestic operating system, and the permission policy records the executable instruction level corresponding to different UIDs / GIDs. The connectivity between the public network address and the internal network gateway address is checked sequentially using the ping command. The network status is determined as online, restricted, or offline based on the connectivity results. The network status detection period is a preset duration, and the detection results are stored in a preset status file of the domestic operating system. The local MCP server reads the preset status file to obtain the network status before executing the task. The preset permission file is / etc / openkylin / mcp / permissions.json, the preset status file is / var / lib / openkylin / network_status.json, and the preset duration is 15 seconds. The execution modes include local mode and cloud mode; the step of switching the corresponding execution mode according to the detected network status includes: If the detected network status is restricted within the intranet or offline, switch to local mode and only call the "verified instruction set" and the local components of the domestic operating system to execute the task; If the detected network status is online, switch to cloud mode, enable cloud enhancement capabilities, and call the "verified instruction set" while also calling the cloud model interface to assist in task execution.

2. The MCP server application method for a domestically developed operating system according to claim 1, characterized in that, The local MCP server is built on the Python FastMCP framework; The general system instruction set includes instructions for implementing Bluetooth control, volume adjustment, display mode switching, network configuration, and system updates; The local MCP server uses a unified encapsulation of the MCP protocol interface to standardize and integrate the unique interface and the general system instruction set, and exposes the call interface to the outside world in the form of a service.

3. The MCP server application method for domestic operating systems according to claim 1, characterized in that, The preset installation package is a .deb installation package; After the preset installation package is installed, it automatically completes the configuration of dependent environments and local endpoint registration, including: Create a dedicated user and directory to run the local MCP server; Write to the default configuration file, which records the service name, local endpoint information, and log level; The local MCP server daemon is started by executing the command "systemctlenable--now"; Perform health checks on the availability of local endpoints and log the results.

4. The MCP server application method for domestic operating systems according to claim 1, characterized in that, The local endpoint is a loopback address or a Unix socket, and it is used for natural language command calls or script command calls after the local MCP server starts.

5. The MCP server application method for a domestically developed operating system according to claim 1, characterized in that, The "verified instruction set" is stored in JSON or SQLite format, and each system instruction corresponds to a record of command path, parameter format, execution level, security policy, and enabled status; The configuration interface supports adding system commands via YAML or JSON format configuration files. The configuration files are placed in a preset directory of the domestic operating system. The local MCP server monitors the updates of the configuration files in the preset directory in real time, and automatically triggers the verification process for the newly added commands when an update is detected.

6. The MCP server application method for a domestically developed operating system according to claim 5, characterized in that, Newly added system commands are activated after verification. The verification includes the following: Check the validity of the command path, the compliance of the parameter format, and the matching of the execution level with the preset permission range for newly added commands; After verification, the local MCP server automatically updates the "verified instruction set" so that the new instructions take effect immediately.

7. An MCP server application system for a domestically developed operating system, characterized in that, The MCP server application method for any one of claims 1 to 6, oriented towards a domestically developed operating system, comprises: The server building module is used to build a local MCP server dedicated to system instruction calls in a domestic operating system environment. The local MCP server encapsulates the interfaces unique to the domestic operating system and the general system instruction set. The server distribution module is used to distribute the local MCP server in the form of a preset installation package; An automatic registration module is used to automatically complete the configuration of dependent environments and local endpoint registration after the preset installation package is installed; The instruction set loading module is used to load a preset "verified instruction set" in response to the startup of the local MCP server. The "verified instruction set" stores system instructions that have been tested and verified for security. The local MCP server has an open configuration interface to support the addition of new system instructions. The newly added system instructions are enabled after verification. The request detection module is used to detect the current user permissions and the network status of the domestic operating system in response to the task execution request received by the local MCP server. The mode switching module is used to perform permission verification based on the detected user permissions and switch the corresponding execution mode according to the detected network status. The task execution module is used to combine the permission verification result and the execution mode to call the "verified instruction set" or newly added system instructions to execute the task; The request detection module is further configured to: respond to the local MCP server receiving a task execution request, read the user's UID using the Python `os.getuid()` function, read the user's GID using the `os.getgid()` function, and perform permission verification based on a preset permission policy, wherein the permission policy is stored in a preset permission file of the domestic operating system, and the permission policy records the executable instruction levels corresponding to different UIDs / GIDs; sequentially detect the connectivity between the public network address and the internal network gateway address using the ping command, and determine the network status as online, internal network restricted, or offline based on the connectivity result, wherein the network status detection period is a preset duration, and the detection results are stored in a preset status file of the domestic operating system, and the local MCP server reads the preset status file before executing the task. The file retrieves network status, with the preset permission file being / etc / openkylin / mcp / permissions.json and the preset status file being / var / lib / openkylin / network_status.json. The preset duration is 15 seconds. The execution mode includes local mode and cloud mode. Switching the corresponding execution mode based on the detected network status includes: if the detected network status is restricted within the intranet or offline, switching to local mode, only calling the "verified instruction set" and the local components of the domestic operating system to execute the task; if the detected network status is online, switching to cloud mode, enabling cloud enhancement capabilities, and calling the "verified instruction set" while also calling the cloud model interface to assist in task execution.

Images