A command control decision service integration architecture and method based on MCP protocol

Abstract

This invention presents an integrated architecture and method for command and control decision-making services based on the MCP protocol. It standardizes and encapsulates command and decision-making functional modules into independent MCP services according to the MCP protocol, achieving unified input / output formats and communication standards. Service registration, version management, load balancing, and unified scheduling are achieved through an API gateway. A visual workflow orchestration platform is provided, supporting drag-and-drop node configuration and automatic parameter mapping. Cross-language communication is achieved using the Stdio transport layer, eliminating the need to expose network ports and enhancing security. Each MCP service can be deployed independently, hot-updated, and elastically scaled, significantly reducing system coupling. This invention achieves "plug-and-play" integration of command and decision-making services, enabling rapid access and unified invocation of multi-source functional modules, greatly improving the flexibility and maintainability of the command and decision-making system. It is applicable to command and control scenarios such as command and decision-making, emergency dispatch, and situational awareness, providing core technical support for building a scalable and collaborative intelligent command and decision-making application ecosystem.

Description

Technical Field

[0001] This invention belongs to the field of intelligent decision-making and microservice architecture technology, and relates to a service integration system for multi-module collaboration, especially a command and control decision service integration architecture and method based on the MCP (Model Context Protocol). Background Technology

[0002] With the rapid development of intelligent command and control scenarios such as command and decision-making, emergency dispatch, and situational awareness, command and decision-making systems are constantly facing challenges in practical applications, including diversified data sources, complex business logic, and highly dynamic environmental requirements. Current complex command and decision-making systems typically consist of multiple functional modules, including information collection and fusion, object identification and monitoring, risk assessment, solution generation, command planning, real-time situational simulation, and decision recommendation. These modules are often independently built by different teams using different development languages, frameworks, and deployment methods, lacking a unified interface standard and communication protocol.

[0003] The current mainstream solution is to adopt a microservice architecture, integrating services through HTTP / RESTful APIs or RPC frameworks. However, in the specific high-security domain of command and control, existing technologies have significant shortcomings:

[0004] Insufficient security: Traditional microservice architectures require services to open network ports (such as HTTP ports 80 / 8080) to listen for requests, which increases the risk of the system being exposed to network attacks and makes it difficult to meet high-level security isolation requirements.

[0005] Rigid protocols: REST or RPC protocols are usually tied to specific network stacks. For the interaction between Python-based AI model services and C++-based underlying computing services, cumbersome serialization and deserialization processing is often required, and there is a lack of a unified standard for passing context.

[0006] The black box problem in decision-making: Existing integration architectures focus more on the connectivity of function calls and lack standardized integration solutions for AI model decision-making processes (such as SHAP interpretation), making it difficult for commanders to understand the basis of decisions and reducing the credibility of the system.

[0007] In the context of multi-source information fusion, rapid iteration of decision-making models, and instantaneous changes in scenario situations, there is an urgent need for a new command and decision-making service architecture that features unified service standards, loose coupling, high scalability, security, reliability, and support for visual workflow orchestration. MCP (Model Context Protocol), as a unified protocol system that has emerged in recent years and is cross-language and cross-framework, possesses natural advantages in tool encapsulation, model invocation, and context interaction. However, there is currently a lack of systematic architectural design and engineering implementation methods for integrating MCP into command and control decision-making systems.

[0008] Against this backdrop, this invention proposes an MCP decision service integration architecture for command and control. By encapsulating the command and decision module with MCP, building a unified scheduling and workflow platform, adopting the Stdio transport layer mechanism, and introducing a microservice construction approach, it aims to solve key problems in existing command and control systems such as inconsistent interfaces, high module coupling, inflexible workflow orchestration, and insufficient security isolation, thereby meeting the stringent technical requirements of modern command and control scenarios for real-time performance, collaboration, and security. Summary of the Invention

[0009] The purpose of this invention is to provide an integrated architecture and method for command and control decision services based on the MCP protocol, which solves the problems of inconsistent interfaces, high system coupling, rigid workflow orchestration, low communication security, uninterpretable decision results, and interrupted system iteration in existing command and control systems. It realizes "plug-and-play" integration of command and decision services, and improves the flexibility, maintainability, security, continuity and decision credibility of the command and decision system.

[0010] To achieve the above objectives, the technical solution of the present invention is as follows:

[0011] An integrated architecture for command and control decision-making services based on the MCP protocol is characterized by comprising a hierarchically coordinated MCP service encapsulation layer, a communication transmission layer, an API gateway layer, a workflow orchestration layer, and an operation monitoring layer. Each layer works together to achieve standardized, pluggable integration of command and control decision-making service modules and visualized workflow orchestration in a closed network environment.

[0012] The MCP service encapsulation layer is used to encapsulate functional modules such as unified coding service, geographic verification service, rule calculation service, model reasoning service, and interpretive calculation service in the command and control decision system according to the MCP protocol specification, forming an independent MCP service with unified input parameter format, output format, and communication convention.

[0013] The communication transport layer, based on the Stdio channel of the MCP protocol, is used to achieve standardized communication between the API gateway and various MCP services across languages ​​and platforms without exposing network ports.

[0014] The API gateway layer is used to register, authenticate, manage versions, schedule routes, and load balance the MCP services, enabling unified access and centralized management of multiple MCP services.

