MCP service platform and privileged publishing, calling and visual statistical method thereof

Abstract

The invention relates to the technical field of financial services, in particular to an MCP service platform and a privileged publishing, calling and visual statistical method thereof, the MCP service platform is deployed in an insurance enterprise private cloud and runs in an insurance enterprise internal network, and the MCP service platform comprises an MCP service creation module used for providing a Web interactive interface and creating MCP services to be published; the service publishing module is used for compiling a to-be-published MCP service into a standardized SSE service address, and configuring a service calling parameter and a calling secret key to form a callable MCP service; the permission distribution module is used for constructing a three-dimensional permission model comprising organizations, roles and attributes, and configuring permission control rules for callable MCP services; and the large-screen data display module is used for collecting the operation data of each module in real time and performing visual display. Therefore, MCP service full-process intranet closed-loop operation is achieved, data security is guaranteed, and meanwhile the use requirement of a multi-level mechanism is met.

Description

Technical Field

[0001] This application relates to the field of financial services technology, and in particular to an MCP service platform and its permission-based publishing, invocation, and visualization statistics method. Background Technology

[0002] The Model Context Protocol (MCP), as the core interface connecting large language models with external data / tools, functions similarly to the "USB-C" universal interface in electronic devices, enabling standardized integration between large models and various external services and data resources. After being open-sourced, the MCP protocol was quickly incorporated into the technology development roadmaps of many fintech companies, becoming a key support for expanding the service capabilities of large models. However, existing MCP-related technical solutions are still primarily in the form of public-network SaaS (Software as a Service), and have not yet formed a financial-grade solution adapted to the needs of the insurance industry. Specifically, it suffers from the following three core shortcomings: Insufficient protocol exclusivity: Mainstream MCP protocol implementations (such as the open-source version of Anthropic) rely on the public network environment for data interaction, which cannot meet the mandatory requirements for end-to-end intranet transmission of financial data. The insurance industry involves a large amount of customer privacy data and sensitive business data; transmission over the public network could lead to security risks such as data leakage and tampering, which does not comply with industry data security standards.

[0003] Lack of Enterprise-Level Management: The open-source MCP framework does not have a permission hierarchy model adapted to the nationwide insurance organizational structure. Insurance companies generally adopt a multi-level organizational structure of head office-provincial branch-city / county branch, but the existing framework cannot realize hierarchical authorization under this system. This makes it difficult for the headquarters to control the service usage of subordinate agencies, while subordinate agencies cannot flexibly configure service permissions according to their own business needs.

[0004] The monitoring dimensions are limited: Existing MCP service monitoring solutions only provide basic QPS (queries per second) monitoring metrics, lacking statistical capabilities for business operation dimensions such as service deployment volume, cross-institutional call ranking, and call failure rate. Insurance companies need to evaluate service value and optimize resource allocation through multi-dimensional monitoring data, and existing solutions cannot meet their business operation decision-making needs. Summary of the Invention

[0005] To overcome the shortcomings of existing technologies, this application provides an MCP service platform and its permission-based publishing, invocation, and visualization statistics method, which can realize the closed-loop operation of the entire MCP service within the intranet, ensuring data security while meeting the usage needs of multi-level organizations.

[0006] Firstly, this application provides an MCP service platform, deployed on an insurance company's private cloud and running on the insurance company's internal network, including: The MCP service creation module provides a web interface for users to fill in MCP service details, edit service logic code, and initially set access permissions to generate an MCP service to be published. The service publishing module is used to compile the MCP service to be published into a standardized SSE service address, and configure the service call parameters and call key to form a callable MCP service; The permission allocation module is used to integrate the unified identity and organizational structure directory of insurance companies, build a three-dimensional permission model including organization, role and attribute, and configure permission control rules for callable MCP services; The large-screen data display module is used to collect the running data of the MCP service creation module, the service publishing module, and the permission allocation module in real time and display them visually.

[0007] In one possible implementation, the MCP service creation module, the service publishing module, the permission allocation module, and the large-screen data display module interact with each other via the Streamable HTTP protocol. The Streamable HTTP protocol is based on ordinary HTTP requests, allowing clients to initiate requests via POST / GET. The server upgrades the response to a server-sent event stream (SSE stream) according to business needs. The client and the server complete the request initiation and SSE stream reception through the same path.

