A cloud platform inspection method and system fusing an mcp protocol and a large language model

Abstract

This invention provides a cloud platform inspection method and system integrating the MCP protocol and a large language model, relating to the field of cloud computing technology. This method solves the problems of inconvenient human-computer interaction, difficult tool integration, and weak analytical capabilities in traditional cloud platform inspections. Its core process is as follows: First, the LLM parses the user's natural language inspection commands and intelligently orchestrates inspection tasks using a knowledge base; then, the MCPServer calls the n8n automated workflow engine to complete the collection of heterogeneous data from the cloud platform; subsequently, the LLM performs semantic summarization and K-means risk clustering analysis on the inspection data, ultimately generating a deep report containing root cause inferences and remediation suggestions. This invention employs private deployment to ensure data security, achieves intelligent operation of the entire inspection process, improves inspection efficiency and risk insight capabilities, and is applicable to cloud platform inspections in multiple scenarios.

Description

Technical Field

[0001] This invention relates to the field of cloud computing technology, and more particularly to the field of cloud computing operation and maintenance management that integrates artificial intelligence technology. Specifically, it relates to a cloud platform inspection method and system that integrates the MCP protocol and a large language model. Background Technology

[0002] Currently, cloud platform inspections mainly rely on the following methods:

[0003] Manual inspection: Operations personnel check each configuration and metric item by item according to a predefined checklist by logging into the cloud platform console or using command-line tools (CLI). For example, checking the security group rules of virtual machines, public access permissions of storage buckets, and database backup policies. This method is time-consuming, labor-intensive, inefficient, and prone to omissions or errors due to human negligence.

[0004] Scripted inspections: Operations personnel write specific scripts (such as Python, PowerShell, and shell scripts) to automate some inspection tasks. These scripts typically call APIs provided by cloud service providers to obtain resource information and make judgments. For example, a script might be used to traverse all ECS instances and check whether they are all associated with the expected IAM role. While scripts improve efficiency, the cost of writing, maintaining, and updating scripts is high, and they are difficult to cover all inspection points, resulting in poor versatility and flexibility. Different cloud platforms and different services often require different scripts, making unified management difficult.

[0005] Dedicated Inspection Tools / Services: Cloud service providers offer their own inspection tools, or third-party commercial or open-source inspection tools. These tools typically incorporate industry best practices or compliance standards (such as CIS Benchmarks) and can automatically scan the cloud environment and generate risk reports. They usually have graphical interfaces and predefined inspection rules.

[0006] Traditional AIOps platforms: Some AIOps platforms attempt to integrate monitoring and log data for analysis to identify anomalies and potential problems. They may use traditional machine learning algorithms for anomaly detection or trend prediction. However, these platforms typically lack the ability to understand natural language instructions, and task definition and adjustments still require specialized configuration. Furthermore, they have limited capabilities in semanticizing and intelligently summarizing analysis results, often generating reports that are simply lists of structured data or simple charts, lacking in-depth insights and root cause analysis capabilities. Summary of the Invention

[0007] Purpose of the invention: To propose a cloud platform inspection method and system that integrates the MCP protocol and a large language model, in order to solve the shortcomings of existing cloud platform inspection technologies in terms of intelligence, human-computer interaction convenience, task scheduling flexibility, and in-depth analysis and insight of inspection results, especially how to efficiently integrate and utilize the powerful capabilities of the large language model to empower the entire inspection process.

[0008] In a first aspect, this invention proposes a cloud platform inspection method that integrates the MCP protocol and a large language model, comprising the following steps: Step 1: The user inputs the inspection requirements in natural language. The large language model parses the natural language inspection requirements, identifies the task intent, inspection scope and key checkpoints, and generates a structured task description. Step 2: The large language model queries the knowledge base to obtain metadata, inspection strategies and historical experience of available inspection workflows. Based on the structured task description generated in Step 1, the user task is decomposed into an executable workflow sequence and the calling parameters of each workflow are determined. Step 3: The large language model constructs an execution request according to the MCP protocol specification, based on the workflow sequence and call parameters of each workflow determined in Step 2, and sends the execution request to the MCP server; after verifying the execution request, the MCP server converts it into a format recognizable by the automated workflow engine and triggers the execution of the corresponding inspection workflow. Step 4: The automated workflow engine executes the inspection workflow triggered in step 3, and collects cloud platform data by calling the cloud platform API to form heterogeneous data; Step 5: The large language model receives the heterogeneous data collected in step 4, performs semantic understanding and key information extraction on the heterogeneous data, and generates a natural language risk summary; extracts risk features and performs vectorization processing, applies a clustering algorithm to group risk points into risk clusters, and the large language model generates a name and description for each risk cluster. Step 6: The large language model queries the knowledge base to obtain compliance baselines and best practices, and integrates them with the natural language risk summary, risk cluster names and descriptions generated in Step 5 to form an inspection report.

[0009] As a preferred embodiment, the knowledge base stores inspection strategies, compliance baselines, workflow metadata, historical inspection data, and best practices; the large language model queries the knowledge base through retrieval-enhanced generation technology to obtain the information required to complete intelligent task orchestration and in-depth report generation.

[0010] As a preferred embodiment, in step 1, the structured task description includes task type, target platform, target resources, inspection scope, and inspection dimension information, wherein the inspection dimension is associated with the corresponding compliance standards or policy requirements.

[0011] As a preferred option, in step 2, the intelligent task orchestration of the large language model includes parameter mapping and value filling, dynamic querying and transformation based on the knowledge base, or calling a dedicated transformation function to transform the user's abstract requirements into specific call parameters that can be executed in the workflow.

[0012] As a preferred option, the automated workflow engine is deployed privately; in step 3, the MCP server, as the implementation carrier of the MCP protocol, encapsulates the access capability to the automated workflow engine, and realizes standardized interaction between the large language model and the automated workflow engine.

[0013] As a preferred solution, in step 4, the cloud platform data includes configuration information, performance indicators, logs, and security alarms; the inspection workflow consists of trigger nodes, API call nodes, loop nodes, data processing nodes, and result aggregation nodes. Each node works together to complete cloud platform data collection, data format conversion, and data compliance comparison, ultimately forming heterogeneous data.

[0014] As a preferred embodiment, in step 5, the clustering algorithm is the K-means clustering algorithm; the risk features include risk type, severity level, affected resource ID, affected components, optional CVE number and business impact label, and the risk features are converted into numerical vectors through one-hot encoding or word embedding technology; the risk features are extracted from the heterogeneous data or natural language risk summary.