[0015] The workflow orchestration layer is used to configure processes, map node parameters, define execution links, and manage workflow versions for multiple MCP services based on a visual interface, enabling flexible construction and dynamic updates of decision-making processes.

[0016] The operation monitoring layer is used to monitor and record the running status, call time, abnormal situations and workflow execution of the MCP service, and realize service health checks, abnormal retries and call chain tracing.

[0017] Furthermore, the services in the MCP service encapsulation layer all include an MCP input parameter validation unit, which performs format validation, type validation, and field integrity validation on input parameters based on JSON Schema or equivalent constraints, and returns standardized error information when validation fails. The heterogeneous functional modules encapsulated in the MCP service encapsulation layer include an interpretable reasoning service, which calculates the importance of model input features based on the SHAP interpretable algorithm and returns an interpretable data structure to provide interpretability support in the decision-making process. Multiple MCP services are deployed in a containerized manner and support elastic scaling based on resource load to adapt to different business throughput requirements.

[0018] Furthermore, the communication transport layer implements data transmission based on Stdio, enabling the MCP service to complete bidirectional communication with the API gateway without opening external network ports, thereby improving communication security and deployment flexibility.

[0019] Furthermore, the API gateway layer includes a service registration module, used to write the service name, version number, operating environment, capability tags, communication method, and health check interface of the MCP service into the service directory; the API gateway layer includes a version management module, used to support version switching, canary release, rollback management, and parallel operation of multiple versions of the MCP service; the API gateway layer also includes an exception management module, used to capture input errors, execution errors, and timeout errors of the MCP service, and trigger retries, circuit breakers, or alternative service calls according to business policies.

[0020] Furthermore, the workflow orchestration layer includes a visual process configuration interface for creating process nodes, setting parameter mapping relationships, defining execution order, and configuring logical branches based on drag-and-drop. The workflow orchestration layer is used to automatically map the output results of the previous node to the input parameters of the next node during workflow execution, forming a multi-node chained call relationship. The workflow orchestration layer supports version management of user-edited process structures, node parameters, and input / output mapping relationships to support process history backtracking and quick switching.

[0021] Furthermore, the operation monitoring layer includes a call chain tracing module, which is used to record the service call chain, execution time, and the results or error information returned by the nodes.

[0022] A method for an integrated architecture of command and control decision services based on the MCP protocol, characterized by the following steps:

[0023] S1: MCP Service Encapsulation: Organize the command and decision-making function modules, encapsulate them into independent MCP services according to the MCP protocol specification, configure unified metadata information and input parameter verification rules, integrate interpretive reasoning services, and complete Docker / K8s containerized deployment;

[0024] S2: Service Registration: After each independent MCP service starts, it submits registration information to the API gateway layer, completes the service catalog entry and health check interface configuration, and the API gateway layer starts a scheduled health check.

[0025] S3: Communication Configuration: Establish a bidirectional communication link between each MCP service and the API gateway layer based on the Stdio channel, and close all external network ports of the MCP service;

[0026] S4: Workflow Orchestration: Configure MCP service nodes through a visual drag-and-drop interface, define execution links, logical branches and parameter mapping rules, and save the configured workflow in a versioned manner;

[0027] S5: Service Scheduling: After receiving a business request, the API gateway layer loads the corresponding workflow configuration, executes the routing scheduling, load balancing and version management of the MCP service according to the scheduling policy, and triggers retry, circuit breaking or alternative service calls in abnormal scenarios.

[0028] S6: End-to-end monitoring: The operation monitoring layer monitors the MCP service's running status and workflow execution process in real time, records call link data, resource load indicators, and service call indicators, and alerts and automatically handles abnormal situations.

[0029] S7: Service Iteration: Based on the module-level hot replacement mechanism, the MCP service is upgraded or rolled back to achieve uninterrupted system iteration.

[0030] Furthermore, the MCP service encapsulation described in step S1 specifically includes: encapsulating the original functional logic into an independent process, using the stdin / stdout interface specified by MCP to process requests, verifying the input data format according to the MCP Schema, and encapsulating the service running results into a data structure that conforms to the MCP response format and outputting it to the standard output stream.

[0031] Furthermore, the parameter mapping rule configuration in step S4 includes two methods: automatic mapping and manual adjustment. Automatic mapping completes precise field matching based on the node's input and output schema, while manual adjustment supports user-defined field mapping relationships, type conversion rules, and default value configurations.

[0032] Furthermore, the module-level hot replacement mentioned in step S7 specifically includes: the new version of the MCP service is launched in parallel with the old version and the service registration is completed; the API gateway layer distributes traffic according to a preset ratio; the operation monitoring layer verifies the stability of the new version in real time; after the verification is passed, the distribution ratio is gradually increased to full switch; if an anomaly occurs, the traffic is immediately switched back to the old version to achieve a fast rollback.

[0033] The beneficial effects of this invention are:

[0034] 1. Standardized encapsulation of command and decision-making services is achieved, resolving the issue of inconsistent module interfaces: This invention unifies service input / output formats and communication standards through the MCP protocol, achieving standardized interaction across languages ​​and frameworks. After each command function module is encapsulated according to the MCP specification, the input parameter verification unit automatically verifies the data format based on JSON Schema, reducing integration and adaptation code, shortening the integration cycle, lowering the incidence of compatibility issues, improving the efficiency of command system construction, and meeting the real-time requirements for rapid fusion of multi-source information.

