Article body
Full article
Introduction
At the end of 2024, Anthropic released the Model Context Protocol (MCP), which quickly became the “USB-C interface” of the AI Agent ecosystem. The protocol addresses a longstanding pain point: every time an external tool is connected, Agent developers have to write a custom set of integration code. MCP aims to standardize this process, allowing any AI Agent to connect to any external tool through a unified protocol.
For BI Agents, the protocol is especially significant. BI analysis inherently needs to interact with many external systems: querying databases, calling APIs, sending emails, writing files, and triggering workflows. If each integration requires custom development, the Agent’s extensibility becomes a bottleneck.
In its latest release, HENGSHI Data Agent introduced MCP support, moving the Agent tool ecosystem from “closed, built-in capabilities” to “open standards.” This article provides an in-depth analysis of MCP’s technical architecture, implementation practices, and ecosystem value in BI Agent scenarios.
I. A Review of MCP’s Core Concepts
1.1 What Problem Does MCP Solve?
Before MCP, the pattern for connecting AI Agents to external tools was an “N × M problem”: N Agents × M tools = N×M sets of integration code. Every new tool required every Agent to develop a new integration; every new Agent required every tool to be adapted again.
MCP reduces this to “N + M”: Agents only need to implement an MCP client, tools only need to implement an MCP server, and the two communicate through a standard protocol.
1.2 MCP’s Three Core Primitives
The MCP protocol defines three interaction primitives:
Tools: Functions that an Agent can call proactively, such as “execute an SQL query,” “retrieve a metric definition,” or “send an alert email.” Each Tool uses a standardized JSON Schema to describe its input parameters and return format.
Resources: Contextual data that an Agent can read, such as “the current user’s permission configuration,” “a dataset’s Schema information,” or “a metric dictionary.” Resources are passive: the Agent reads them as needed, and doing so does not trigger side effects.
Prompts: Predefined prompt templates used to guide an Agent toward more accurate output in particular situations, such as a “sales analysis report template” or an “anomaly attribution analysis template.”
1.3 Communication Architecture
MCP uses a Client-Server architecture:
- MCP Host: The host program that runs the AI Agent, such as the HENGSHI Data Agent runtime
- MCP Client: The protocol client embedded in the Host that is responsible for communicating with external Servers
- MCP Server: An independent tool service process that exposes Tools, Resources, and Prompts
The transport layer supports two modes: stdio for local inter-process communication and HTTP+SSE for remote network communication.
II. MCP Integration Architecture in HENGSHI Data Agent
2.1 Overall Architecture
HENGSHI Data Agent’s MCP integration architecture has four layers:
Layer 1: Agent reasoning engine. It is responsible for intent understanding, task planning, and tool selection. When a user submits an analysis request, the reasoning engine decides which tools are needed and in what sequence to call them.
Layer 2: MCP Client layer. The Agent reasoning engine does not call tools directly. Instead, it uses the MCP Client to send requests to registered MCP Servers. The MCP Client manages all Server connections, handles timeout retries, and converts result formats.
Layer 3: MCP Server ecosystem. It includes two types of Servers:
- Built-in Servers: HENGSHI’s built-in BI toolset, including the “data query Server,” “metric definition Server,” “chart generation Server,” and “report export Server”
- External Servers: Tools provided by third parties, such as the “Slack notification Server,” “Jira ticket Server,” and “enterprise OA approval Server”
Layer 4: Tool execution layer. Each MCP Server encapsulates the specific implementation logic for tools, including connecting to databases, calling APIs, and generating files.
2.2 Built-in MCP Server Inventory
HENGSHI Data Agent registers the following built-in MCP Servers by default:
Data Query Server:
- Tool:
query_dataset: Query data by dataset name and filter conditions - Tool:
execute_sql: Execute SQL directly, subject to permission sandbox controls - Resource:
dataset_schema: Return the field definitions and types of a specified dataset - Resource:
dataset_metadata: Return the update time, row count, and data source of a dataset
Metric Management Server:
- Tool:
get_metric_definition: Retrieve a metric’s calculation definition and associated dataset - Tool:
compare_metrics: Compare differences between two metrics across dimensions - Resource:
metric_catalog: Return the complete metric catalog tree - Resource:
metric_lineage: Return a metric’s lineage, including the base fields on which it depends
Visualization Server:
- Tool:
create_chart: Generate a visualization based on chart type and data - Tool:
export_dashboard: Export a dashboard as an image or PDF - Resource:
chart_templates: Return a list of available chart templates
Collaboration and Distribution Server:
- Tool:
send_notification: Send analysis results to specified users or groups - Tool:
schedule_report: Create a scheduled report task - Tool:
create_subscription: Create a data subscription for a user
2.3 Process for Connecting External MCP Servers
Enterprises can connect third-party MCP Servers as needed. A typical process is as follows:
Step 1: Register the Server configuration. Enter the MCP Server connection information in the HENGSHI administration console: name, transport method (stdio/HTTP), startup command or URL, and authentication credentials.
Step 2: Discover capabilities. When the Agent starts, the MCP Client sends an initialize request to the newly registered Server to retrieve its list of Tools, Resources, and Prompts. These capabilities are automatically registered in the Agent’s tool catalog.
Step 3: Configure permissions. Administrators configure the user scope and operation permissions for each MCP Server. For example, the “Jira Server” is available only to project management roles, while the “financial system Server” is available only to the finance department.
Step 4: Route dynamically. During reasoning, the Agent selects the appropriate Tool from the tool catalog according to user intent. Its selection logic considers factors including the Tool description, parameter match quality, and historical call success rate.
III. Typical MCP Applications in BI Scenarios
3.1 Scenario 1: Automatically Create a Jira Ticket from Analysis Results
Business scenario: An operations team uses Data Agent to analyze user churn trends and finds an abnormal drop in 7-day retention for a product line. The Agent not only provides an analysis conclusion, but also automatically creates a Bug ticket in Jira with the analysis data and suggested investigation directions.
Technical implementation:
- Connect a Jira MCP Server, using a community open-source version
- When the Agent reasoning engine identifies “this is an issue that requires R&D follow-up,” it calls the Jira Server’s
create_issueTool - The Agent automatically generates the ticket title from the analysis conclusion, and the ticket description includes key data metrics and a link to chart screenshots
- The Agent automatically determines ticket priority based on impact scope, marking it P1 when the number of affected users is > 10000
Key design point: The Agent does not create tickets indiscriminately. Its reasoning engine includes an “action decision layer” that decides whether to trigger an external operation based on the severity and impact scope of the analysis conclusion and historical patterns. This avoids the noise problem of “creating a pile of tickets after every analysis.”
3.2 Scenario 2: Cross-System Linked Data Analysis
Business scenario: A sales director asks the Agent, “Why did South China sales performance fail to meet target last month?” The Agent not only queries HENGSHI BI sales data, but also automatically calls customer follow-up records in the CRM system and inventory data in the ERP system for multidimensional cross-analysis.
Technical implementation:
- Connect CRM and ERP MCP Servers, built by the enterprise
- The Agent reasoning engine plans a three-step task: query sales data → query customer follow-up status → query inventory availability
- The three queries call Tools from different Servers, and their results are associated and analyzed at the Agent layer
- The Agent draws a conclusion from the three data sources: “The main reason South China sales failed to meet target is delayed delivery of an order from key customer A. CRM records show the follow-up status as ‘waiting for sample confirmation,’ while insufficient inventory in the South China warehouse delayed replenishment. ERP shows inventory turnover days above the threshold.”
Key design point: The challenge of cross-system queries is not the calls themselves, but relating the results. The Agent needs to understand the semantic correspondence between fields in different systems, such as the CRM’s “customer number” and BI’s “customer ID” being the same concept. HENGSHI resolves this with the unified identification mechanism of the metric semantic layer.
3.3 Scenario 3: Automatically Push Analysis Reports to WeCom
Business scenario: At 8:00 every Monday morning, the Agent automatically runs a weekly business analysis, generates a report, and pushes it to a WeCom management group.
Technical implementation:
- Connect a WeCom MCP Server
- The Agent’s scheduled task engine triggers the analysis flow at 7:30 on Monday
- The Agent calls the Data Query Server to obtain this week’s key metrics, the Metric Management Server to obtain month-over-month and year-over-year baselines, and the Visualization Server to generate trend charts
- It finally calls the WeCom Server’s
send_group_messageTool to push the report as a card message to the specified group - Group members can click the card to open the complete HENGSHI BI dashboard directly
Key design point: Scheduled tasks plus multi-tool orchestration are JARVIS’s core capability. The MCP protocol turns external notification channels into standard tools, with no need to develop custom push logic.
IV. Security Design for MCP Integration
4.1 Permission Sandbox for Tool Calls
MCP’s openness brings security challenges: if any Agent can call any tool, the risk is self-evident. HENGSHI applies three layers of security control:
Layer 1: Server-level access control. Each MCP Server is configured with a list of roles allowed to access it. Agents for ordinary user roles can access only built-in Servers; external Servers require explicit administrator authorization.
Layer 2: Tool-level behavior audit. Every Tool call produces a complete audit log: who called which Tool, the parameters passed, the result returned, and the elapsed time. Alert rules can be configured for audit logs, such as triggering a security alert when a write-operation Tool is called outside working hours.
Layer 3: Parameter-level security validation. For sensitive Tools such as execute_sql, the MCP Server validates parameters internally: SQL statements must pass SQL injection detection, table names must be within the authorized scope, and result-set rows have an upper limit.
4.2 Data Exfiltration Protection
External MCP Servers may be provided by third parties, creating a risk that data sent to an external Server could be leaked. HENGSHI’s protection strategies are:
- Outbound data masking: When an Agent calls a Tool on an external Server, sensitive data in parameters, including mobile numbers, ID card numbers, and amounts, is automatically masked
- Allowlist mechanism: Only external Servers approved by administrators may receive unmasked data
- Traffic auditing: Request bodies sent to external Servers are stored for auditing, allowing the security team to review them periodically
V. Future Outlook for the MCP Ecosystem
5.1 From “Built-in Tools” to a “Tool Marketplace”
The long-term value of MCP lies in its ecosystem effect. As more and more tools are released as MCP Servers, the capability boundary of BI Agents will expand exponentially.
Imagine a future scenario: enterprise administrators browse available Servers in an “MCP tool marketplace,” including Salesforce connectors, SAP data interfaces, Tianyancha enterprise information queries, and Amap geographic analysis. With one-click installation, the Agent immediately gains new capabilities. This is the direction of the MCP ecosystem.
5.2 The “Plugin-Based” Evolution of BI Agents
MCP evolves BI Agents from “products with fixed functions” into “extensible platforms.” HENGSHI Data Agent is no longer positioned as a closed analysis tool, but as a combination of an “analysis reasoning engine + an unlimited tool ecosystem.”
Enterprises can assemble their own Agent capability stack as needed: use built-in Servers for basic analysis, self-built Servers for industry-specific analysis, and community open-source Servers for general office collaboration. Every enterprise’s Agent is unique.
5.3 Interoperability Brought by Standardization
Another far-reaching effect of MCP is interoperability between Agents. When all Agents support MCP, Agents from different vendors can share the same tool ecosystem. Enterprises are not locked into a single Agent platform: when they switch Agents, tool configurations can migrate smoothly.
VI. Conclusion
For BI Agents, MCP is as significant as REST APIs are for web applications. It changes tool integration from “one-to-one customization” to “standard protocol integration,” turning Agent capability expansion from an engineering problem into a configuration problem.
The core value of HENGSHI Data Agent’s MCP integration architecture lies at three levels:
- For developers: No integration code is required. Connecting a new tool only requires registering an MCP Server configuration
- For enterprises: Assemble a tool ecosystem as needed without being locked into a fixed set of functions
- For the ecosystem: Connect with the broader AI Agent community and share the results of tool innovation
When the tool boundaries of BI Agents are fully opened, the possibilities for data analysis can truly be unleashed.
This is the 43rd article in the HENGSHI BI technology series. To learn about the technical architecture and multi-agent collaboration mechanism of HENGSHI Data Agent, please refer to our related thematic articles.