[0008] In one possible implementation, the organizational information in the three-dimensional permission model is configured based on the six-level organizational unit data of the insurance company; the role information is configured based on the association between users, roles, and services, including service creators, service auditors, ordinary callers, and administrators; the attribute information is configured based on row and column labels, which include data access scope labels and access rule labels set for each MCP service; and the three-dimensional permission model is stored in the form of a five-tuple of organization, role, service, row filtering rules, and column desensitization rules.

[0009] In one possible implementation, the permission allocation module also sets permission conflict resolution rules based on permission type priority and scope priority.

[0010] Secondly, this application provides a method for authoritative publishing of MCP services, applied to the MCP service platform described in the first aspect, the method comprising the following steps: Users can fill in the name, function description and parameter description of the MCP service in Markdown format through the web interactive interface provided by the MCP service creation module, edit the service logic code, and initially set the access permission scope of the service to generate the MCP service to be published. The generated MCP service to be published is subjected to security verification and compliance review, and the service publication process is triggered after the review is passed; The service publishing module compiles the approved MCP service to be published into an SSE service address in a set format, and configures the input parameter format, output data structure and calling key of the service call to generate a callable MCP service. The permission allocation module configures a three-dimensional permission policy, including organization, role, and attribute, for the generated callable MCP service based on the insurance company's organizational structure and user roles, thereby enabling the SSE service address to be called.

[0011] Thirdly, this application provides a method for accessing MCP services with permissions, applied to the MCP service platform described in the first aspect, the method comprising the following steps: In the internal network environment of an insurance company, client users select the target callable MCP service generated by the service publishing module through the interactive interface of the AI ​​big model service platform, input the calling parameters and calling key, and initiate a calling request to the SSE service address corresponding to the service. The permission allocation module establishes an SSE connection after verifying the client user's permissions in one go, based on a preset three-dimensional permission policy. The server selects between a standard HTTP response and an SSE streaming service to complete the service call, depending on the business requirements.

[0012] Fourthly, this application provides a visualization and statistical method for MCP services, applied to the MCP service platform described in the first aspect, the method comprising the following steps: The large-screen data display module collects real-time data on the number of publications, the number of calls, the call ranking, and the failure rate generated by the MCP service creation module, the service publishing module, and the permission allocation module from the insurance company's internal database cluster. The collected data is categorized and aggregated according to the organizational structure and then displayed on a large visual dashboard.

[0013] In one possible implementation, users with the role of administrator are granted permission to access or export the data displayed on the large screen.

[0014] Fifthly, this application provides an electronic device, including: a processor, a memory, and a bus, wherein the memory stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor communicates with the memory via the bus, and when the machine-readable instructions are executed by the processor, they perform the steps of an MCP service permission-based publishing, invocation, and visualization statistics method as described in any of the second, third, and fourth aspects.

[0015] Sixthly, this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, performs the steps of an MCP service permission-based publishing, invocation, and visualization statistics method as described in any of the first, second, third, and fourth aspects.

[0016] This embodiment provides an MCP service platform and its permission-based publishing, invocation, and visualization statistics method, deployed on an enterprise private cloud intranet. It achieves closed-loop operation of the entire process of MCP service creation, publishing, and invocation, ensuring data security. Furthermore, relying on a three-dimensional permission model of organization-role-attribute, it accurately matches the organizational structure of the insurance industry, meeting the service usage needs of multi-level institutions. It also achieves efficient streaming interaction through the Streamable HTTP protocol, improving the user experience. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 A schematic diagram of the structure of the MCP service platform according to an embodiment of this application is shown; Figure 2 A schematic diagram of the organizational structure according to an embodiment of this application is shown; Figure 3 A flowchart of the MCP service permission-based publishing method according to an embodiment of this application is shown; Figure 4 A flowchart of an embodiment of the MCP service permission-based invocation method described in this application is shown; Figure 5 A flowchart of the MCP service visualization and statistical method according to an embodiment of this application is shown; Figure 6 A structural block diagram of an electronic device according to an embodiment of this application is shown. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the accompanying drawings in this application are for illustrative and descriptive purposes only and are not intended to limit the scope of protection of this application. Furthermore, it should be understood that the schematic drawings are not drawn to scale. The flowcharts used in this application illustrate operations implemented according to some embodiments of this application. It should be understood that the operations in the flowcharts may not be implemented in sequence, and steps without logical contextual relationships may be reversed or implemented simultaneously. In addition, those skilled in the art, guided by the content of this application, may add one or more other operations to the flowcharts, or remove one or more operations from the flowcharts.