[0035] 2. Reduced System Coupling: Employing a microservices design and standardized MCP service encapsulation allows command and decision-making modules to be developed, deployed, tested, and upgraded independently. Modules communicate loosely via an API gateway, eliminating direct dependencies and significantly reducing system coupling. New features can be quickly integrated, and the failure of a single module will not lead to system-wide crashes, ensuring system stability and task continuity in complex and dynamic environments.

[0036] 3. Enhance the flexibility of decision-making workflows: Provide a visual command workflow orchestration platform, enabling drag-and-drop node configuration, dynamic link adjustment, and multi-logical branch management. During workflow execution, parameter mapping and type conversion are automatically completed, supporting complex logic such as parallel execution and conditional triggering. Decision-making processes can be quickly adjusted, and relevant personnel can participate in process design, significantly improving situational response speed and decision-making adaptability.

[0037] 4. Unified Communication and Security Management: Adopting a Stdio-based unified communication mechanism combined with centralized access control via an API gateway, all service communications are standardized. The gateway provides unified security policy enforcement, call chain tracing, and anomaly management, effectively shortening security incident response time. Stdio channels do not expose network ports, providing natural isolation between services, making them particularly suitable for command and control environments with high security requirements, effectively mitigating the risks of network attacks and information leakage.

[0038] 5. Implement standardized lifecycle management: Introduce a module-level hot-swap mechanism and version management module to support parallel operation of new and old modules, proportional distribution, replacement after verification of stability, and rapid rollback in case of anomalies. The API gateway enables unified scheduling of canary releases and version switching, allowing the system to complete upgrades without downtime, ensuring that decision-making capabilities are not interrupted due to system upgrades, and meeting the stringent requirements of command and control for system continuity.

[0039] 6. Achieve intelligent monitoring and management across the entire chain to improve system maintainability: The operation monitoring layer performs full-chain tracking of service operation and workflow execution, records call data, resource load indicators and service call indicators, generates a visualized call chain graph and monitoring reports, supports abnormal threshold alarms and automatic processing, facilitates operation and maintenance personnel to quickly locate and solve problems, and improves system maintainability and problem-solving efficiency.

[0040] This invention constructs a highly standardized, modular, and visualized command and decision-making service integration architecture, enabling the command and control system to possess the technical characteristics of flexible expansion, rapid iteration, and security and reliability. It provides core technical support for building a scalable and collaborative intelligent command and decision-making application ecosystem, and significantly improves command efficiency and decision-making quality in complex environments.

[0041] The present invention will be further explained in detail below with reference to the accompanying drawings and specific embodiments. Attached Figure Description

[0042] Figure 1 This is a schematic diagram of the overall hierarchical structure of the MCP protocol decision service integration architecture of the present invention;

[0043] Figure 2 This is a schematic diagram of the standardized packaging process for the MCP service of this invention;

[0044] Figure 3 This is a schematic diagram of the visual workflow orchestration interface and node configuration of the present invention;

[0045] Figure 4 This is a schematic diagram illustrating the interaction principle between the Stdio communication mechanism and the API gateway in this invention.

[0046] Figure 5 This is a schematic diagram of the workflow execution logic in the command and control scenario of this invention. Detailed Implementation

[0047] Example 1:

[0048] An integrated architecture for command and control decision services based on the MCP protocol, such as Figure 1 As shown, it includes a hierarchically coordinated MCP service encapsulation layer, communication transmission layer, API gateway layer, workflow orchestration layer, and operation monitoring layer. Each layer works together to achieve standardized, pluggable integration and visualized workflow orchestration of the command and decision service module in a closed network environment.

[0049] like Figure 2 As shown, the MCP service encapsulation layer is used to encapsulate functional modules such as unified coding service, geographic verification service, rule calculation service, model reasoning service, and interpretive calculation service in the command and control decision system according to the MCP protocol specification, forming an independent MCP service with unified input parameter format, output format, and communication convention;

[0050] The services in the MCP service encapsulation layer all include an MCP input parameter validation unit, which performs format validation, type validation, and field integrity validation on input parameters based on JSONSchema or equivalent constraints, and returns standardized error information when validation fails. The heterogeneous functional modules encapsulated in the MCP service encapsulation layer include an interpretable reasoning service, which calculates the importance of model input features based on the SHAP interpretable algorithm and returns an interpretable data structure to provide interpretability support in the decision-making process. Multiple MCP services are deployed in a containerized manner and support elastic scaling based on resource load to adapt to different business throughput requirements.

[0051] The communication transport layer, based on the Stdio channel of the MCP protocol, is used to achieve standardized communication between the API gateway and various MCP services across languages ​​and platforms without exposing network ports.

[0052] The communication transport layer is based on Stdio to implement data transmission, enabling the MCP service to complete bidirectional communication with the API gateway without opening external network ports, thereby improving communication security and deployment flexibility.

[0053] The API gateway layer is used to register, authenticate, manage versions, schedule routes, and load balance the MCP services, enabling unified access and centralized management of multiple MCP services.

[0054] The API gateway layer includes a service registration module, used to write the service name, version number, operating environment, capability tags, communication method, and health check interface of the MCP service into the service directory; the API gateway layer includes a version management module, used to support version switching, canary release, rollback management, and parallel operation of multiple versions of the MCP service; the API gateway layer also includes an exception management module, used to capture input errors, execution errors, and timeout errors of the MCP service, and trigger retries, circuit breakers, or alternative service calls according to business policies.