[0015] As a preferred embodiment, the inspection report includes risk description, cluster analysis, potential root cause prediction, and remediation suggestions. The inspection method is triggered either manually by the user through natural language or automatically by an external monitoring system after detecting performance anomalies. When the external monitoring system detects an anomaly, it sends an event notification containing the anomaly type, affected resources, and timestamp to the large language model. The large language model parses the event notification, replacing the natural language inspection requirement parsing process in step 1, and generates a corresponding structured task description before executing steps 2 to 6.

[0016] Furthermore, this invention proposes a cloud platform inspection system that integrates the MCP protocol and a large language model. The system includes: The interaction module is used to receive natural language inspection requests input by users or to receive event notifications sent by external monitoring systems and output inspection reports to users. The large language model is used to parse the natural language inspection requirements or event notifications received by the interaction module to generate a structured task description, query the knowledge base and intelligently orchestrate the structured task description based on the knowledge base information to determine the workflow sequence and call parameters, receive heterogeneous data and perform semantic summarization and risk clustering to generate a natural language risk summary and risk cluster names and descriptions, and integrate the knowledge base information to form an inspection report. The MCP server, following the MCP protocol, is used to receive execution requests sent by the large language model, verify the execution requests, and forward them to the automated workflow engine, thereby realizing standardized interaction between the large language model and the automated workflow engine; the execution requests are constructed by the large language model based on the workflow sequence and calling parameters. The automated workflow engine receives requests forwarded by the MCP server and executes the corresponding inspection workflow. It collects cloud platform data by calling the cloud platform API, forms heterogeneous data, and feeds it back to the large language model. A knowledge base is used to store relevant information that assists large language models in completing tasks, providing data support for large language models.

[0017] As a preferred option, the large language model is deployed privately and has the capabilities of natural language processing, reasoning, task orchestration, and text generation. The knowledge base stores relevant information including inspection strategies, compliance baselines, workflow metadata, historical inspection data, fault modes, and remediation suggestions. The large language model obtains data support from the knowledge base through retrieval-enhanced generation technology.

[0018] As a preferred option, the automated workflow engine is deployed privately; the cloud platform data includes configuration information, performance metrics, logs, and security alerts; the event notification includes the exception type, affected resources, and timestamp, and is sent to the interaction module by an external monitoring system via Webhook or API call when the cloud platform performance metrics exceed a preset threshold.

[0019] Compared with the prior art, the present invention has at least the following beneficial effects: (1) Utilize the natural language understanding, reasoning and orchestration capabilities of LLM to achieve intelligent processing of the entire process from task definition and execution to result analysis.

[0020] (2) Users can easily initiate complex inspection tasks through natural language, reducing the threshold for use.

[0021] (3) LLM can dynamically arrange and adjust the inspection workflow according to user intent and real-time context to adapt to diverse inspection needs.

[0022] (4) Through semantic summarization and risk clustering, massive and heterogeneous inspection data are transformed into valuable and actionable risk insights, revealing potential systemic risks.

[0023] (5) By leveraging the MCP protocol, the interaction between LLM and external execution tools (workflow engines) is standardized, simplifying integration and improving the scalability and maintainability of the system.

[0024] (6) By deploying LLM and workflow engine privately, ensure that sensitive cloud platform inspection data is processed in an enterprise-controlled environment.

[0025] (7) Inspection strategies and analysis experience can be solidified into the knowledge base to help LLM continuously optimize inspection capabilities. Attached Figure Description

[0026] Figure 1 This is a flowchart of a cloud platform inspection method that integrates the MCP protocol and a large language model, as shown in the embodiment.

[0027] Figure 2 This is an overall architecture diagram of the cloud platform inspection system that integrates the MCP protocol and the large language model in this embodiment.

[0028] Figure 3 The above is a timing diagram of the overall implementation of the intelligent inspection method in the embodiment. Detailed Implementation

[0029] In the following description, numerous specific details are set forth in order to provide a more thorough understanding of the invention. However, it will be apparent to those skilled in the art that the invention can be practiced without one or more of these details. In other instances, certain technical features well-known in the art have not been described in order to avoid obscuring the invention.

[0030] Before describing the embodiments, some terms that may appear below will be explained.

[0031] LLM (Large Language Model): This refers to a deep learning model trained on large amounts of text data, possessing powerful natural language understanding, generation, reasoning, and coding capabilities, such as DeepSeek32B mentioned in this solution. Its core is the Transformer architecture, which can process contextual information and generate coherent and relevant text or code.

[0032] MCP (Model Context Protocol): An open standard protocol proposed and promoted by companies such as Anthropic, aiming to standardize the integration and data sharing of AI models (especially LLMs) with external tools, systems, and data sources. It provides a model-agnostic, universal interface that allows AI models to discover tools, acquire data, perform functions, and handle contextual cues.

[0033] MCPServer (Model Context Protocol Server): A service or component conforming to the MCP protocol. It acts as the execution tool for the large language model, encapsulating access to one or more backend systems (such as the automated workflow engine n8n in this solution). The large language model indirectly invokes the functions of these backend systems by sending requests conforming to the MCP specification to the MCPServer.

[0034] n8n is an open-source, visual workflow automation platform that allows users to create automated processes by connecting different applications and services through nodes. In this solution, n8n serves as the automation workflow engine, executing specific cloud platform inspection operations. n8n supports self-hosting and can expose its workflows as tools to LLMs via MCPServer.

[0035] AIOps (Artificial Intelligence for IT Operations): refers to the application of artificial intelligence (AI) and machine learning (ML) to IT operations management (ITOM) to enhance and automate IT operations tasks such as incident correlation, anomaly detection, root cause analysis, and automated remediation.

[0036] NLP (Natural Language Processing): A branch of artificial intelligence that focuses on the interaction between computers and human natural language. This includes the ability to understand, interpret, and generate human language. In this solution, LLM utilizes NLP technology to parse the user's natural language inspection instructions.

[0037] RAG (Retrieval Augmented Generation): A technique that combines retrieval mechanisms with generative models (such as LLM). Before generating a response, the system first retrieves relevant information from an external knowledge base, and then provides this information as context to the LLM to generate more accurate and relevant content.

[0038] K-means clustering is a classic unsupervised learning clustering algorithm designed to divide a dataset into K predefined clusters. The algorithm iteratively assigns data points to the nearest cluster center (centroid) and updates the centroid positions until the centroids no longer change significantly or the maximum number of iterations is reached. The goal is to minimize the sum of squared distances (inertia) from data points within a cluster to their centroids.

[0039] ITSM (IT Service Management): A set of practices and processes to guide the design, delivery, management, and improvement of IT services. Root cause analysis (RCA) is an important component of ITSM.

[0040] Cloud Platform Inspection: refers to the regular or on-demand inspection and audit of cloud infrastructure (such as IaaS, PaaS) in terms of configuration, security, performance, compliance, etc., in order to discover potential risks, configuration errors, performance bottlenecks and security vulnerabilities.