[0020] Furthermore, the described embodiments are merely some, not all, of the embodiments of this application. The components of the embodiments of this application described and illustrated herein can typically be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0021] It should be noted that the term "comprising" will be used in the embodiments of this application to indicate the presence of the features declared thereafter, but does not exclude the addition of other features.

[0022] In view of the technical problems raised in the background, this application provides an MCP service platform and its permission-based publishing, calling and visualization statistics method, which can realize the closed-loop operation of the entire MCP service within the intranet, ensuring data security while meeting the usage needs of multi-level organizations.

[0023] In one embodiment, see the appendix to the specification. Figure 1 This application provides an MCP service platform, deployed on an insurance company's private cloud and running on the insurance company's internal network, comprising: The MCP service creation module provides a web interface for users to fill in MCP service details, edit service logic code, and initially set access permissions to generate an MCP service to be published. The service publishing module is used to compile the MCP service to be published into a standardized SSE service address, and configure the service call parameters and call key to form a callable MCP service; The permission allocation module is used to integrate the unified identity and organizational structure directory of insurance companies, build a three-dimensional permission model including organization, role and attribute, and configure permission control rules for callable MCP services; The large-screen data display module is used to collect the running data of the MCP service creation module, the service publishing module, and the permission allocation module in real time and display them visually.

[0024] First, it should be noted that the MCP service platform provided in this application is limited to deployment on the insurance company's private cloud and operation within the insurance company's internal network. The insurance company's private cloud is a dedicated cloud computing resource pool, providing services only to that insurance company and not sharing hardware, software, or storage resources with external institutions. This avoids the potential data leakage risks associated with resource sharing, and allows the company to independently configure cloud resource security policies (such as firewall rules and data encryption standards) and operational processes (such as vulnerability patching and version updates), conforming to internal IT management standards. Furthermore, only internal employees (through the office LAN) and authorized devices (such as intranet terminals and VPN-accessed remote devices) can connect to the platform; external public network users cannot directly access it. Interactions between the platform and the company's internal database cluster and business systems (such as underwriting and claims systems) are all completed within the internal network, with no public network data transmission links. Thus, through physical isolation and network closure, data and service controllability and security are achieved, complying with financial industry regulatory requirements.

[0025] Furthermore, the MCP service creation module, service publishing module, permission allocation module, and large-screen data display module described in this application interact with each other via the Streamable HTTP protocol. Streamable HTTP is based on ordinary HTTP requests. When a client initiates a request, it can directly use the standard HTTP POST / GE method, eliminating the need to develop entirely new communication interfaces, reducing technical access costs, and ensuring compatibility with existing network infrastructure (such as intranet firewalls and load balancers). The server can dynamically select the response method based on the business requirements of the request: for scenarios with short data volumes and immediate responses (such as single service parameter verification or simple result return), it directly returns an ordinary HTTP response (one-time complete data); for scenarios with long data volumes and continuous real-time transmission (such as streaming responses generated from large models or batch policy data synchronization), it automatically upgrades the response to an SSE (Server Send Event) stream. Through the native characteristics of SSE, the server can continuously push data fragments to the client (without requiring repeated client requests), achieving low-latency, high-throughput streaming interaction, adapting to business scenarios in the insurance industry that require real-time feedback (such as real-time risk alerts during underwriting).

[0026] The MCP service creation module serves as the source creation end for MCP services. Its core function is to support users in building custom MCP service templates that adapt to different insurance business scenarios as needed, providing a basic prototype for subsequent release and invocation.