[0055] like Figure 3 As shown, the workflow orchestration layer is used to configure processes, map node parameters, define execution links, and manage workflow versions for multiple MCP services based on a visual interface, thereby enabling flexible construction and dynamic updates of decision-making processes.

[0056] The workflow orchestration layer includes a visual process configuration interface for creating process nodes, setting parameter mapping relationships, defining execution order, and configuring logical branches based on drag-and-drop. During workflow execution, the workflow orchestration layer automatically maps the output of the previous node to the input parameters of the next node, forming a multi-node chained call relationship. The workflow orchestration layer supports version control of user-edited process structures, node parameters, and input / output mapping relationships to support process history backtracking and rapid switching.

[0057] The operation monitoring layer is used to monitor and record the running status, call time, abnormal situations and workflow execution of the MCP service, and realize service health checks, abnormal retries and call chain tracing.

[0058] The operation monitoring layer includes a call chain tracing module, which is used to record the service call chain, execution time, and the results or error information returned by the nodes.

[0059] An implementation method for a command and control decision service integration architecture based on the MCP protocol includes the following steps:

[0060] S1: MCP Service Encapsulation: Organize the command and decision-making function modules, encapsulate them into independent MCP services according to the MCP protocol specification, configure unified metadata information and input parameter verification rules, integrate interpretive reasoning services, and complete Docker / K8s containerized deployment;

[0061] Specifically, the MCP service encapsulation in step S1 includes: encapsulating the original functional logic into an independent process, using the stdin / stdout interface specified by MCP to process requests, verifying the input data format according to the MCP Schema, and encapsulating the service running results into a data structure that conforms to the MCP response format and outputting it to the standard output stream.

[0062] S2: Service Registration: After each independent MCP service starts, it submits registration information to the API gateway layer, completes the service catalog entry and health check interface configuration, and the API gateway layer starts a scheduled health check.

[0063] S3: Communication Configuration: Establish a bidirectional communication link between each MCP service and the API gateway layer based on the Stdio channel, and close all external network ports of the MCP service;

[0064] S4: Workflow Orchestration: Configure MCP service nodes through a visual drag-and-drop interface, define execution links, logical branches and parameter mapping rules, and save the configured workflow in a versioned manner;

[0065] The parameter mapping rule configuration in step S4 includes two methods: automatic mapping and manual adjustment. Automatic mapping completes precise field matching based on the node's input and output schema, while manual adjustment supports user-defined field mapping relationships, type conversion rules, and default value configurations.

[0066] S5: Service Scheduling: After receiving a business request, the API gateway layer loads the corresponding workflow configuration, executes the routing scheduling, load balancing and version management of the MCP service according to the scheduling policy, and triggers retry, circuit breaking or alternative service calls in abnormal scenarios.

[0067] S6: End-to-end monitoring: The operation monitoring layer monitors the MCP service's running status and workflow execution process in real time, records call link data, resource load indicators, and service call indicators, and alerts and automatically handles abnormal situations.

[0068] S7: Service Iteration: Based on the module-level hot replacement mechanism, the MCP service is upgraded or rolled back to achieve uninterrupted system iteration.

[0069] Specifically, the module-level hot replacement in step S7 includes: the new version of the MCP service is launched in parallel with the old version and the service registration is completed; the API gateway layer distributes traffic according to a preset ratio; the operation monitoring layer verifies the stability of the new version in real time; after the verification is passed, the distribution ratio is gradually increased to full switch; if an anomaly occurs, the traffic is immediately switched back to the old version to achieve a fast rollback.

[0070] Example 2:

[0071] This embodiment is a further refinement based on Embodiment 1. This embodiment details the specific implementation path of the standardized modular decision service integration architecture based on the MCP protocol. For example... Figures 1-5As shown, the implementation details of each layer are described in sequence according to the technical logic flow of "service encapsulation → communication → gateway → workflow → monitoring". It includes multi-language code examples and configuration files, fully covering all technical features of the claims, and ensuring that the technical solution is fully disclosed and implementable.

[0072] 1. Implementation of the MCP service encapsulation layer

[0073] 1.1 Service Standardization and Encapsulation Process

[0074] The MCP service encapsulation layer is used to encapsulate functional modules such as unified coding service, geographic verification service, rule calculation service, model inference service, anomaly detection, and SHAP interpretive calculation service in the decision system according to the MCP protocol specification, so that they have unified description capabilities and calling methods, forming independent MCP services with unified input parameter format, output format and communication convention.

[0075] During implementation, the decision-making function module is first encapsulated using the MCP protocol:

[0076] Define service metadata: Create an MCP service description file for each module, containing the following definitions: name: service name, version: version number, description: service description, input_schema: input parameter structure (JSON Schema format), output_schema: output data structure, capabilities: types of capabilities provided by the service, such as inference, validation, and explain; security_metadata: access control fields, such as token and scope. Each functional module is encapsulated using a unified method, including: encapsulating existing functional logic into independent processes; using the stdin / stdout interfaces specified by MCP to process requests; validating the input data format according to the MCP Schema; encapsulating the service execution results into a data structure conforming to the MCP response format; and outputting to the standard output stream for reading by the API gateway or upper-layer workflow. After MCP encapsulation, any module can be deployed and upgraded independently, and interact with the system using the same protocol.