[0041] This invention proposes a cloud platform inspection method that integrates the MCP protocol and a large language model. The main steps are as follows: Figure 1 As shown.

[0042] Step 1: Natural Language Task Instruction Parsing: Users input inspection requirements through natural language. The Large Language Model (LLM) parses the instructions to understand the task intent, inspection scope, and key checkpoints.

[0043] Step 2: Intelligent task orchestration and tool selection based on knowledge base: LLM combines available tools (manifested as automated workflows), inspection strategies, and historical experience stored in the knowledge base to intelligently decompose user tasks into one or more executable workflows and determine the calling parameters.

[0044] Step 3: Execute the automated workflow by calling the MCPServer: The LLM sends execution instructions to the MCPServer through the MCP protocol. The MCPServer, as a standardized interface, calls the privately deployed automated workflow engine (n8n) to execute the orchestrated inspection workflow.

[0045] Step 4: Automated Inspection Execution and Heterogeneous Data Collection: The automated workflow engine executes specific inspection operations, interacts with the cloud platform API, and collects heterogeneous data such as configuration information, performance indicators, logs, and security alarms.

[0046] Step 5: Semantic summary and risk clustering of inspection results: LLM receives raw inspection data and applies an "inspection result semantic summary and risk clustering algorithm" for in-depth analysis. This algorithm includes: Semantic understanding and key information extraction are performed on heterogeneous data to generate human-readable risk summaries.

[0047] Risk features are extracted, and clustering algorithms such as K-means are applied to automatically group risk points and discover potential correlations.

[0048] LLM names and interprets risk clusters. (One of the main inventions: combining the semantic summarization of LLM with risk clustering analysis methods) Step Six: Knowledge Base-Based In-Depth Report Generation and Summary: LLM combines compliance baselines, best practices, and other information from the knowledge base with the analysis results from Step Five to generate an in-depth inspection report that includes risk descriptions, cluster analysis, potential root cause speculation, and remediation suggestions.

[0049] This invention also proposes a cloud platform inspection system, the overall architecture of which is described below. Figure 2 The figure illustrates the main components of the intelligent inspection system of this invention, including a user terminal, a large language model (LLM), an MCPServer, an automated workflow engine (n8n), a knowledge base, and an inspected cloud platform, and shows the main interaction relationships and data flow between them.

[0050] User Interface / CLI: The entry point for users to interact with the system, allowing users to input natural language commands and initiate inspection tasks, as well as receive and view inspection reports.

[0051] Large Language Model (LLM): The intelligent core of the system, responsible for understanding user commands, orchestrating inspection tasks, calling MCPServer to execute tools, analyzing inspection results, and generating reports. A privately deployed LLM (such as DeepSeek 32B) is used to ensure data security. The LLM possesses powerful natural language processing, reasoning, planning, and code generation capabilities.

[0052] MCP Server: Adhering to the Model Context Protocol (MCP), it acts as a standardized bridge between the LLM and the automation workflow engine. The LLM invokes "tools" (i.e., inspection workflows) defined in the workflow engine by sending instructions to the MCP Server. The MCP Server can encapsulate calls to the n8n API, or n8n itself can run as an MCP server via plugin support, exposing its workflows as MCP tools.

[0053] An automated workflow engine, such as a privately deployed n8n, is responsible for executing specific inspection tasks. Inspection tasks are orchestrated into workflows, each consisting of multiple nodes. These nodes can perform operations such as calling cloud platform APIs, executing scripts, data transformation, and sending notifications.

[0054] The inspected cloud platform (CloudPlatform): The target inspection environment, which can be a public cloud (such as Alibaba Cloud, Huawei Cloud, Tencent Cloud), private cloud, or hybrid cloud environment, including various IT resources such as virtual machines, containers, networks, storage, and databases.

[0055] Knowledge base: Stores various types of information that support intelligent decision-making and analysis in LLM, including: 1. Inspection strategies and rule base.

[0056] 2. Compliance baseline and security standards.

[0057] 3. The automation workflow engine provides metadata descriptions (name, function, input and output parameters, etc.) of available workflows (tools) for LLM to select and orchestrate tools.

[0058] 4. Historical inspection data, identified risks and their handling experience.

[0059] 5. Best practices for cloud platform services and configuration. LLM interacts with the knowledge base through Retrieval Enhanced Generation (RAG) technology to obtain the contextual information needed to complete the task.

[0060] See the overall implementation sequence diagram of the intelligent inspection method. Figure 3 As shown in the diagram, this sequence diagram details the complete execution flow of the intelligent inspection method of the present invention. Starting from the user's input of natural language commands, it sequentially shows the key steps and their interaction order, including LLM task parsing and orchestration, calling the workflow engine through MCPServer, the workflow engine executing the inspection, LLM performing result analysis (semantic summarization and risk clustering), and finally generating an inspection report and feeding it back to the user.

[0061] Example 1: Cloud Host Security Configuration Inspection Step 1: Task Initiation and Analysis.

[0062] Execution subject: user, large language model (LLM).

[0063] Triggering condition: The user wants to perform a comprehensive security configuration inspection on all cloud hosts in the production environment.

[0064] Processing Action: Users input a natural language command into the large language model (LLM, such as DeepSeek 32B for private deployment) through the web interface or command-line tool provided by the system. For example: "Please conduct a security configuration inspection of all ECS instances under our production environment Alibaba Cloud account, focusing on checking whether their network security group rules comply with the company's security policy A, whether the operating system patches are updated to the latest version, and whether the associated IAM role permissions follow the principle of least privilege." Upon receiving the instruction, LLM utilizes its powerful Natural Language Processing (NLP) capabilities to perform deep semantic analysis. It identifies the core task as "security configuration inspection," the inspection target as "all ECS instances of the production environment Alibaba Cloud account," and key inspection dimensions as "network security group rules" (which must be compared with "company security policy A"), "operating system patch level" (requires "latest"), and "IAM role permissions" (requires "least privilege principle").

[0065] The result is a structured task description object, which may contain the following fields: {task_type:"security_inspection",target_platform:"alicloud",target_resource:"ecs",scope:"all_production",checks:[{type:"security_group",policy_ref:"company_policy_A"},{type:"os_patch",level:"latest"},{type:"iam_role_privilege",principle:"least_privilege"}]}.

[0066] Use of the results: This structured task description will serve as input for subsequent intelligent task orchestration and tool selection.

[0067] Function: It realizes the transformation from user-friendly natural language input to task definitions that can be accurately understood and executed by machines, greatly reducing the user's barrier to entry.

[0068] Step 2: Intelligent task orchestration and tool selection.

[0069] Executing entity: LLM.

[0070] Triggering condition: Successfully parsing user commands and obtaining a structured task description.