[0027] Specifically, the MCP service creation module provides a visual web interface through which users configure basic information, develop service logic, and preset initial permissions. When configuring basic information, users must fill in the core service information in a standardized Markdown format, including the service name (which must reflect the business scenario, such as "Critical Illness Insurance Underwriting Data Verification Service"), a function description (clearly defining the service's purpose and applicable stages), and parameter descriptions (including field names, data types, and required field identifiers for input / output parameters), ensuring clear and traceable information. The MCP service creation module supports online editing in mainstream programming languages ​​such as Java and Python, and has built-in syntax checking and compilation preview functions. When developing service logic, users can directly write core logic such as data queries, business calculations, and interface integration, avoiding basic syntax errors. When presetting initial permissions, users can pre-set approximate access boundaries based on the service's applicable scope (e.g., visible only to this department, accessible to the entire company, or accessible only to provincial institutions), providing a reference for subsequent refined permission configuration and reducing repetitive operations. This enables lightweight and standardized service creation, allowing business and technical personnel to quickly build MCP services that meet actual needs without relying on professional development teams, and adapt to the customized needs of diverse business scenarios in the insurance industry (such as underwriting, claims, data query, etc.).

[0028] The service publishing module primarily transforms the MCP services generated by the MCP service creation module into legitimate MCP services that can be legally invoked by clients. Specifically, it compiles the user-edited service logic code in real-time, generating a fixed-format SSE (Server Send Event) service address: http: / / mcp.chinalife.com / sse / {service_id}. Here, {service_id} is an automatically generated unique identifier, ensuring the uniqueness and traceability of each service address. Users need to visually configure service invocation specifications, including input parameter formats (such as JSON Schema constraints) and output data structures (such as field hierarchy and encoding standards), ensuring that callers initiate requests according to a unified standard and avoiding format compatibility issues. Simultaneously, a unique invocation key (such as a 32-bit random string) is automatically generated as an authentication credential for client invocation, bound one-to-one with the SSE service address to prevent unauthorized access. After configuration and approval, invocation can be officially opened. Thus, through standardized compilation and secure configuration, the callability, security, and compatibility of the MCP service are ensured, providing a unified and standardized interaction foundation for subsequent permission binding and client invocation.

[0029] The permission allocation module is mainly based on the organizational structure and role system of insurance companies to build a multi-dimensional permission model, realize refined control over MCP service access and data usage, and balance business flexibility and compliance.

[0030] For details, please refer to the instruction manual appendix. Figure 2 The constructed multi-dimensional permission model involves three dimensions: organization, role, and attribute. The organization dimension (O) relies on LDAP (Lightweight Directory Access Protocol) to synchronously maintain a six-level tree-structured organizational unit (OU) from head office to provincial branch, prefecture-level branch, county-level branch, sub-branch, and outlet. It supports permission inheritance (lower-level organizations inherit permissions from higher-level organizations by default) and exception configuration (allowing for individual restriction of permissions on specific lower-level organizations), accurately matching the hierarchical management architecture of insurance companies. The role dimension (R) establishes a three-level association between user, role, and service, defining permission boundaries through (user, role, service) triples. For example, role types include service creator, service approver, ordinary caller, and administrator, with different roles corresponding to specific operational permissions (e.g., an approver is only responsible for service approval and has no creation permission). The attribute dimension (A) achieves fine-grained control at the row and column levels. The data access scope is defined by the row-level label (data_scope), with options including ALL (all data), PROVINCE (data from this province), CITY (data from this city), and BRANCH (data from this organization). The field access rules are defined by the column-level label (mask), with options including PLAIN (display in plain text), MASKED (masking using regular expressions, such as hiding the middle 4 digits of a phone number), and DENY (deny access, do not return the field). Each access policy is stored in the form of a 5-tuple: ⟨O, R, Service, Row_Filter, Column_Mask> to ensure clear and executable rules. Row_Filter represents the row filtering rule, defined using Spring-EL syntax; Column_Mask represents the column masking rule, supporting regular expressions for masking rules (such as masking phone numbers) or setting it to DENY to deny field access.

[0031] Furthermore, conflict resolution rules are set up with clear priority decisions. Specifically, when multiple policies conflict, they are handled according to the following priorities to ensure consistency in permission execution: Permission type priority: DENY (deny) > ALLOW (allow); Scope priority: Branch office level > County branch office > City branch office > Provincial branch office > Head office (the smaller the scope, the higher the priority); Timestamp priority: For conflicting policies of the same scope and permission type, the policy with the latest updated timestamp prevails.

[0032] This allows for the construction of a highly adaptable access control system for the insurance industry, supporting centralized control by headquarters while meeting the differentiated access needs of institutions at all levels. At the same time, row-level and column-level control ensures the security of sensitive data and aligns with the compliance requirements of the financial industry.

[0033] The large-screen data display module serves as the data monitoring center for the entire lifecycle of MCP services, collecting, aggregating, and displaying operational data in real time to provide intuitive decision support for enterprise management. The data collection scope covers key indicators throughout the service lifecycle, including: service release quantity, statistically analyzed by province and business type (e.g., health insurance service release volume in a specific province); service call count, statistically analyzed by institution and time period (e.g., monthly call volume of a branch office in a specific city); call ranking, sorted by institution and service type (e.g., top 10 services / institutions by call volume); and call failure rate, analyzed by service and error type (e.g., the percentage of failures due to insufficient permissions or incorrect parameters). It employs a combination of overview charts and detailed tables, including bar charts (province release volume comparison), line charts (call volume trends), leaderboards (popular services), and detailed tables (single service call records), supporting switching between daily / weekly / monthly / quarterly time dimensions. It also supports drill-down from head office to provincial branch offices to city-level branch offices. For example, clicking on provincial data directly displays details of subordinate cities, quickly identifying data highlights or anomalies.

[0034] Furthermore, access permissions can be set. For example, access can be restricted to administrators only, with permissions divided by level (headquarters / provincial / municipal level administrators), allowing only those at their corresponding level and subordinate organizations to view data, thus preventing unauthorized access. Data export (Excel format) is supported, with flexible selection of the export range (full data / level / time period data), and export operation records are logged. Users can also click on data items to view details (such as the specific reasons for failures behind the failure rate).

[0035] This enables real-time, visual, and traceable MCP service operation data, helping management to quickly grasp the service promotion effect, call efficiency, and bottlenecks, and providing data support for resource optimization and business strategy adjustment.

[0036] As can be seen, the MCP service platform provided in this application is deployed on the private cloud intranet of insurance companies, operating in a closed-loop process. It complies with relevant regulations on financial data security and personal information protection, completely avoiding the risk of data leakage caused by public network transmission. Furthermore, it is compatible with the six-level organizational structure of the insurance industry, achieving fine-grained control through a three-dimensional permission model of organization-role-attribute. This supports flexible service publishing by institutions at all levels while ensuring centralized control by headquarters, balancing flexibility and compliance.

[0037] See the instruction manual appendix Figure 3 Based on the same inventive concept, this application also provides a method for authoritative publishing of MCP services, applied to the aforementioned MCP service platform. The method includes the following steps: S1. Users fill in the name, function description and parameter description of the MCP service in Markdown format through the Web interactive interface provided by the MCP service creation module, edit the service logic code, and initially set the access permission scope of the service to generate the MCP service to be published. S2. Perform security verification and compliance review on the generated MCP service to be published, and trigger the service publication process after the review is passed; S3. The approved MCP service to be published is compiled into an SSE service address in a set format through the service publishing module, and the input parameter format, output data structure and calling key of the service call are configured to generate a callable MCP service. S4. Based on the insurance company's organizational structure and user roles, the permission allocation module configures a three-dimensional permission policy, including organization, role, and attributes, for the generated callable MCP service, thereby enabling the SSE service address to be called.

[0038] Specifically, after logging into the MCP service platform, users (such as business and technical personnel from insurance companies) first complete the basic service information entry, logic development, and permission preset through the visual web interface provided by the MCP service creation module, generating an MCP service to be published. After service creation, the MCP service to be published is automatically pushed to the review process, where designated service reviewers (such as corporate compliance specialists or technical leads) conduct dual reviews to ensure service compliance and controllability. Security verification: Reviewers use the platform's built-in security testing tools to verify whether the service logic code has vulnerabilities (such as SQL injection, unauthorized access risks), whether the data access path complies with the company's data security specifications (such as unauthorized access to sensitive data fields), and whether there are potential performance risks (such as infinite loops, excessive resource consumption). Compliance review: Verifying the completeness of basic service information (such as whether parameter descriptions are comprehensive and function descriptions are clear), format compliance (whether Markdown formatting is consistent and field naming conforms to the company's technical standards), and the rationality of parameter design (such as whether input and output parameters are compatible with the data format of the insurance business system). If the review is approved, the subsequent release process will be triggered; if the review is not approved, the modification suggestions will be returned, and the creator will optimize and resubmit for review to ensure that the online service has no compliance and security risks.

[0039] Then, the service publishing module receives the approved MCP services to be published, completes the standardization transformation and call parameter configuration, and generates services accessible to clients. Specifically, it compiles the user-written service logic code into standardized SSE (Server Send Event) service addresses in real time, ensuring the uniqueness and traceability of each service address. It also configures the call parameters and structure, and automatically generates a unique call key, which is bound to the SSE service address as authentication credentials for subsequent client calls, preventing unauthorized access to the service. Finally, the permission allocation module configures fine-grained permission policies for the compiled SSE service addresses based on the insurance company's actual organizational structure and role system, completing the binding of permissions and services. After binding, the SSE service address is officially open for calls, and only clients that meet the permission policy (such as authorized role users under a specified organization) carrying a valid call key can initiate legitimate requests.

[0040] See the instruction manual appendix Figure 4 Based on the same inventive concept, this application also provides a method for accessing MCP services with permissions, applied to the aforementioned MCP service platform. The method includes the following steps: P1. In the internal network environment of the insurance company, the client user selects the target callable MCP service generated by the service publishing module through the interactive interface of the AI ​​big model service platform, inputs the calling parameters and calling key, and initiates a calling request to the SSE service address corresponding to the service. P2. The permission allocation module establishes an SSE connection after verifying the client user's permissions in one go based on a preset three-dimensional permission policy. P3. The server selects a normal HTTP response or upgrades to SSE streaming data transmission based on business needs to complete the service call.

[0041] Specifically, through a closed-loop process of request initiation, permission verification, and data transmission, the secure and efficient invocation of the MCP service is achieved, ensuring both compliance of permission control and adaptability to the data interaction needs of insurance business.

[0042] In step P1, initiating the call request is a prerequisite operation for the client user to trigger the MCP service call. The entire process is confined to the insurance company's internal network environment to ensure the security of request transmission. Specifically, the user must be on the company's intranet (such as an office LAN or VPN access), and direct calls from the public internet are prohibited. First, the user logs into the company's internal AI large-scale model service platform and filters and selects the target MCP service through the built-in service list interface. The service list clearly displays the service name, function description, and applicable business scenarios (such as health insurance underwriting data verification service and auto insurance claim information query service), and only displays published services visible within the user's permissions (pre-configured by the permission allocation module). Then, the user enters the complete call parameters according to the service's preset input parameter format (e.g., query services require the policy number and de-identified customer ID number; calculation services require the premium base and rate coefficient); simultaneously, the unique call key configured when the service was published is automatically associated (the user does not need to manually enter it; the platform automatically retrieves and attaches it), ensuring traceable call identity. After the user confirms that the parameters are correct, they click the call button. The platform automatically sends a request to the SSE service address corresponding to the target service (formatted as http: / / mcp.chinalife.com / sse / {service_id}) via POST / GET method (according to the call method configured when the service was published). The request message contains core information such as parameter information, call key, and user identity identifier (implicitly carried and not exposed to the outside world).

[0043] In step P2, permission verification is a core control step for call security. It is completed once by the permission allocation module before establishing the SSE long connection, avoiding efficiency losses caused by repeated verification after the connection is established. Specifically, after receiving the call request, the permission allocation module first extracts key information from the request message, including the client user's organizational unit (e.g., a provincial branch's auto insurance department in a certain city), associated role (e.g., a regular caller, a claims specialist), the {service_id} identifier of the target MCP service, and the call key, as the basic data for verification. Then, based on the extracted information, the permission allocation module filters valid five-tuple permission policies for the organization, role, and service from the permission database. If multiple policies exist, conflict resolution rules are automatically applied to determine the single policy that ultimately takes effect. Furthermore, dual validation is performed according to the effective policy: row-level validation: using Spring-EL syntax to parse row filtering rules, it verifies whether the data range requested by the user is within the authorized scope (e.g., only allowing access to car insurance business data in a certain province is permitted); column-level validation: according to column masking rules (e.g., regular expression masking, access denied), it verifies whether the output fields involved in the request are compliant (e.g., customer mobile phone numbers need to be masked for display, and core financial fields can only be viewed in plaintext by administrators). If both row-level and column-level validations pass, and the calling key is verified to be correct (completely matching the key configured when the service was published), then an SSE long connection is allowed to be established, and subsequent data transmission can proceed; if any validation fails (e.g., insufficient permissions, key mismatch, data access scope exceeding authorization), the call is directly rejected, a clear failure message is returned to the client, and no connection is established.

[0044] In step P3, the server selects the appropriate data transmission method based on business requirements to ensure efficient and accurate data interaction. Specifically, the server parses the business requirement type of the call request. If it is a short data volume, immediate response requirement, a normal HTTP response is returned, and the data is transmitted all at once in a preset output data structure. If it is a long data volume, real-time streaming requirement, the response is upgraded to SSE stream transmission to achieve data segmentation and continuous push, avoiding timeouts or lag caused by one-time transmission. Furthermore, the transmitted data strictly adheres to the column anonymization rules determined in the permission verification process. After data transmission is complete, the server returns a call success identifier and related metadata to the client (such as data transmission duration and the number of returned fields). If an exception occurs during transmission (such as network interruption or temporary service unavailability), an exception message and troubleshooting suggestions are returned (e.g., network instability, please retry), facilitating quick problem identification for users.

[0045] See the instruction manual appendix Figure 5 Based on the same inventive concept, this application also provides an MCP service visualization and statistical method, applied to the aforementioned MCP service platform, the method comprising the following steps: Q1. The large-screen data display module collects data in real time from the insurance company's internal database cluster, including the number of publications, the number of calls, the call ranking, and the failure rate generated by the MCP service creation module, the service publishing module, and the permission allocation module. Q2. Classify and aggregate the collected data according to the organizational structure, and display it through a large visualization screen.

[0046] Specifically, the screen data display module extracts data only from the insurance company's internal database cluster, with the data source covering the entire lifecycle of the MCP service. The service creation module generates records of services to be published, the service publishing module generates successful publishing logs, and the permission allocation module generates call verification records (including success / failure indicators), ensuring that the data comprehensively reflects the service's operational status.

[0047] The collected data is categorized and aggregated according to the core levels of the enterprise's multi-level branches. For example, the head office level displays aggregated data for the entire industry, the provincial branch level displays data for its own province and subordinate cities, and the city-level branch level displays detailed data for its local city. The aggregation logic is fully aligned with the enterprise's organizational structure, making it convenient for managers at all levels to view the operational status within their respective authority scopes. Furthermore, a combination of overview and detailed charts is used for display. For example, the overview area uses bar charts to compare the number of releases by province, line charts to show the trend of call volume across the entire platform, and leaderboards to present the top 10 most popular services / organizations with the highest call volume; the detailed area uses tables to display the call details of a single service, and the charts support switching time dimensions to meet the needs of different management scenarios. Top-down hierarchical drill-down operations are also supported. Administrators can click on the provincial data at the head office level to directly expand the detailed data of all city-level branches under that province, quickly locating specific areas of data anomalies or highlights.

[0048] In addition, this application also focuses on data access security and practical interaction, ensuring that data is only open to authorized objects, while supporting flexible operation in management scenarios. Specifically, access control is implemented as follows: Only users with administrator roles can access the dashboard data. Administrator roles are hierarchically divided (administrators at different levels can only view data within their corresponding level and subordinate organizations, and cannot access data from higher levels or other provinces / cities without authorization). Permission verification is linked to the platform's three-dimensional permission model of organization, role, and attribute to ensure precise permission control. Data details can be viewed in a pop-up window when an administrator clicks on any chart or data item on the dashboard. For example, clicking on the failure rate data of a service allows viewing the distribution of failure reasons (such as insufficient permissions, incorrect parameters, service anomalies) and specific failed call records (including call time, calling organization, and error code), providing a basis for troubleshooting. Data export functionality allows administrators to export data files as needed. The default export format is Excel, and the export range can be flexibly selected (full data, data from a specific level, data from a specific time period). Exported files automatically include metadata such as the exporter, export time, and data range. Export operations are recorded in the audit log, facilitating the tracking of data usage and ensuring that data is not illegally disseminated.

[0049] Based on the same concept of the present invention, the specification is attached. Figure 6 As shown in the figure, an embodiment of this application provides the structure of an electronic device 600, which includes: at least one processor 601, at least one network interface 604 or other user interface 603, memory 605, and at least one communication bus 602. The communication bus 602 is used to realize the connection and communication between these components. The electronic device 600 may optionally include a user interface 603, including a display (e.g., touch screen, LCD, CRT, holographic imaging, or projector, etc.), a keyboard, or a clicking device (e.g., mouse, trackball, touchpad, or touch screen, etc.).

[0050] Memory 605 may include read-only memory and random access memory, and provides instructions and data to processor 601. A portion of memory 605 may also include non-volatile random access memory (NVRAM).

[0051] In some implementations, memory 605 stores executable modules or data structures, or subsets thereof, or extended sets thereof: The 6051 operating system contains various system programs used to implement various basic business functions and handle hardware-based tasks. Application module 6052 contains various applications, such as desktop (launcher), media player (MediaPlayer), browser (Browser), etc., to implement various application services.

[0052] In this embodiment, by calling the program or instructions stored in the memory 605, the processor 601 executes steps such as in a method for authoritative publishing, calling and visual statistics of an MCP service platform, which can realize the closed-loop operation of the entire MCP service intranet, ensuring data security while meeting the usage needs of multi-level organizations.

[0053] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, performs steps such as those in a timeliness optimization method for a high-frequency, low-value internet payment system.

[0054] Specifically, the storage medium can be a general-purpose storage medium, such as a portable disk or hard disk. When the computer program on the storage medium is run, it can execute the aforementioned timeliness optimization method for the high-frequency, low-value internet payment system.

[0055] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and there may be other division methods in actual implementation. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the coupling or direct coupling or communication connection shown or discussed may be through some communication interface; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0056] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0057] In addition, the functional units in the embodiments provided in this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0058] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0059] Finally, it should be noted that the above embodiments are merely specific implementations of this application, used to illustrate the technical solutions of this application, and not to limit them. The protection scope of this application is not limited thereto. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this application; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application. All should be covered within the protection scope of this application. Therefore, the protection scope of this application should be determined by the protection scope of the claims.