[0077] Encapsulate as an independent process: Encapsulate the original functional logic into an independent executable file, which is then started via a shell script.

[0078] Implement the Stdio communication interface: The service listens to the standard input stream, receives JSON format requests, processes them, and writes the results to the standard output stream.

[0079] 1.2 Implementation of Input Parameter Validation Unit

[0080] All services in the MCP service encapsulation layer include an MCP input parameter validation unit, which is used to perform format validation, type validation, and field integrity validation on input parameters based on JSON Schema or equivalent constraints.

[0081] Automatic validation based on JSON Schema (Javascript code):

[0082] const Ajv = require('ajv');

[0083] const ajv = new Ajv({allErrors: true});

[0084] function validateInput(schema, data) {

[0085] const validate = ajv.compile(schema);

[0086] const isValid = validate(data);

[0087] if (!isValid) {

[0088] const errors = validate.errors.map(err =>

[0089] `${err.instancePath} ${err.message} (received: ${JSON.stringify(err.data)})` );

[0091] throw new ValidationError('INVALID_PARAMETERS', errors.join(';'));

[0092] }

[0093] return true;

[0094] }

[0095] 1.3 Implementation of SHAP Interpretation Service

[0096] MCP services include an interpretable reasoning service, which calculates the importance of model input features based on SHAP or other interpretable algorithms and returns an interpretable data structure.

[0097] Based on the SHAP interpretable algorithm (Python code)

[0098] class SHAPExplanationService:

[0099] def __init__(self, model_path):

[0100] self.model = load_model(model_path)

[0101] self.explainer = shap.Explainer(self.model)

[0102] def explain(self, input_data):

[0103] processed = preprocess(input_data)

[0104] shap_values ​​= self.explainer(processed)

[0105] return {

[0106] "base_value": float(shap_values.base_values),

[0107] "shap_values": shap_values.values.tolist(),

[0108] "feature_names": get_feature_names(),

[0109] "explanation_type": "shap"

[0110] }

[0111] 1.4 Containerized Deployment and Elastic Scaling

[0112] Multiple MCP services are deployed in a containerized manner and support elastic scaling based on resource load to adapt to different business throughput requirements.

[0113] MCP service deployment configuration on Kubernetes (YAML code):

[0114] # MCP Service Deployment Definition

[0115] apiVersion: apps / v1

[0116] kind: Deployment

[0117] metadata:

[0118] name: geocode-validator

[0119] labels:

[0120] app: mcp-service

[0121] service-type: geocode-validator

[0122] spec:

[0123] replicas: 3

[0124] selector:

[0125] matchLabels:

[0126] app: geocode-validator

[0127] template:

[0128] metadata:

[0129] labels:

[0130] app: geocode-validator

[0131] spec:

[0132] containers:

[0133] - name: mcp-service

[0134] image: registry.example.com / geocode-validator:1.2.0

[0135] ports:

[0136] - containerPort: 8080

[0137] resources:

[0138] limits:

[0139] CPU: "500m"

[0140] memory: "512Mi"

[0141] requests:

[0142] CPU: "200m"

[0143] memory: "256Mi"

[0144] readinessProbe:

[0145] exec:

[0146] command: [" / bin / sh", "-c", "echo 'READY' | nc -w 1localhost 8080"]

[0147] initialDelaySeconds: 5

[0148] periodSeconds: 10

[0149] 2. Implementation of the communication transport layer

[0150] 2.1 Implementation of Stdio Communication Mechanism

[0151] The communication transport layer uses Stdio to implement data transmission, enabling the MCP service to complete bidirectional communication with the API gateway without opening external network ports, thereby improving communication security and deployment flexibility.

[0152] Data transfer based on Stdio (Go code)

[0153] func (p *StdioProxy) Start() {

[0154] go p.readFromStdin()

[0155] go p.writeToStdout()

[0156] go p.monitorHealth()

[0157] }

[0158] func (p *StdioProxy) readFromStdin() {

[0159] scanner := bufio.NewScanner(p.stdin)

[0160] scanner.Buffer(make([]byte, 1024), 1<<20) / / 1MB buffer

[0161] for scanner.Scan() {

[0162] line := scanner.Text()

[0163] if isValidJSON(line) {

[0164] p.incoming <- json.RawMessage(line)

[0165] }

[0166] }

[0167] }

[0168] func (p *StdioProxy) writeToStdout() {

[0169] for msg := range p.outgoing {

[0170] p.stdout.Write([]byte(msg))

[0171] p.stdout.Write([]byte("\n"))

[0172] }

[0173] }

[0174] 3. Implementation of API Gateway and Scheduling Control Layer

[0175] 3.1 Service Registration Module

[0176] Introduce a unified API gateway to enable centralized management, call scheduling, and access control of MCP services.

[0177] Each MCP service submits registration information to the API gateway upon startup, including: service name and version number; network access method (e.g., container address); invocation capabilities and load status; and a health check. The gateway maintains a service catalog for subsequent routing and scheduling.

[0178] The gateway executes the following scheduling strategies based on the request content and workflow configuration: service tag-based routing; version number-based canary deployment; load balancing based on load information; and access permission filtering based on identity and permissions.

[0179] Regardless of the language or framework used by a specific module, the API gateway sends requests to it using a unified MCP call format, thereby achieving standardized collaboration at the system level.