[0071] Processing Action: Based on the structured task description, the LLM begins intelligent task orchestration. It queries an internal or external knowledge base. This knowledge base pre-registers metadata for inspection workflows (as "tools") available in the automated workflow engine (n8n). For example, the knowledge base might contain descriptions of the following workflows: workflow_alicloud_ecs_list: This function "gets a list of ECS instances under a specified Alibaba Cloud account and region". Input parameters are {alicloud_account_id: string, region: string}, and output is instance_list.

[0072] workflow_alicloud_ecs_sg_check: The function "Check the security group configuration of the specified ECS instance", takes the input parameter {instance_id:string,policy_document_url:string}, and outputs sg_compliance_report.

[0073] workflow_alicloud_ecs_patch_check: This function "checks the operating system patch level of a specified ECS instance". The input parameter is {instance_id:string}, and the output is patch_status_report.

[0074] `workflow_alicloud_ecs_iam_check`: This function "analyzes the IAM role permissions associated with a specified ECS instance." The input parameter is `{instance_id:string}`, and the output is `iam_analysis_report`. Based on the inspection objects and checkpoints in the task description, LLM uses reasoning and planning capabilities to determine which workflows need to be invoked, their execution order, and parameters. For example, it might orchestrate the following task sequence: Call workflow_alicloud_ecs_list to retrieve all ECS instance IDs in the production environment.

[0075] For each obtained ECS instance ID, call the following in parallel or serial: The function is called workflow_alicloud_ecs_sg_check, and the instance ID and the path or content of "Company Security Policy A" are passed in.

[0076] For workflow_alicloud_ecs_patch_check, pass in the instance ID.

[0077] `workflow_alicloud_ecs_iam_check` takes the instance ID as input. LLM also translates the specific requirements in the structured task description (such as "latest patch" or "minimum permissions") into parameters that the workflow can understand, or uses them as a basis for subsequent result analysis. The specific implementation process here is as follows: 1. Parameter Mapping and Value Population: The LLM first uses the workflow (tool) metadata stored in the knowledge base to understand the name, type, and format of the parameters required for each workflow. For simple, direct requirements, the LLM performs direct mapping. For example, in the structured task {level:"latest"}, the LLM will look up the parameter list of the workflow_alicloud_ecs_patch_check workflow, find a parameter named patch_level or check_mode, and set its value to "latest".

[0078] 2. Dynamic query and transformation based on knowledge base: For more abstract requirements or those requiring context, LLM will perform a "query-transform" operation.