Claims

1. An MCP service platform, characterized in that, Deployed on the insurance company's private cloud and running on the insurance company's internal network, including: The MCP service creation module provides a web interface for users to fill in MCP service details, edit service logic code, and initially set access permissions to generate an MCP service to be published. The service publishing module is used to compile the MCP service to be published into a standardized SSE service address, and configure the service call parameters and call key to form a callable MCP service; The permission allocation module is used to integrate the unified identity and organizational structure directory of insurance companies, build a three-dimensional permission model including organization, role and attribute, and configure permission control rules for callable MCP services; The large-screen data display module is used to collect the running data of the MCP service creation module, the service publishing module, and the permission allocation module in real time and display them visually.

2. The MCP service platform according to claim 1, characterized in that, The MCP service creation module, the service publishing module, the permission allocation module, and the large-screen data display module interact with each other through the Streamable HTTP protocol. The Streamable HTTP protocol is based on ordinary HTTP requests, allowing clients to initiate requests via POST / GET. The server upgrades the response to a server-sent event SSE stream according to business needs. The client and the server complete the request initiation and SSE stream reception through the same path.

3. The MCP service platform according to claim 2, characterized in that, The organizational information in the three-dimensional permission model is configured based on the six-level organizational unit data of the insurance company; the role information is configured based on the association between users, roles, and services, including service creators, service auditors, ordinary callers, and administrators. The attribute information is configured according to row and column labels, which include data access scope labels and access rule labels set for each MCP service; and the three-dimensional permission model is stored in the form of a five-tuple of organization, role, service, row filtering rule, and column desensitization rule.