[0180] The API gateway layer includes a service registration module, which is used to write the service name, version number, operating environment, capability tags, communication method, and health check interface of the MCP service into the service directory.

[0181] Service registration (Java code)

[0182] public class ServiceRegistry {

[0183] private final ConcurrentHashMap<String, ServiceInfo> services =new ConcurrentHashMap<>();

[0184] public void registerService(ServiceInfo service) {

[0185] String key = service.getServiceName() + ":" +service.getVersion();

[0186] services.put(key, service);

[0187] HealthChecker.scheduleCheck(service);

[0188] }

[0189] public ServiceInfo getService(String name, String version) {

[0190] return services.get(name + ":" + version);

[0191] }

[0192] }

[0193] 3.2 Version Management Module

[0194] The API gateway layer includes a version management module, which supports version switching, canary releases, rollback management, and parallel operation of multiple versions for the MCP service.

[0195] Version control (Java code)

[0196] public class VersionManager {

[0197] public ServiceInstance selectInstance(String serviceName, StringrequestedVersion, Map<String, String> context) {

[0198] / / Version matching strategy

[0199] if (requestedVersion != null && !requestedVersion.isEmpty()){

[0200] ServiceInfo service = registry.getService(serviceName,requestedVersion);

[0201] if (service != null) return service.getInstance();

[0202] }

[0203] / / Canary release strategy

[0204] String canaryHeader = context.get("X-MCP-Canary");

[0205] if ("true".equals(canaryHeader)) {

[0206] ServiceInfo canaryService = findCanaryService(serviceName);

[0207] if (canaryService != null) returncanaryService.getInstance();

[0208] }

[0209] / / Default to the latest stable version

[0210] return registry.getLatestStableVersion(serviceName);

[0211] }

[0212] }

[0213] 3.3 Exception Management Module

[0214] The API gateway layer also includes an exception management module, which is used to capture input errors, execution errors, and timeout errors of the MCP service, and trigger retries, circuit breakers, or alternative service calls according to business policies.

[0215] Exception management (Java code)

[0216] public class ExceptionHandler {

[0217] public MCPResponse handleException(MCPRequest request, Exceptione) {

[0218] if (e instanceof MCPValidationError) {

[0219] return new MCPErrorResponse(

[0220] request.getRequestId(),

[0221] "VALIDATION_ERROR",

[0222] e.getMessage(), 400 );

[0225] } else if (e instanceof ServiceUnavailableException) {

[0226] MCPService fallback = getFallbackService(request.getServiceName());

[0227] if (fallback != null) {

[0228] return invokeService(fallback, request);

[0229] }

[0230] return new MCPErrorResponse(

[0231] request.getRequestId(),

[0232] "SERVICE_UNAVAILABLE",

[0233] "All instances are unavailable", 503 );

[0236] }

[0237] / / Other exception handling...

[0238] }

[0239] }

[0240] 4. Implementation of the workflow orchestration layer

[0241] 4.1 Visual Process Configuration Interface

[0242] The workflow orchestration layer includes a visual process configuration interface, which is used to create process nodes, set parameter mapping relationships, define execution order, and configure logical branches based on drag and drop.

[0243] Each node is an MCP service instance, which includes: input parameter mapping rules; MCP service selection and version selection; exception handling strategy; and downstream node binding configuration for output results.

[0244] During workflow execution: parse nodes in the order of the flowchart; sort the topology according to call dependencies; send MCP call requests to each node; summarize node outputs as inputs for subsequent nodes; and record link logs for tracing and replay.

[0245] The workflow platform supports multiple strategies: parallel node execution; branch decision nodes; condition-triggered nodes; automatic parameter validation and type conversion.

[0246] Visual process configuration (JSX code)

[0247] function WorkflowEditor() {

[0248] const [nodes, setNodes] = useState([]);

[0249] const [connections, setConnections] = useState([]);

[0250] const handleDrop = (event) => {

[0251] const serviceId = event.dataTransfer.getData('service');

[0252] const {x, y} = getMousePosition(event);

[0253] addNode(serviceId, x, y);

[0254] };

[0255] const configureMapping = (sourceNode, targetNode) => {

[0256] setConnections([...connections, {

[0257] source: sourceNode.id,

[0258] target: targetNode.id,

[0259] mappings: sourceNode.outputs.map(output => ({

[0260] source: output,

[0261] target: targetNode.inputs.find(i => i.name === output).name

[0262] }))

[0263] }]);

[0264] };

[0265] return (

[0266] <div classname="workflow-canvas" ondrop="{handleDrop}" ondragover="{e" =>e.preventDefault()}>

[0267] {nodes.map(node => (

[0268] <workflownode key="{node.id}" node="{node}" onConfigure="{configureMapping}" / >

[0269] ))}

[0270] <servicepalette / >

[0271] );

[0273] }

[0274] 4.2 Automatic Parameter Mapping Mechanism

[0275] The workflow orchestration layer is used to automatically map the output of the previous node to the input parameters of the next node during workflow execution, forming a multi-node chained call relationship.

[0276] Automatic parameter mapping (Python code)

[0277] def map_parameters(node, context):

[0278] params = {}

[0279] for input_def in node.input_definitions:

[0280] value = context.get_value(input_def.source_path)

[0281] if value is not None and input_def.type != 'any':

[0282] try:

[0283] value = convert_type(value, input_def.type)

[0284] except ValueError:

[0285] raise WorkflowException(f"Type mismatch for {input_def.name}")