[0079] 2.1. For "latest patch": The LLM may query external security bulletins integrated into the knowledge base (such as a CVE database or a cloud vendor's security center) to obtain the specific version number or release date (e.g., "security_patch_20250715") of the "latest" security patch package for the specified operating system (e.g., CentOS 7.9) in the current environment. It then passes this specific value as a parameter to the workflow.

[0080] 2.2. Regarding the "Least Privilege Principle": The LLM queries the company's security policies stored in the knowledge base. It finds the corresponding permission policy definition file (e.g., a JSON or YAML policy document) based on the inspection target (e.g., "production web server"). The LLM does not directly pass the phrase "least privilege," but instead passes the policy document's identifier or the URL of its content (e.g., "policy_ref":"s3: / / company-policies / iam / prod-web-server-v1.2.json") as a parameter to the `workflow_alicloud_ecs_iam_check` workflow. This workflow then uses this specific policy file to compare the actual IAM role permissions.

[0081] 3. Calling dedicated transformation functions or services: In more complex scenarios, LLM can call a predefined function or microservice specifically designed to handle particular logic. For example, transforming a vague business term "core financial application" into a list of specific resource IDs might be encapsulated in a separate tool. During orchestration, the LLM would first call this tool and then use its output as input for subsequent inspection workflows.

[0082] Through the above process, LLM accurately transforms high-level, abstract natural language instructions into specific, structured, parameterized instructions that can be executed by the underlying automated workflow.

[0083] The result is a workflow plan to be executed, including the selected sequence of workflow IDs, the input parameters for each workflow (which have been transformed from the user's abstract requirements into concrete, machine-readable values), and possible dependencies and execution logic (such as loops and parallelism).

[0084] Purpose of the result: This plan will be passed to the automation workflow engine for execution via MCPServer.

[0085] Function: It enables the intelligent decomposition and mapping of high-level, abstract user requirements into low-level executable automated operation sequences, demonstrating the planning, reasoning, and dynamic transformation capabilities of LLM through deep integration with knowledge bases. This is a key link in achieving end-to-end intelligence.

[0086] Step 3: Execute the automated workflow by calling MCPServer.

[0087] Execution entities: LLM, MCPServer, Automation Workflow Engine (n8n).

[0088] Triggering condition: The LLM completes the intelligent orchestration of tasks and generates a workflow plan.

[0089] Processing Actions: The LLM constructs requests conforming to the Model Context Protocol (MCP) specification based on the workflow plan. The MCP protocol defines a standardized way for AI models to interact with external tools. The LLM sends one or more execution requests to the MCPServer. Each request typically includes the "tool name" to be invoked (in this scenario, the workflow ID defined in n8n, such as workflow_alicloud_ecs_sg_check) and the parameters required by the tool (such as {instance_id:"i-12345",policy_document_url:"s3: / / bucket / policy_A.json"}). Upon receiving the LLM's request, the MCPServer first performs verification (such as identity authentication and permission checks). Then, based on the tool name and parameters in the request, it communicates with the backend integrated automation workflow engine (n8n). This communication can be achieved through webhook triggers provided by n8n, REST API interfaces, or, if n8n itself is configured as an MCP server, directly via the MCP protocol. The MCPServer translates the invocation instructions into a format that n8n can understand and triggers the execution of the corresponding workflow.

[0090] The result is that the corresponding workflow in n8n is activated and begins execution.

[0091] Purpose of the result: To initiate actual cloud platform inspection operations.

[0092] Function: MCPServer acts as the "arm" of the LLM, translating the LLM's "thinking" into actual "action." Through the standardized MCP protocol, it decouples the LLM from the tight coupling of specific execution tools (n8n workflows), enabling the LLM to interact uniformly with various types of tools, thus enhancing the system's modularity and scalability.

[0093] Step 4: Automated inspection execution and data collection.

[0094] Execution entity: Automated workflow engine (n8n).

[0095] Triggering condition: Receiving a call instruction from MCPServer (or directly from LLM via MCP).

[0096] Processing actions: Taking workflow_alicloud_ecs_sg_check as an example, this n8n workflow may contain the following nodes and logic: 1. TriggerNode: Receives call requests from MCPServer and obtains input parameters (such as instance_id, policy_document_url).

[0097] 2. ALICLOUD SDK Node / HTTP Request Node: Use the ALICLOUD SDK or directly call the ALICLOUD API to query the list of security group IDs associated with the ECS instance based on the instance_id.

[0098] 3. LoopNode: Iterates through each security group ID obtained.

[0099] 4. ALICLOUD SDK Node / HTTP Request Node: For each security group ID, call the API to obtain its detailed inbound and outbound rules, including information such as protocol, port range, source / destination IP or security group.

[0100] 5. Data Fetch Node: If policy_document_url points to an S3 object or other location, then retrieve the contents of that policy file.

[0101] 6. Data Transform / Process Node: Compares the collected security group rules with the company's security policy A (which may be passed in from parameters or obtained from the knowledge base) and marks non-compliant rules.

[0102] 7. Result Aggregation Node: Formats the security group check results (original rules, policy content, compliance flags) of a single instance into JSON or other structured data. Similarly, `workflow_alicloud_ecs_patch_check` calls the API of a system management service (such as ALICLOUD Systems Manager) to obtain the patch compliance status of an instance; `workflow_alicloud_ecs_iam_check` calls the API of the IAM service to obtain the policy documents of the IAM roles associated with the instance, and may perform permission analysis.

[0103] The result is a raw data set containing various security configurations of the target ECS instance (security group rules, patch status, IAM permission details, etc.), usually in JSON or XML format.

[0104] Purpose of the results: This raw data will be returned to LLM via MCPServer for further analysis and summarization.

[0105] Function: It automates and efficiently completes in-depth data collection from cloud platform resources, avoiding the tediousness and error-proneness of manual operation, and ensuring the comprehensiveness and consistency of the data.

[0106] Step 5: Semantic summary of inspection results and application of risk clustering algorithm.

[0107] Executing entity: LLM.

[0108] Triggering condition: Receive the raw inspection data returned by the n8n workflow after execution from the MCPServer.

[0109] Processing Action: LLM initiates the "Inspection Result Semantic Summary and Risk Clustering Algorithm," which includes the following core steps: 1. Semantic Summarization: LLM first performs semantic understanding and information extraction on the received heterogeneous raw data (such as JSON-formatted security group rule lists, text-formatted patch reports, IAM policy documents, etc.). For example, for security group data, LLM can identify that "the security group sg-012345abcdef of instance i-abcdef12345abcdef has opened inbound rules from 0.0.0.0 / 0 to TCP port 22", and understand that this means the SSH port is open to the public network. For large amounts of such information, LLM will summarize and generate a human-readable text summary, such as: "Among the 150 ECS instances inspected in this patrol, 15 instances were found to have their SSH port (22) open to the public network (0.0.0.0 / 0), posing a high risk. Another 5 instances had their RDP port (3389) open to the public network. 25 instances were found to have not updated critical security patches for more than 90 days. The IAM roles associated with 3 instances included iam: CreateUser and s3: The "equal access" strategy violates the principle of least privilege. This ability to summarize goes beyond simple statistics; it grasps the essence of risk and expresses it in natural language.

[0110] 2. Feature Engineering for Clustering: To perform risk clustering, LLM (or auxiliary scripts) needs to extract structured risk features from the raw data or semantic summary. These features may include: 2.1. risk_id: A unique risk identifier.

[0111] 2.2, resource_id: The ID of the affected resource (e.g., i-abcdef1234567890).

[0112] 2.3, risk_type: Risk type (e.g., 'open_ssh_port_public', 'critical_patch_missing', 'overly_permissive_iam_role', 'unrestricted_s3_bucket_access'). LLM can classify risks according to its understanding.

[0113] 2.4. Severity_level: Risk severity level (e.g., 'critical', 'high', 'medium', 'low'). This can be determined by the LLM based on risk definitions in the knowledge base (e.g., CIS scores) or built-in logic, or it can be initially marked by the n8n workflow during data collection.

[0114] 2.5. affected_component: Affected components (such as 'network_security_group', 'operating_system', 'iam_policy').

[0115] 2.6 Vulnerability_CVE (optional): If it is related to a patch, it may have a CVE number.

[0116] 2.7 Business_impact_tag (optional): Business impact information extracted from resource tags (e.g., 'production_database', 'development_webserver'). These features need to be converted into numerical vectors (e.g., through one-hot encoding, word embedding, etc.) before they can be used in clustering algorithms.

[0117] 3. Risk Clustering: Using all identified risk points (vectorized) as input, an unsupervised clustering algorithm, such as K-means, is applied. Before applying K-means, it may be necessary to determine an appropriate number of clusters K (e.g., through silhouette coefficients, elbow rule, or preset by an experienced administrator). The K-means algorithm divides risk points into K clusters based on the similarity between risk feature vectors (e.g., Euclidean distance). For example, the following risk clusters might be formed: Cluster 1: "High-risk management ports exposed to the public network" (including the risk of all SSH, RDP, database ports, etc. being open to 0.0.0.0 / 0).

[0118] Cluster 2: "Critical system component patches missing" (including the risk of known high-risk vulnerabilities remaining unpatched in all operating systems, databases, middleware, etc.).

[0119] Cluster 3: "Improper identity and access permission configuration" (including excessive permissions for all IAM users / roles, failure to use MFA, risk of AccessKey leakage, etc.).

[0120] Cluster 4: "Weak data storage security configuration" (including risks such as public access to S3 buckets and unencrypted databases).

[0121] Cluster naming and explanation: LLM analyzes the common characteristics of risk points within each cluster and generates a concise and meaningful name (as in the example above) and a descriptive text for each cluster, explaining the common risk problem represented by the cluster.

[0122] The semantic summary and risk clustering algorithm process for inspection results includes data preprocessing, an LLM-driven semantic summary module, a risk feature extraction module, feature vectorization, application of clustering algorithms such as K-Means for risk clustering, and the steps of interpreting and summarizing the clustering results.

[0123] The result is a structured analysis of the risk data, which includes a natural language risk summary, detailed information on each risk point, and risk clustering results (the cluster to which each risk point belongs, the cluster's label, and a description).

[0124] Purpose of the result: It serves as the core input for generating the final in-depth inspection report.

[0125] Function: This algorithm is one of the core innovations of this invention. It combines the powerful semantic understanding capabilities of LLM with mature clustering algorithms, enabling users to quickly understand inspection findings and revealing systemic problems and patterns behind isolated risk points, providing insights far exceeding traditional list-based reports. For example, clustering may reveal a large number of "high-risk port exposures in development environment resources," potentially indicating a lack of security awareness or automated checks in the development process.

[0126] Step 6: Generate in-depth reports based on the knowledge base.

[0127] Executing entity: LLM.

[0128] Triggering condition: Complete the semantic summary and risk clustering analysis of the inspection results.

[0129] Processing Action: The LLM synthesizes the analysis results from the previous step and queries the knowledge base again to obtain richer contextual information to enrich the report content. The knowledge base may provide the following at this point: Potential business impact of risks: Based on historical data or predefined rules, assess the potential business disruption or data breach impact of a certain type of risk (such as exposure of a production database port).

[0130] Detailed remediation recommendations and best practices: For specific types of risks (such as "SSH public network exposure"), standard remediation steps are provided (such as "configuring bastion host access", "restricting source IP addresses", "using key authentication and disabling password login").

[0131] Similar Historical Events and Solutions: If the knowledge base contains records, similar past risk events and their successful handling methods can be referenced. LLM leverages its powerful text generation capabilities to organize all this information into a well-structured, detailed, and visually appealing in-depth inspection report. The report typically includes the following sections: Inspection Overview: This includes the scope, timing, and execution strategies of the inspection.

[0132] Overall risk posture assessment: A summary evaluation of the overall security situation, which may include a risk score or rating.

[0133] Key findings (semantic summary): A concise description of the most important risk findings.

[0134] Risk clustering analysis: Display the distribution and proportion of different risk clusters using charts (such as pie charts and bar charts), and list in detail the specific risk items, affected resources, severity levels, etc. under each cluster.

[0135] High-risk item details: In-depth analysis of identified high-risk or important risk clusters, which may include preliminary speculation on their causes.

[0136] Remediation Recommendations and Priorities: For each risk or risk cluster, specific and actionable remediation recommendations are provided, and remediation priorities are given based on the severity and potential impact of the risk.

[0137] Compliance Comparison (Optional): Compares inspection results with specific compliance standards (such as PCI DSS, HIPAA, ISO27001, or internal policies) and identifies non-compliance items. Reports can be generated in various formats such as PDF and HTML.

[0138] The result is a complete, in-depth inspection report that can be used by management and the operations team.

[0139] Use of results: To serve as a basis for decision-making and to guide the operations and maintenance team in risk remediation and security hardening.

[0140] Function: Provides inspection outputs with in-depth analysis and actionable suggestions that far exceed those of traditional inspection tools, helping enterprises effectively manage and reduce cloud platform risks.

[0141] The technical effects of the cloud host security configuration inspection in the above embodiment 1 are as follows: 1. Significantly improves the convenience of human-computer interaction and the flexibility of task definition: Users can directly express complex and customized inspection needs using natural language (such as "Check all ECS instances tagged 'production' and running UnionTech 2.0, ensuring their SSH ports are not open to the public network and that no high-risk CVE patches have been left unpatched in the past 30 days"). The LLM's understanding and parsing capabilities enable the system to accurately capture user intent, far exceeding the configuration methods of traditional inspection tools based on forms or fixed rules. (Corresponding to steps one and two) 2. Achieving Standardized and Scalable Tool Integration and Invocation: By introducing MCPServer as middleware between the LLM and the n8n workflow engine, and adhering to the MCP protocol, unified and standardized invocation of external tools (manifested as n8n workflows) by the LLM is achieved. This means that new inspection workflows can be easily created in n8n (e.g., for new cloud services or new inspection logic). Simply register their metadata in the knowledge base, and the LLM can discover and use these new "tools" without modifying the core code of the LLM itself or MCPServer. This solves the problem of complex tool integration and poor scalability in traditional systems (the N×M integration dilemma). (Corresponding to step three) 3. Deeply Automated and Intelligent Data Acquisition and Preliminary Processing: The n8n workflow engine can automate complex, multi-step data acquisition tasks, including calling various cloud APIs, executing remote commands, and parsing data in different formats. The workflow can also include preliminary data cleaning, formatting, and filtering logic to provide higher-quality data input for subsequent LLM analysis. (Corresponding to step four) 4. Revolutionary inspection result analysis and insight capabilities: 4.1 Semantic Summary: LLM can transform large amounts of heterogeneous, raw inspection data (such as JSON configurations, log text, and API responses) into concise and easy-to-understand natural language summaries. For example, it can summarize "X high-risk public network exposed ports exist" from a set of security group rules, rather than simply listing the rules. This greatly improves the efficiency of operations and maintenance personnel in understanding inspection results.

[0142] Risk Clustering: By clustering risk features extracted from data using algorithms such as K-means, the inherent connections and common patterns between different independent risk points can be automatically discovered. For example, "multiple instances of SSH ports open to the public network" and "multiple instances of database ports open to the public network" might both be grouped into the risk cluster of "unrestricted access to critical management services." This clustering analysis helps to grasp the risk situation at a macro level and identify systemic and regional weaknesses, which is incomparable to the simple listing of problems in traditional inspection reports. LLM can also help explain the meaning of these clusters, making them easier to understand. (Corresponding to Step 5) Generate highly actionable, context-aware, and in-depth reports: LLM combines compliance standards, best practices, and historical experience from a knowledge base with current analysis results (semantic summaries and risk clustering). The resulting reports not only describe the problem but also provide targeted remediation recommendations, potential impact analyses, and prioritization. The quality and depth of these reports far surpass those generated by traditional templates, and they are more effectively able to guide actual risk management efforts. (Corresponding to Step Six) Ensuring data security and privacy: By adopting privately deployed LLM (such as DeepSeek 32B) and the n8n workflow engine, we ensure that all sensitive cloud platform configuration information, inspection data, and analysis results are processed in a controllable environment within the enterprise, effectively avoiding the security risks and compliance issues that may arise from transmitting core data to external public cloud LLM services.

[0143] Example 2: Intelligent Inspection Based on Performance Monitoring and Anomaly-Driven Processes This embodiment focuses on combining intelligent inspection capabilities with a real-time performance monitoring system to automatically trigger a targeted, context-aware intelligent inspection when cloud resources of critical business applications exhibit performance anomalies (e.g., a sharp increase in application response latency, a significant increase in error rate, or persistently high CPU or memory utilization). This allows for the rapid collection of diagnostic information and assistance in root cause analysis.

[0144] The difference from Example 1 is as follows: Differences in task triggering methods: Example 1: The inspection task is mainly initiated manually by the user through natural language commands.

[0145] Example 2: The inspection task is mainly triggered automatically by an external monitoring system (such as Prometheus, Datadog, Zabbix, or the monitoring workflow built by n8n itself). When the monitoring system detects that a predefined performance indicator threshold has been exceeded or an abnormal pattern has occurred, it will call the intelligent inspection system of this invention via API (specifically, it may directly call a specific API endpoint of LLM, or call a preset MCPServer tool interface specifically used to receive abnormal events). This API call will carry key abnormal context information, such as: "The service 'Order Processing API' detected a P95 response latency of 2500ms at timestamp '2024-08-15T10:30:00Z', exceeding the threshold of 800ms for 5 minutes. Affected instances include instance-A and instance-B."

[0146] The dynamism and targeted nature of task orchestration: Example 1: LLM is arranged according to the user's general inspection needs.

[0147] Example 2: After receiving specific anomaly event information, the LLM's task orchestration becomes more dynamic and targeted. The LLM first understands the type of anomaly (e.g., high CPU usage, memory leaks, network latency, increased application errors) and its context (which service, which instances, and specific metrics). Then, the LLM queries the knowledge base for fault diagnosis trees, historical experience, or preset diagnostic strategies related to this type of anomaly. Based on this information, the LLM dynamically orchestrates a series of highly relevant inspection workflows. For example, for the anomaly of "high CPU usage," the LLM might orchestrate the following sequence: Call the workflow to obtain a detailed list of cloud hosts / containers associated with the abnormal service.

[0148] For these hosts / containers, the workflow is invoked to check real-time system metrics such as CPU, memory, disk I / O, and network traffic, and to capture a list of processes with the highest CPU usage.

[0149] The workflow is invoked to retrieve application logs, middleware logs, and system logs related to the time before and after the abnormal event.

[0150] Invoke the workflow to check for recent deployment activities, configuration changes, or known events.

[0151] The workflow is invoked to check the health status of dependent services. This dynamic orchestration ensures that inspection operations are closely focused on the current anomaly, avoiding unnecessary large-scale scans and improving diagnostic efficiency.

[0152] In-depth application of knowledge base in root cause analysis: Example 1: The knowledge base is mainly used for compliance baselines, tool metadata, etc.

[0153] Example 2: The knowledge base plays a more important role in assisting LLM in root cause analysis. In addition to storing tool information, the knowledge base also contains detailed records of similar historical anomalies (phenomena, inspection data, root causes, solutions), a known failure mode library, component dependency graphs, etc. When analyzing collected inspection data, the LLM uses RAG technology to retrieve this information from the knowledge base to help infer the most likely root cause. For example, if current CPU usage is high and logs show a large number of database connection timeouts, and the knowledge base records past instances where database performance bottlenecks caused similar applications to experience high CPU usage, the LLM may list the database problem as a highly suspected root cause.

[0154] Differences in focus between inspection reports: Example 1: The report focuses on comprehensive configuration compliance and potential risks.

[0155] Example 2: The core of the report is to focus on the current performance anomaly, highlighting the inspection findings related to the anomaly, data correlation analysis, speculation on multiple potential root causes and their confidence ranking, as well as short-term recommendations aimed at quickly restoring service and long-term recommendations aimed at eradicating the problem.

[0156] The steps in this embodiment 2 are as follows: 1. Anomaly Detection and Event Triggering: When an external monitoring system (such as Alibaba Cloud Alarm System or Prometheus Alertmanager) detects anomalies in key performance indicators (e.g., P95 latency > 1 second for 5 minutes), the monitoring system sends an event notification containing detailed context (service name, indicator name, current value, threshold, timestamp, affected resource ID, etc.) to the designated API interface of this intelligent inspection system through pre-configured actions (e.g., calling a Webhook, sending an SNS message and then being triggered by Lambda).

[0157] 2. LLM understands the exception context and dynamically orchestrates tasks: LLM receives and parses the exception event. It queries the knowledge base to retrieve diagnostic templates, historical cases, and known issues related to this exception type (such as "high API latency") and related services (such as "user authentication service"). Based on this, LLM dynamically generates one or more targeted inspection workflow call plans, such as: (1) checking the CPU / memory / network status of all instances of "user authentication service"; (2) collecting application logs and Nginx access logs of these instances; (3) checking the performance metrics and connection counts of its dependent databases (such as Redis cache, PostgreSQL master database); (4) querying whether there are any recent deployment or configuration change records for "user authentication service" or its dependencies.

[0158] 3. Automated workflows are invoked and executed via MCPServer: The LLM sends the orchestrated workflow invocation instructions (including workflow IDs and specific parameters, such as a list of instance IDs and log time ranges) to the MCPServer via the MCP protocol. The MCPServer then invokes n8n to execute these workflows.

[0159] 4. Targeted data collection: Each workflow in n8n is executed concurrently or sequentially, collecting diagnostic data highly relevant to the current anomaly from the cloud platform, log system, configuration management database (CMDB), etc.

[0160] 5. LLM Data Analysis and Root Cause Inference: Collected data (such as a list of processes with high CPU usage, error stack traces in logs, slow query logs, configuration change diffs, etc.) is returned to the LLM. The LLM performs semantic summarization and correlation analysis on this heterogeneous data. For example, it might find that "the Java process of instance A has 95% CPU usage, application logs show a large number of database connection pool exhaustion errors, database monitoring shows that the number of connections has reached the limit, and the slow query log shows that multiple queries from instance A have taken more than 5 seconds." Combining this with information from the knowledge base (such as "improper database connection pool configuration may cause application CPU spikes under high concurrency"), the LLM will infer several possible root causes and rank them by probability, such as: 1. Database performance bottlenecks cause application thread blocking and increased CPU; 2. Code defects in the application itself cause resources not to be released; 3. Problems introduced by recent configuration changes.

[0161] 6. Generate Incident Analysis and Decision Support Report: LLM generates an incident analysis report, including: a description of the anomaly, a summary of key inspection data, a timeline analysis, multiple potential root causes and their evidence, a confidence assessment, and recommended further investigation steps or temporary mitigation measures (such as "Recommend temporarily scaling up the database instance" or "Roll back the most recent XX change"). This report can be automatically pushed to the alarm handling platform, create an ITSM work order, or notify relevant operations and maintenance teams via instant messaging tools.

[0162] The technical effects of the intelligent inspection system for performance monitoring and anomaly-driven operation in Embodiment 2 above are as follows: Achieve proactive, event-driven intelligent inspection: Transform intelligent inspection from the traditional periodic execution or manual triggering mode to automatic triggering by performance anomalies detected by the real-time monitoring system. This proactive response mechanism makes inspections more timely, enabling intervention in the early stages of problems and collection of first-hand on-site data.

[0163] Context-aware and highly targeted dynamic orchestration: LLM understands the context of triggering events (such as which service, which metric is abnormal, the degree of abnormality, and the duration), and dynamically and intelligently orchestrates a series of highly relevant diagnostic inspection workflows based on this. This is more flexible and efficient than fixed, generic troubleshooting scripts, and can directly address the crux of the problem, avoiding unnecessary information interference.

[0164] Significantly accelerates fault diagnosis and mean time to resolve (MTTR): Through automated, targeted, in-depth information collection (such as relevant logs, metric snapshots, and configuration changes) and rapid preliminary analysis and root cause inference by LLM, the time required for fault location and diagnosis can be significantly reduced, thereby accelerating fault recovery, reducing MTTR, and improving service availability and user satisfaction.

[0165] Promote the accumulation, sharing, and continuous improvement of operational knowledge: The process of each anomaly-driven inspection, the collected data, the LLM analysis results, and the finally identified root causes and solutions can all be structured and recorded in a knowledge base. This experiential data can be used to continuously optimize the LLM's fault diagnosis model and task orchestration strategy, forming a closed loop of learning and improvement, making the system increasingly intelligent and efficient in handling similar problems.

[0166] Reduce the workload of the operations and maintenance team and improve operational efficiency: It automates a large number of repetitive data collection and preliminary analysis tasks that were previously performed manually in the early stages of troubleshooting, allowing operations and maintenance engineers to focus more on complex judgments, decisions and repair execution, thereby improving overall IT operational efficiency.

[0167] The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments have been described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification. Although the present invention has been shown and described with reference to specific preferred embodiments, it should not be construed as limiting the invention itself. Various changes in form and detail may be made without departing from the spirit and scope of the invention as defined in the appended claims.

Claims

1. A cloud platform inspection method integrating MCP protocol and large language model, characterized in that, Includes the following steps: Step 1: The user inputs the inspection requirements in natural language. The large language model parses the natural language inspection requirements, identifies the task intent, inspection scope and key checkpoints, and generates a structured task description. Step 2: The large language model queries the knowledge base to obtain metadata, inspection strategies and historical experience of available inspection workflows. Based on the structured task description generated in Step 1, the user task is decomposed into an executable workflow sequence and the calling parameters of each workflow are determined. Step 3: The large language model constructs an execution request according to the workflow sequence and call parameters of each workflow determined in Step 2, in accordance with the MCP protocol specification, and sends the execution request to the MCP server. After verifying the execution request, the MCP server converts it into a format recognizable by the automated workflow engine and triggers the execution of the corresponding inspection workflow. Step 4: The automated workflow engine executes the inspection workflow triggered in step 3, and collects cloud platform data by calling the cloud platform API to form heterogeneous data; Step 5: The large language model receives the heterogeneous data collected in step 4, performs semantic understanding and key information extraction on the heterogeneous data, and generates a natural language risk summary. Risk features are extracted and vectorized, and clustering algorithms are applied to group risk points into risk clusters. The large language model generates names and descriptions for each risk cluster. Step 6: The large language model queries the knowledge base to obtain compliance baselines and best practices, and integrates them with the natural language risk summary, risk cluster names and descriptions generated in Step 5 to form an inspection report.

2. The cloud platform inspection method according to claim 1, characterized in that, The knowledge base stores inspection strategies, compliance baselines, workflow metadata, historical inspection data, and best practices; the large language model queries the knowledge base through retrieval-enhanced generation technology to obtain the information needed to complete intelligent task orchestration and in-depth report generation.

3. The cloud platform inspection method according to claim 1, characterized in that, In step 1, the structured task description includes task type, target platform, target resources, inspection scope and inspection dimension information, and the inspection dimension is associated with the corresponding compliance standards or policy requirements.

4. The cloud platform inspection method according to claim 1, characterized in that, In step 2, the intelligent task orchestration of the large language model includes parameter mapping and value filling, dynamic query and transformation based on the knowledge base, or calling a dedicated transformation function to transform the user's abstract requirements into specific call parameters that can be executed in the workflow.

5. The cloud platform inspection method according to claim 1, characterized in that, The automated workflow engine is deployed privately; in step 3, the MCP server, as the implementation carrier of the MCP protocol, encapsulates the access capability to the automated workflow engine and realizes the standardized interaction between the large language model and the automated workflow engine.

6. The cloud platform inspection method according to claim 1, characterized in that, In step 4, the cloud platform data includes configuration information, performance indicators, logs, and security alarms; the inspection workflow consists of trigger nodes, API call nodes, loop nodes, data processing nodes, and result aggregation nodes. Each node works together to complete cloud platform data collection, data format conversion, and data compliance comparison, ultimately forming heterogeneous data.

7. The cloud platform inspection method according to claim 1, characterized in that, In step 5, the clustering algorithm is the K-means clustering algorithm; the risk features include risk type, severity level, affected resource ID, affected components, optional CVE number and business impact label, and the risk features are converted into numerical vectors through one-hot encoding or word embedding technology; the risk features are extracted from the heterogeneous data or natural language risk summary.

8. The cloud platform inspection method according to claim 1, characterized in that, The inspection report includes risk description, cluster analysis, potential root cause prediction, and remediation suggestions. The inspection method is triggered either manually by the user through natural language or automatically by the external monitoring system after detecting performance anomalies. When the external monitoring system detects an anomaly, it sends an event notification containing the anomaly type, affected resources, and timestamp to the large language model. The large language model parses the event notification, replacing the natural language inspection requirement parsing process in step 1, and generates a corresponding structured task description before executing steps 2 to 6.

9. A cloud platform inspection system integrating the MCP protocol and a large language model, characterized in that, include: The interaction module is used to receive natural language inspection requests input by users or to receive event notifications sent by external monitoring systems and output inspection reports to users. The large language model is used to parse the natural language inspection requirements or event notifications received by the interaction module to generate a structured task description, query the knowledge base and intelligently orchestrate the structured task description based on the knowledge base information to determine the workflow sequence and call parameters, receive heterogeneous data and perform semantic summarization and risk clustering to generate a natural language risk summary and risk cluster names and descriptions, and integrate the knowledge base information to form an inspection report. The MCP server, following the MCP protocol, is used to receive execution requests sent by the large language model, verify the execution requests, and forward them to the automated workflow engine, thereby realizing standardized interaction between the large language model and the automated workflow engine; the execution requests are constructed by the large language model based on the workflow sequence and calling parameters. The automated workflow engine receives requests forwarded by the MCP server and executes the corresponding inspection workflow. It collects cloud platform data by calling the cloud platform API, forms heterogeneous data, and feeds it back to the large language model. A knowledge base is used to store relevant information that assists large language models in completing tasks, providing data support for large language models.

10. The cloud platform inspection system according to claim 9, characterized in that, The large language model is deployed privately and has the capabilities of natural language processing, reasoning, task orchestration, and text generation. The knowledge base stores relevant information including inspection strategies, compliance baselines, workflow metadata, historical inspection data, fault modes, and remediation suggestions. The large language model obtains data support from the knowledge base through retrieval-enhanced generation technology. The automated workflow engine is deployed privately; the cloud platform data includes configuration information, performance metrics, logs, and security alerts; the event notification includes the exception type, affected resources, and timestamp, and is sent to the interaction module by an external monitoring system via Webhook or API call when the cloud platform performance metrics exceed a preset threshold.

Images