4. The MCP service platform according to claim 3, characterized in that, The permission allocation module also sets permission conflict resolution rules based on permission type priority and scope priority.

5. A method for permission-based publishing of MCP services, characterized in that, Applied to the MCP service platform described in claim 4, the method includes the following steps: Users can fill in the name, function description and parameter description of the MCP service in Markdown format through the web interactive interface provided by the MCP service creation module, edit the service logic code, and initially set the access permission scope of the service to generate the MCP service to be published. The generated MCP service to be published is subjected to security verification and compliance review, and the service publication process is triggered after the review is passed; The service publishing module compiles the approved MCP service to be published into an SSE service address in a set format, and configures the input parameter format, output data structure and calling key of the service call to generate a callable MCP service. The permission allocation module configures a three-dimensional permission policy, including organization, role, and attribute, for the generated callable MCP service based on the insurance company's organizational structure and user roles, thereby enabling the SSE service address to be called.

6. A method for permission-based invocation of MCP services, characterized in that, Applied to the MCP service platform described in claim 4, the method includes the following steps: In the internal network environment of an insurance company, client users select the target callable MCP service generated by the service publishing module through the interactive interface of the AI ​​big model service platform, input the calling parameters and calling key, and initiate a calling request to the SSE service address corresponding to the service. The permission allocation module establishes an SSE connection after verifying the client user's permissions in one go, based on a preset three-dimensional permission policy. The server selects between a standard HTTP response and an SSE streaming service to complete the service call, depending on the business requirements.

7. A method for visualizing and statistically analyzing MCP services, characterized in that, Applied to the MCP service platform described in claim 4, the method includes the following steps: The large-screen data display module collects real-time data on the number of publications, the number of calls, the call ranking, and the failure rate generated by the MCP service creation module, the service publishing module, and the permission allocation module from the insurance company's internal database cluster. The collected data is categorized and aggregated according to the organizational structure and then displayed on a large visual dashboard.

8. The MCP service visualization and statistical method according to claim 7, characterized in that, in, Grant users with the role of administrator access to or export of the data displayed on the large screen.

9. An electronic device, characterized in that, include: The device includes a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the memory via the bus. When the machine-readable instructions are executed by the processor, they perform the steps of an MCP service permission-based publishing, invocation, and visualization statistics method as described in any one of claims 5 to 8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the steps of an MCP service permissioned publishing, invocation, and visualization statistics method as described in any one of claims 5 to 8.

Images