[0286] params[input_def.name] = value

[0287] return params

[0288] 4.3 Workflow Version Management

[0289] The workflow orchestration layer supports version control of user-edited process structures, node parameters, and input / output mapping relationships to support process history backtracking and quick switching.

[0290] Workflow version control (Java code)

[0291] public class WorkflowVersionManager {

[0292] private final Map<String, WorkflowHistory> histories = newConcurrentHashMap<>();

[0293] public void saveWorkflow(WorkflowDefinition workflow) {

[0294] String workflowId = workflow.getId();

[0295] WorkflowHistory history = histories.computeIfAbsent(workflowId, k -> new WorkflowHistory());

[0296] String version = generateVersion(workflow);

[0297] WorkflowVersion newVersion = new WorkflowVersion(

[0298] version,

[0299] workflow,

[0300] LocalDateTime.now(),

[0301] SecurityContext.getCurrentUser() );

[0303] history.addVersion(newVersion);

[0304] workflowStorage.save(newVersion);

[0305] }

[0306] public WorkflowDefinition getWorkflow(String id, String version){

[0307] WorkflowHistory history = histories.get(id);

[0308] if (history == null) {

[0309] throw new WorkflowNotFoundException(id);

[0310] }

[0311] return history.getVersion(version).getDefinition();

[0312] }

[0313] }

[0314] 5. Implementation of the monitoring layer

[0315] 5.1 Invoking the Link Tracing Module

[0316] The runtime monitoring layer includes a call chain tracing module, which records the service call chain, execution time, and the results or error information returned by the nodes.

[0317] Call chain tracing (Java code)

[0318] public class TracingService {

[0319] private final Tracer tracer = GlobalTracer.get();

[0320] public void startTrace(MCPRequest request) {

[0321] String traceId = request.getHeader("X-Trace-Id");

[0322] String parentId = request.getHeader("X-Parent-Span-Id");

[0323] Span span = tracer.buildSpan(request.getServiceName())

[0324] .asChildOf(TraceContext.extract(traceId, parentId))

[0325] .withTag("version", request.getVersion())

[0326] .start();

[0327] RequestContext.setCurrentSpan(span);

[0328] }

[0329] public void recordMetrics(MCPResponse response, long duration) {

[0330] Span span = RequestContext.getCurrentSpan();

[0331] if (response.isSuccess()) {

[0332] span.setTag("status", "success");

[0333] } else {

[0334] span.setTag("status", "error");

[0335] span.setTag("error_code", response.getErrorCode());

[0336] span.log(response.getErrorMessage());

[0337] }

[0338] span.setTag("duration", duration);

[0339] span.finish();

[0340] Metrics.record("mcp.service.duration", duration,

[0341] "service", response.getServiceName(),

[0342] "version", response.getVersion());

[0343] }

[0344] }

[0345] 6. Complete Workflow Example

[0346] 1) Commanders submit situation analysis requests through the front-end interface;

[0347] 2) The API gateway receives requests and forwards them to the workflow engine;

[0348] 3) The workflow engine loads "tactical_analysis_workflow" to direct the workflow;

[0349] 4) Execute the "sensor_fusion", "risk_assessment", and "resource_allocation" nodes in sequence;

[0350] 5) Each node calls the corresponding MCP service (such as situation fusion service, risk assessment service, and resource scheduling service) via Stdio communication;

[0351] The communication mechanism is based on Stdio, using the MCP-compliant Stdio communication method as the underlying mechanism for inter-service interaction. Modules receive requests through standard input (stdin) and return responses through standard output (stdout). This approach offers the following advantages: no need to expose external network ports; natural isolation between services, resulting in high security; unified format, strong cross-language compatibility; and a simple deployment environment, requiring no additional protocol stack. All inputs and outputs strictly adhere to the MCP JSON format definition, and the system can track tasks and monitor operation through metadata.

[0352] 6) The workflow engine aggregates the situational analysis results, risk assessment conclusions, and resource scheduling suggestions and returns them to the API gateway;

[0353] 7) The API gateway returns a complete decision support report to the command personnel interface.

[0354] In a microservices-based environment, each MCP service runs as a microservice with independent lifecycle management capabilities, independent deployment, and elastic scaling. Module operation modes include: containerized deployment (Docker / Kubernetes); automatic horizontal scaling up and down; and module-level resource isolation (CPU / MEM limits).

[0355] This invention supports module-level hot replacement: new version services are launched in parallel with old versions; the API gateway distributes traffic proportionally; the old version is gradually replaced after stability is verified; and if an anomaly occurs, it can be rolled back to the old version. This mechanism ensures that the system can iterate rapidly without service interruption.

[0356] The above description is only used to illustrate the technical solution of the present invention and is not intended to limit it. Various changes and modifications can be made to the present invention without departing from the spirit and scope of the present invention, and all such changes and modifications should be included within the protection scope of the present invention.

Claims

1. A command and control decision service integration architecture based on the MCP protocol, characterized in that, It includes a hierarchical and collaborative MCP service encapsulation layer, communication transmission layer, API gateway layer, workflow orchestration layer, and operation monitoring layer. Each layer works together to achieve standardized, pluggable integration and visualized workflow orchestration of the command and decision service module in a closed network environment. The MCP service encapsulation layer is used to encapsulate functional modules such as unified coding service, geographic verification service, rule calculation service, model reasoning service, and interpretive calculation service in the command and control decision system according to the MCP protocol specification, forming an independent MCP service with unified input parameter format, output format, and communication convention. The communication transport layer, based on the Stdio channel of the MCP protocol, is used to achieve standardized communication between the API gateway and various MCP services across languages ​​and platforms without exposing network ports. The API gateway layer is used to register, authenticate, manage versions, schedule routes, and load balance the MCP services, enabling unified access and centralized management of multiple MCP services. The workflow orchestration layer is used to configure processes, map node parameters, define execution links, and manage workflow versions for multiple MCP services based on a visual interface, enabling flexible construction and dynamic updates of decision-making processes. The operation monitoring layer is used to monitor and record the running status, call time, abnormal situations and workflow execution of the MCP service, and realize service health checks, abnormal retries and call chain tracing.

2. The architecture according to claim 1, characterized in that, The services in the MCP service encapsulation layer all include an MCP input parameter validation unit, which performs format validation, type validation, and field integrity validation on input parameters based on JSON Schema or equivalent constraints, and returns standardized error information when validation fails. The heterogeneous functional modules encapsulated in the MCP service encapsulation layer include an interpretable reasoning service, which calculates the importance of model input features based on the SHAP interpretable algorithm and returns an interpretable data structure to provide interpretability support in the decision-making process. Multiple MCP services are deployed in a containerized manner and support elastic scaling based on resource load to adapt to different business throughput requirements.

3. The architecture according to claim 1, characterized in that, The communication transport layer is based on Stdio to implement data transmission, enabling the MCP service to complete bidirectional communication with the API gateway without opening external network ports, thereby improving communication security and deployment flexibility.

4. The architecture according to claim 1, characterized in that, The API gateway layer includes a service registration module, used to write the service name, version number, operating environment, capability tags, communication method, and health check interface of the MCP service into the service directory; the API gateway layer includes a version management module, used to support version switching, canary release, rollback management, and parallel operation of multiple versions of the MCP service; the API gateway layer also includes an exception management module, used to capture input errors, execution errors, and timeout errors of the MCP service, and trigger retries, circuit breakers, or alternative service calls according to business policies.

5. The architecture according to claim 1, characterized in that, The workflow orchestration layer includes a visual process configuration interface, which is used to create process nodes, set parameter mapping relationships, define execution order and configure logical branches based on drag and drop. The workflow orchestration layer is used to automatically map the output of the previous node to the input parameters of the next node during workflow execution, forming a multi-node chained call relationship; The workflow orchestration layer supports version management of user-edited process structures, node parameters, and input / output mapping relationships to support process history backtracking and quick switching.

6. The architecture according to claim 1, characterized in that, The operation monitoring layer includes a call chain tracing module, which is used to record the service call chain, execution time, and the results or error information returned by the nodes.

7. A method for an integrated architecture of command and control decision service based on the MCP protocol as described in any one of claims 1-6, characterized in that, Includes the following steps: S1: MCP Service Encapsulation: Organize the command and decision-making function modules, encapsulate them into independent MCP services according to the MCP protocol specification, configure unified metadata information and input parameter verification rules, integrate interpretive reasoning services, and complete Docker / K8s containerized deployment; S2: Service Registration: After each independent MCP service starts, it submits registration information to the API gateway layer, completes the service catalog entry and health check interface configuration, and the API gateway layer starts a scheduled health check. S3: Communication Configuration: Establish a bidirectional communication link between each MCP service and the API gateway layer based on the Stdio channel, and close all external network ports of the MCP service; S4: Workflow Orchestration: Configure MCP service nodes through a visual drag-and-drop interface, define execution links, logical branches and parameter mapping rules, and save the configured workflow in a versioned manner; S5: Service Scheduling: After receiving a business request, the API gateway layer loads the corresponding workflow configuration, executes the routing scheduling, load balancing and version management of the MCP service according to the scheduling policy, and triggers retry, circuit breaking or alternative service calls in abnormal scenarios. S6: End-to-end monitoring: The operation monitoring layer monitors the MCP service's running status and workflow execution process in real time, records call link data, resource load indicators, and service call indicators, and alerts and automatically handles abnormal situations. S7: Service Iteration: Based on the module-level hot replacement mechanism, the MCP service is upgraded or rolled back to achieve uninterrupted system iteration.

8. The method according to claim 7, characterized in that, The MCP service encapsulation described in step S1 specifically includes: encapsulating the original functional logic into an independent process, using the stdin / stdout interface specified by MCP to process requests, validating the input data format according to the MCP Schema, and encapsulating the service execution result into a data structure that conforms to the MCP response format and outputting it to the standard output stream.

9. The method according to claim 7, characterized in that, The parameter mapping rule configuration in step S4 includes two methods: automatic mapping and manual adjustment. Automatic mapping completes precise field matching based on the node's input and output schema, while manual adjustment supports user-defined field mapping relationships, type conversion rules, and default value configurations.

10. The method according to claim 7, characterized in that, The module-level hot replacement mentioned in step S7 specifically includes: the new version of the MCP service is launched in parallel with the old version and the service registration is completed; the API gateway layer distributes traffic according to a preset ratio; the operation monitoring layer verifies the stability of the new version in real time; after the verification is passed, the distribution ratio is gradually increased to full switch; if an anomaly occurs, the traffic is immediately switched back to the old version to achieve a fast rollback.

Images