Internet of Things equipment tool capability expansion method and system based on MCP protocol

Abstract

The invention provides an Internet of Things equipment tool capability expansion method and system based on an MCP protocol. Comprising the following steps: S1, establishing WebSocket or MQTT communication connection between an Internet of Things device and a cloud service; s2, packaging a JSON-RPC message of a standard MCP protocol into an equipment communication protocol message, and performing bidirectional transparent transmission through the communication connection; and S3, the cloud service completes MCP initialization handshake with the Internet of Things equipment through the MCP initialized message and the tools / list message, and obtains a hardware tool list registered at the Internet of Things equipment end, the resource limitation is broken through, the limited IoT equipment such as ESP32 does not need to operate a complete MCP server, the MCP message is transparently transmitted through WebSocket / MQTT, the equipment hardware capability is exposed to the LLM in a standard MCP tool form for the first time, and the hardware capability of the equipment is exposed to the LLM in a standard MCP tool form. The access threshold is greatly reduced, the LLM does not need to perceive the source difference of local and remote MCP and equipment end tools when calling tools through the universal MCPClient interface and the unified registry, development is simplified, and the maintenance cost is reduced.

Description

Technical Field

[0001] This invention relates to the field of IoT device and artificial intelligence interaction technology, and in particular to a method and system for extending the capabilities of IoT device tools based on the MCP protocol. Background Technology

[0002] Large language models have entered the stage of intelligent agents that call tools. The MCP protocol released by Anthropic, as an important standard in the AIAgent field, has established a standardized interaction interface for large models and external tools, and is widely supported by mainstream AI vendors. Meanwhile, IoT devices such as ESP32 possess rich hardware capabilities such as cameras and sensors. If they can be called by cloud-based large models, it will greatly expand the functional boundaries of AI assistants. Currently, large models can call local tools and remote MCP server tools, but existing technologies still have many shortcomings: resource-constrained IoT devices, lacking a complete runtime environment, cannot run standard MCP servers, making it difficult to participate in the MCP tool ecosystem; the calling methods and protocols for local, remote, and device-side tools differ, leading to fragmented management and increased system complexity; the MCP connection initialization steps are cumbersome, easily causing resource consumption peaks and connection storms under high concurrency, increasing interaction latency; name conflicts easily occur with tools from multiple sources, and device-side tool naming is also incompatible with LLM specifications; device-side tool calls rely on shared communication connections, and there is a lack of mature solutions for asynchronous and timeout handling, affecting the reliability of the calls. Summary of the Invention

[0003] In view of this, in order to solve the problems existing in the technical background, the present invention proposes... A method for extending the capabilities of IoT device tools based on the MCP protocol includes the following steps: S1 establishes a WebSocket or MQTT communication connection between IoT devices and cloud services; S2, encapsulate the standard MCP protocol JSON-RPC message into a device communication protocol message and transmit it bidirectionally through the communication connection; S3, the cloud service completes the MCP initialization handshake with the IoT device through the MCP initialize message and tools / list message to obtain the list of hardware tools registered on the IoT device; S4 registers device-side hardware tools, local tools, and remote MCP server tools into the function registry, allowing the large language model to obtain a complete list of tools through the Function Calling interface. In S5, when the large language model calls a tool during inference, the tool manager iterates through all tool clients, finds the client that owns the tool, executes the call, and returns the result to the large language model to continue inference.

[0004] Furthermore, in step S2, the specific method for encapsulating the standard MCP protocol JSON-RPC message into a device communication protocol message is as follows: a type identifier field is set on the outer layer of the device communication protocol message, with the value of the field being "mcp", and the MCP JSON-RPC message is used as the value of the outer payload field; and the MCP message pass-through includes an asynchronous request-response matching mechanism, specifically: Assign an auto-incrementing unique ID to each MCP tool call request, and create a corresponding result channel to store in a mapping table; Send an MCP tools / call request carrying the ID via the device communication connection; When a device returns a message, the ID field in the message is extracted, the corresponding result channel is looked up in the mapping table, and the result is delivered. The caller can return a result through the select multi-way waiting result channel, cancel the waiting context, or trigger a waiting timeout timer. When a timeout occurs or the connection is lost, the corresponding entry in the mapping table will be automatically cleared.

[0005] Furthermore, the MCP initialization handshake support tool list is paginated, and the specific process is as follows: After sending a tools / list request, if the response data returned by the device contains a non-empty nextCursor field, a subsequent tools / list request carrying the cursor parameter will be automatically constructed to continue obtaining the list. The system iterates through the requests until the device's response does not contain the nextCursor field or the nextCursor is empty, aggregating all tools into a complete tool list. The capabilities field of the initialize message carries the access address and authentication token for the visual recognition service, enabling IoT devices to directly invoke the cloud-based visual recognition service when performing tool operations.

[0006] Furthermore, it also includes a tool name normalization step: performing normalization processing on the device-side tool name, replacing characters not supported by the large language model Function Calling specification with underscore characters; maintaining a tool name mapping table to record the mapping relationship between the normalized name and the original name; registering and exposing the use of the normalized name externally, and restoring the original name through the mapping table when sending an MCP request to the device.

[0007] Furthermore, in S5, the tool manager adopts a pre-initialization-delayed binding strategy: when the system starts, multiple tool manager instances are created and added to the resource pool. Each instance completes local tool registration and remote MCP server connection initialization in advance when it is created. When an IoT device connects, the pre-initialized tool manager instance is obtained from the resource pool, and only reference binding operations are performed to bind the device connection and function processor to the manager instance. The reference binding operations include setting connection references, creating or binding device-side MCP clients, performing health checks on remote MCP clients, and registering tools for all ready clients.

[0008] Furthermore, the resource pool adopts a "return to old and innovate" recycling strategy: when a tool manager instance is returned, the old instance is not put back into the resource pool; a new tool manager instance is created asynchronously, and the new instance is put into the resource pool after performing a complete pre-initialization; the old instance performs a cleanup operation, and all MCP client connections are closed in sequence.

[0009] Furthermore, the three types of tool clients—device-side, local, and remote MCP server—share a unified client interface, which includes a start method, a stop method, a tool query method, a tool list retrieval method, a tool invocation method, a readiness check method, and a health check method.

[0010] An IoT device tool capability extension system based on the MCP protocol includes: a device-side MCP client module, used to encapsulate JSON-RPC messages of the MCP protocol into the device communication protocol for transparent transmission, perform initial handshake and tool discovery with IoT devices, and realize asynchronous request-response matching and tool name normalization mapping; a local tool client module, used to manage local tool functions directly called within the server process; a remote MCP server client module, used to connect to a remote MCP server via stdio, SSE, or StreamableHTTP to obtain and call remote tools; a tool manager module, used to manage the above three types of tool clients, realizing unified tool registration, discovery, and scheduling; a resource pool module, used to pre-create and cache tool manager instances, realizing a pre-initialization-delayed binding strategy; and a function registry module, used to uniformly store tool information from all sources, providing a complete tool list for large language model function calling. The device-side MCP client module also includes a connection adapter submodule, which includes an MQTT connection adapter and a WebSocket connection adapter, used to adapt different types of device communication connections to a unified message sending interface.

[0011] The above technical solution has the following beneficial effects: This invention overcomes resource limitations, allowing restricted IoT devices such as ESP32 to transmit MCP messages via WebSocket / MQTT without running a complete MCP server. For the first time, it exposes device hardware capabilities to LLM in the form of a standard MCP tool, significantly reducing the access barrier.

[0012] We have created a unified management system for tools from three sources. Through the universal MCPClient interface and a unified registry, LLMs can call tools without being aware of the differences in the sources of local, remote MCPs, and device-side tools, thus simplifying development and reducing maintenance costs.

[0013] The pre-initialization + delayed binding strategy moves the time-consuming MCP initialization to the system startup stage, and only performs millisecond-level reference binding when the device connects. In high-concurrency scenarios with 3000+ devices, it completely avoids connection storms and initial interaction delays.

[0014] Tool name conflicts are resolved by using naming prefixes for isolation, and device-side tool names are made compatible with the LLM specification through character substitution and mapping tables. Meanwhile, reliable MCP request-response matching is achieved on device shared connections by relying on auto-incrementing IDs, result channels, and timeout mechanisms.

[0015] Visual service information is transmitted during the initial handshake, creating a complete closed loop from device hardware to MCP protocol to AI visual recognition to LLM inference. This expands the boundaries of intelligent interaction between IoT devices and AI, and multiple connection adapters adapt to different device communication methods, improving system compatibility. Attached Figure Description

[0016] Figure 1 This is a diagram of a unified scheduling architecture for three-source tools in an IoT device tool capability extension method and system based on the MCP protocol, as presented in this invention. Figure 2 This is a diagram illustrating the device-side MCP protocol transparent message encapsulation of an IoT device tool capability extension method and system based on the MCP protocol according to the present invention. Figure 3 This is a timing diagram of the MCP initialization handshake for an IoT device tool capability extension method and system based on the MCP protocol according to the present invention. Figure 4 This is a flowchart illustrating the asynchronous request-response matching process of an IoT device tool capability extension method and system based on the MCP protocol, as presented in this invention. Figure 5 This invention provides a timing diagram of the MCPManager pre-initialization-delayed binding mechanism for an IoT device tool capability extension method and system based on the MCP protocol. Figure 6This is a flowchart of the MCP resource "return to old and innovate" strategy of an IoT device tool capability extension method and system based on the MCP protocol according to the present invention. Figure 7 This is a schematic diagram illustrating the tool name mapping and namespace isolation of an IoT device tool capability extension method and system based on the MCP protocol according to the present invention. Figure 8 This invention presents a Vision capability extension link diagram for an IoT device tool capability extension method and system based on the MCP protocol. Figure 9 This is a unified tool scheduling flowchart of an IoT device tool capability extension method and system based on the MCP protocol according to the present invention. Detailed Implementation

[0017] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0018] Example 1, see Figures 1-9 The method for extending the capabilities of IoT devices based on the MCP protocol, as shown, includes the following steps: S1 establishes a WebSocket or MQTT communication connection between IoT devices and cloud services; S2, encapsulate the standard MCP protocol JSON-RPC message into a device communication protocol message and transmit it bidirectionally through the communication connection; S3, the cloud service completes the MCP initialization handshake with the IoT device through the MCP initialize message and tools / list message to obtain the list of hardware tools registered on the IoT device; S4 registers device-side hardware tools, local tools, and remote MCP server tools into the function registry, allowing the large language model to obtain a complete list of tools through the Function Calling interface. In S5, when the large language model calls a tool during inference, the tool manager iterates through all tool clients, finds the client that owns the tool, executes the call, and returns the result to the large language model to continue inference.

[0019] Example 2, based on Example 1, in this example, the specific method for encapsulating the standard MCP protocol JSON-RPC message into a device communication protocol message in step S2 is as follows: a type identifier field is set on the outer layer of the device communication protocol message, the value of which is "mcp", and the MCP JSON-RPC message is used as the value of the outer payload field; and the MCP message pass-through includes an asynchronous request-response matching mechanism, specifically: Assign an auto-incrementing unique ID to each MCP tool call request, and create a corresponding result channel to store in a mapping table; Send an MCP tools / call request carrying the ID via the device communication connection; When a device returns a message, the ID field in the message is extracted, the corresponding result channel is looked up in the mapping table, and the result is delivered. The caller can return a result through the select multi-way waiting result channel, cancel the waiting context, or trigger a waiting timeout timer. When a timeout occurs or the connection is lost, the corresponding entry in the mapping table will be automatically cleared.

[0020] Furthermore, the MCP initialization handshake support tool list is paginated, and the specific process is as follows: After sending a tools / list request, if the response data returned by the device contains a non-empty nextCursor field, a subsequent tools / list request carrying the cursor parameter will be automatically constructed to continue obtaining the list. The system iterates through the requests until the device's response does not contain the nextCursor field or the nextCursor is empty, aggregating all tools into a complete tool list. The capabilities field of the initialize message carries the access address and authentication token for the visual recognition service, enabling IoT devices to directly invoke the cloud-based visual recognition service when performing tool operations.

[0021] Example 3, based on Example 1, further includes a tool name normalization step: performing normalization processing on the device-side tool name, replacing characters not supported by the Large Language Model Function Calling specification with underscore characters; maintaining a tool name mapping table to record the mapping relationship between the normalized name and the original name; registering and exposing the use of the normalized name externally, and restoring the original name through the mapping table when sending an MCP request to the device.

[0022] In S5, the tool manager adopts a pre-initialization-delayed binding strategy: when the system starts, multiple tool manager instances are created and added to the resource pool. Each instance completes local tool registration and remote MCP server connection initialization in advance when it is created. When an IoT device connects, the pre-initialized tool manager instance is obtained from the resource pool, and only reference binding operations are performed to bind the device connection and function processor to the manager instance. The reference binding operations include setting connection references, creating or binding device-side MCP clients, performing health checks on remote MCP clients, and registering tools for all ready clients.

[0023] Example 4, based on Example 1, employs a "return to old and innovate" recycling strategy for the resource pool: when a tool manager instance is returned, the old instance is not put back into the resource pool; a new tool manager instance is created asynchronously, and the new instance is placed into the resource pool after performing a complete pre-initialization; the old instance undergoes a cleanup operation, sequentially closing all MCP client connections. The three types of tool clients—device-side, local, and remote MCP server—share a unified client interface, which includes a start method, a stop method, a tool query method, a tool list retrieval method, a tool invocation method, a readiness check method, and a health check method.

[0024] An IoT device tool capability extension system based on the MCP protocol includes: a device-side MCP client module, used to encapsulate JSON-RPC messages of the MCP protocol into the device communication protocol for transparent transmission, perform initial handshake and tool discovery with IoT devices, and realize asynchronous request-response matching and tool name normalization mapping; a local tool client module, used to manage local tool functions directly called within the server process; a remote MCP server client module, used to connect to a remote MCP server via stdio, SSE, or StreamableHTTP to obtain and call remote tools; a tool manager module, used to manage the above three types of tool clients, realizing unified tool registration, discovery, and scheduling; a resource pool module, used to pre-create and cache tool manager instances, realizing a pre-initialization-delayed binding strategy; and a function registry module, used to uniformly store tool information from all sources, providing a complete tool list for large language model function calling. The device-side MCP client module also includes a connection adapter submodule, which includes an MQTT connection adapter and a WebSocket connection adapter, used to adapt different types of device communication connections to a unified message sending interface.

[0025] The three types of clients share a unified MCPClient interface definition: interface MCPClient { Start(ctx context.Context) error / / Start the client and perform initialization Stop() / / Stop the client and release resources HasTool(name string) bool / / Checks if a tool with the specified name exists. GetAvailableTools() []Tool / / Retrieves a list of all available tools (OpenAI Tool format) CallTool(ctx, name, args) (result, error) / / Calls the specified tool and returns the result. IsReady() bool / / Checks if the client has finished initializing CheckHealth(ctx context.Context) error / / Health check ResetConnection() error / / Reset connection state Type() string / / Returns the client type identifier } Regardless of the source of the tool, the Manager only needs to iterate through all MCPClients and call the same interface method to complete the discovery, registration, and invocation of the tool.

[0026] XiaoZhiMCPClient embeds JSON-RPC messages of the standard MCP protocol into existing device communication connections (WebSocket or MQTT) for transmission, enabling resource-constrained IoT devices to participate in the MCP tool ecosystem without running a complete MCP server.

[0027] Wrap the MCP JSON-RPC message in the message body of the device communication protocol, and use the outer type field for message type identification and routing: { "type": "mcp", "session_id": "device-session-xxx", "payload": { "jsonrpc": "2.0", "id": 1, "method": "initialize", "params": { ...} }} The outer type field indicates that this is an MCP protocol message, enabling the device communication message dispatcher to route it to the MCP processing module, rather than ordinary voice dialogue processing logic (such as audio listening messages with type "listen", text chat messages with type "chat", etc.). The outer session_id field identifies the current communication session and is used to associate the device connection and the MCP client instance; Inner payload field: Standard MCP JSON-RPC 2.0 message body, fully compliant with MCP protocol specifications, including jsonrpc version number, request ID, method name, and params parameters.

[0028] Initialization handshake process: After the device connects to the server via WebSocket or MQTT, XiaoZhiMCPClient executes the following initialization handshake sequence: Step I1: XiaoZhiMCPClient constructs an MCP initialize message (id=1), carries a vision capability declaration (including the URL of the vision recognition service and a JWT access token) in params.capabilities, and sends it to the device via the device communication connection: { "type": "mcp", "payload": { "jsonrpc": "2.0", "id": 1, "method": "initialize", "params": { "protocolVersion": "2024-11-05", "capabilities": { "roots": { "listChanged": true}, "sampling": {}, "vision": { "url": "http: / / server:8080 / vision", "token": "jwt_token_xxx" } }, "clientInfo": { "name": "XiaozhiClient", "version": "1.0.0" } } } } After receiving the initialize request, the device returns server information and capability declarations (including serverInfo.name and serverInfo.version). After receiving the initialize response (matched by payload.id == 1), XiaoZhiMCPClient parses the server information and then sends a tools / list request (id=2) to obtain the list of tools supported by the device. The device returns a list of tools, each tool containing name, description, and inputSchema (a parameter pattern in JSON Schema format, containing type, properties, and required fields). If the tool list data returned by the device contains a nextCursor field and is not empty, XiaoZhiMCPClient automatically constructs a subsequent tools / list request carrying the cursor parameter, and retrieves it in a loop until no nextCursor is returned. Once all tools have been retrieved, XiaoZhiMCPClient marks the ready state as true and notifies the Manager to register the tools via a callback function (onFetchToolsDone).

[0029] Because the device communication connection is shared (the same WebSocket / MQTT connection simultaneously transmits voice audio frames, text chat messages, and MCP protocol messages), MCP requests and responses need to be associated through a precise ID matching mechanism: callResults: map[int]chan interface{} / / Mapping table of request ID → result channel callResultsLock: Mutex / / A mutex lock to protect the mapping table nextID: int / / An auto-incrementing request ID counter Request sending process: 1. Acquire the callResultsLock lock, assign an auto-incrementing ID, create a buffered (size 1) result channel resultCh, store it in the callResults[id] mapping table, and release the lock; 2. Construct an MCP tools / call JSON-RPC request message, setting payload.id to the assigned ID; 3. Send requests via the device communication connection (conn.WriteMessage); 4. The caller enters a select multi-way wait: - Wait for resultCh to receive the result → Return the result; - Wait for ctx.Done() (context cancellation) → Clean up callResults[id] and return a cancellation error; - Wait for time.After(30 seconds) (timeout timer) → Clean up callResults[id] and return a timeout error.

[0030] Response reception process (HandleMCPMessage method): 1. Parse the payload field of the message returned by the device; 2. If the payload contains a result field (indicating a successful response) or an error field (indicating an error response), extract payload.id; 3. Acquire the callResultsLock and look up callResults[id]; 4. If the corresponding resultCh is found → push the result (or error) into resultCh and delete the entry from callResults; 5. If not found (may have timed out and been cleaned up) → ignore the response; 6. For the initialization response (id == mcpInitializeID) and the tool list response (id == mcpToolsListID), execute specific processing logic (such as triggering subsequent tools / list requests or marking the ready state).

[0031] Exception handling: - If sending fails (conn.WriteMessage returns an error), immediately clean up the entries in callResults to prevent memory leaks; - When the device disconnects, the Stop method iterates through all unfinished callResults, closes all resultCh channels, and notifies waiting callers; - All critical operations include panic recovery (defer recover) to prevent a single tool call anomaly from affecting the entire connection.

[0032] Device-side tool names may contain special characters not supported by LLM Function Calling, thus requiring a name mapping mechanism: Input: Original tool name (e.g., "self.camera.take_photo") Processing: Replace all period characters "." with underscores "_". Output: The normalized name (e.g., "self_camera_take_photo") When obtaining the tool list (step I4), for each device-side tool: 1. Call sanitizeToolName to obtain the normalized name; 2. Store the mapping relationship in toolNameMap (e.g., "self_camera_take_photo" → "self.camera.take_photo"); 3. Use standardized names when externally displayed (registered with the Function Registry and exposed to LLMs); 4. Use the original name for the device (construct the MCP tools / call request).

[0033] Name restoration process when calling a tool: 1. LLM decides to call the tool "self_camera_take_photo"; 2. XiaoZhiMCPClient.CallTool receives the request and queries the toolNameMap to obtain the original name "self.camera.take_photo"; 3. Construct an MCP tools / call request using the original name and send it to the device; 4. The device is unaware of the existence of name standardization and uses its native tool name to process requests.

[0034] To enable MCP messages to be transmitted through different transmission channels, two connection adapters were designed: MCPConnAdapter (MQTT Adapter): - Implement the WriteMessage method of the Conn interface; - Send MCP messages to the MQTT topics subscribed to by the device using the sendPublish method of MQTTClient; - Suitable for devices connected via MQTT+UDP dual-channel connection.

[0035] WSRWAdapter (WebSocket adapter): - Adapt the WebSocket connection to the io.ReadWriteCloser interface; - Asynchronous read and write communication is achieved through independent read and write coroutines (readLoop and writeLoop); - Enables the standard mcp-go library's client to work directly through the WebSocket channel; - Suitable for devices connected via WebSocket.

[0036] The results returned by the device-side tool are passed through the content field. XiaoZhiMCPClient supports two result processing modes: Mode 1: Text Result - Extract content[0].text, encapsulate it as ActionResponse(Action=ActionTypeReqLLM), and return the text result to LLM for further reasoning. For example, the device returns sensor data "Temperature: 25.3℃, Humidity: 60%".

[0037] Mode 2: Trigger subsequent actions - For a specific tool (such as taking a photo), extract content[0].text (containing the image URL or data), encapsulate it into ActionResponse (Action=ActionTypeCallHandler, FuncName="mcp_handler_take_photo"), and trigger the server-side visual recognition process (upload image → call Vision service → return recognition result to LLM).

[0038] Design principles of MCP Manager pooling and pre-initialization-delayed binding mechanism The lifecycle of MCP Manager is divided into two phases: Pre-initialization phase: All time-consuming operations (external MCP server connection, tool discovery, etc.) are completed during system startup, and the results are cached in the resource pool; Lazy Binding: Only lightweight reference binding operations (in milliseconds) are performed when a device connects, without the need for repeated initialization.

[0039] During the pre-initialization phase (NewManagerForPool), when the system starts, the resource pool factory (MCPFactory) creates multiple MCP Manager instances (10 by default, maximum 9999). Each Manager executes the preInitializeServers method upon creation. Create a LocalClient instance, register the local utility functions enabled in the configuration file (such as local_exit, local_time, local_switch_voice, etc.), and call the Start method to add it to the ready state; Read the MCP server configuration file (.mcp_server_settings.json) and parse the mcpServers configuration items; For each configured external MCP server: - Check the enabled flag and skip servers that are disabled; - Create a Client of the corresponding type based on the configured transport method: - If the command field is configured → Create a stdio type client (start a child process); - If the url field is configured and transport is "sse" → Create an SSE type client; - If the url field is configured and transport is "streamable_http" → Create a StreamableHTTP type client; - Call the Client.Start method to perform the MCP initialize handshake and tools / list tool discovery; - Add the initialized Client to the Manager's clients mapping table; Set the `isInitialized` property of the Manager to true.

[0040] Upon completion of this phase, the Manager will possess: - LocalClient ready (all local tools are registered); - A ready collection of external MCP Clients (all remote tools have been discovered); The only missing component is the XiaoZhiMCPClient connection to the device (because the device is not yet connected).

[0041] During the delayed binding phase (BindConnection), when a device connects to the server via WebSocket or MQTT, a pre-initialized MCP Manager is retrieved from the resource pool, and the BindConnection method is executed for fast binding. Set the link reference (conn) and the function handler reference (funcHandler); Handling XiaoZhiMCPClient: - If XiaoZhiMCPClient does not exist → Create a new instance, set the vision URL, device ID, client ID, access token, register the tool discovery completion callback, and call the Start method to start the MCP initialization handshake; - If it already exists → Rebind the connection reference (SetConnection), update the device identification information, check the ready status, and restart the initialization if it is not ready; Add XiaoZhiMCPClient to the clients mapping table (key name "xiaozhi"); Perform a health check (CheckHealth) on all external MCP clients of stdio and SSE types: - If the health check is passed → Continue using; - If the health check fails → Reset Connection → Start → If it still fails, log the error and skip the client; Call registerAllToolsIfNeeded to register all tools from ready clients to a unified FunctionRegistry.

[0042] The core operations of the binding process only involve reference assignment, state checks, and lightweight network checks, taking milliseconds, which is 2-3 orders of magnitude faster than the several seconds of the complete initialization process.

[0043] MCP resource recycling strategy When MCP Manager returns resources to the resource pool, it adopts a "return to old and innovate" strategy instead of a simple state reset: Special handling of mcpPool in the Put(resource) method of the resource pool: Step R1: Do not put the old resource back into the pool channel; Step R2: Asynchronously (goroutine) call factory.Create() to create a new MCP Manager; Step R3: After the new Manager executes the complete preInitializeServers, it is placed into the pool channel; Step R4: The old Manager's Cleanup method is called, which shuts down all MCPClients in sequence.

[0044] MCP Manager comprises multiple layers of stateful connections—a stdio / SSE connection to an external MCP server maintains the session context, while XiaoZhiMCPClient caches the tool list and name mappings for the previous device. A simple Reset operation cannot guarantee the complete clearing of all state, potentially causing subsequent users to "see" tools from the previous device or trigger callbacks from the previous session. Creating a completely new instance is the most reliable way to ensure a clean state.

[0045] Since the creation of new instances is performed asynchronously (without blocking return operations), and the resource pool has a minimum number of instances guaranteed (10 by default), this strategy will not lead to resource pool exhaustion or increased binding latency.

[0046] All tools are uniformly registered to the FunctionRegistry interface (unified function registry): The registerAllToolsIfNeeded method is called when BindConnection is invoked; Iterate through all ready MCPClients (local, external MCP server, xiaozhi); Call GetAvailableTools() for each Client to obtain a list of tools in OpenAI Tool format (including function.name, function.description, and function.parameters). Call funcHandler.RegisterFunction(toolName, tool) to register each tool to a unified registry; When LLM performs function calling, it obtains a complete list of tools from a unified registry without needing to be aware of the tool's origin.

[0047] Since the device-side MCP initialization (steps I1-I6) requires a response from the device, it may not be completed until BindConnection returns. Therefore, a callback mechanism (onFetchToolsDone) is designed to automatically trigger registration after the device-side tool discovery is complete, without blocking the binding process.

[0048] Unified scheduling process: When the LLM decides to call a certain tool, the Manager performs unified scheduling: The Manager.ExecuteTool method receives the tool name and parameters; Acquire a read lock and iterate through all registered MCPClients; For each Client, call HasTool(toolName) to check if the client owns the tool; Once a matching Client is found, its CallTool(ctx, toolName, args) is invoked for execution; The execution result is returned to the LLM to continue inference.

[0049] For the device-side tool (XiaoZhiMCPClient.CallTool): 1. Restore the sanitized name to its original name using toolNameMap; 2. Construct an MCP tools / call JSON-RPC request (including the restored original tool name and parameters); 3. Sent to the device via device communication connection; 4. Wait for the device to return the result (resultCh matched by ID + 30-second timeout); 5. Parse the returned content field and select either text result mode or trigger action mode based on the tool type.

[0050] Throughout the scheduling process, LLM only needs to provide the tool name and parameters, and is completely unaware whether the tool is executed locally on the server, on a remote MCP server, or on the device.

[0051] Vision Capability Expansion – Connecting Device Hardware and AI Vision During the initial handshake (step I1), the URL of the vision service and the JWT access token are passed in the MCP capabilities: json "capabilities": { "vision": { "url": "http: / / server:8080 / vision", "token": "jwt_token_xxx" } } This allows the device to invoke the server-side visual recognition service when executing the MCP tool. Typical process: 1. LLM calls the device-side tool "self_camera_take_photo"; 2. XiaoZhiMCPClient sends a photo request to the device via MCP pass-through; 3. After the device takes a picture, it uses the vision URL and token received from the capabilities section to upload the image to the Vision service on the server. 4. The device returns an MCP result containing image information; 5. XiaoZhiMCPClient is identified as a response from a camera app, and an ActionResponse is encapsulated to trigger the visual recognition processor; 6. The visual recognition result is returned to the LLM for further reasoning (e.g., "No one is at the door").

[0052] like Figure 1 As shown, the unified scheduling architecture of the three-source tools of this invention includes: a top-level Large Language Model (LLM) connected to a unified function registry (FunctionRegistry) via a Function Calling interface; the registry connected to an intermediate tool manager (Manager); and the Manager managing three types of MCPClients—LocalClient (local tools, in-process calls), Client (remote MCP server tools, stdio / SSE / HTTP connections), and XiaoZhiMCPClient (device-side tools, WebSocket / MQTT pass-through). The three types of clients share a unified MCPClient interface, including methods such as Start, Stop, HasTool, GetAvailableTools, CallTool, IsReady, CheckHealth, and Type.

[0053] like Figure 2 As shown, standard MCP JSON-RPC messages are wrapped within device communication protocol messages. The outer layer uses the `type="mcp"` flag for message routing, while the inner `payload` field carries the complete MCP JSON-RPC message body. The device only needs to implement the JSON-RPC message parsing and hardware tool execution logic; it does not need to run an HTTP server or standard processes.

[0054] like Figure 3As shown, XiaoZhiMCPClient first sends an MCP initialize message (carrying a vision capability declaration). After the device returns server information, it sends a tools / list request to obtain the device's hardware tool list. If the response contains a nextCursor field, it automatically sends subsequent pagination requests until the complete list is obtained. After all tools are obtained, the device is marked as ready, triggering a callback to register the tools.

[0055] like Figure 4 As shown, each MCP tool call request is assigned an auto-incrementing unique ID, and a buffered result channel (chan interface{}, buffer size 1) is created and stored in the callResults mapping table (map[int]chan interface{}). The request is sent via the device communication connection. When the device returns, payload.id is extracted, and the corresponding channel delivery result is found in callResults. The caller waits for the result channel via select, context cancellation, or a 30-second timeout. The mapping entry is automatically cleaned up when a timeout occurs or the connection is broken.

[0056] like Figure 7 As shown, the period character "." in the device-side tool name (e.g., "self.camera.take_photo") is replaced with an underscore "_" using the `sanitizeToolName` function to obtain the canonical name ("self_camera_take_photo"). The `toolNameMap` mapping table records the bidirectional mapping between canonical and original names. Externally, the canonical name is used to register with the `FunctionRegistry`, and when sending an MCP request to the device, it is restored to the original name through the mapping table. Tools from different sources are isolated using naming prefixes: the `local_` prefix indicates a local tool, the `mcp_` prefix indicates a remote MCP server tool, and the device-side tool uses the sanitized original name.

[0057] like Figure 5 As shown, when the system starts, the resource pool factory creates multiple MCP Manager instances (10 by default). Each instance executes `preInitializeServers` upon creation: creating a `LocalClient` to register local tools, reading configurations to connect to external MCP servers, and performing tool discovery. When a device connects, it retrieves a pre-initialized Manager from the pool and executes `BindConnection`, which involves only lightweight operations such as reference assignment, state checks, and creating a `XiaoZhiMCPClient`, taking milliseconds.

[0058] like Figure 6As shown, when the Manager returns an instance, it does not put the old instance back. Instead, it asynchronously creates a new instance, performs a complete pre-initialization, and then puts it into the pool. The old instance calls Cleanup to close all MCPClient connections in turn. This strategy avoids session state pollution caused by the reuse of stateful connections.

[0059] like Figure 8 As shown, the vision service URL and JWT token are passed in the capabilities of MCP initialize. When LLM calls the device's camera tool, the process is as follows: MCP request is passed through to the device → device takes a picture → image is uploaded using the vision service information in the capabilities → Vision service performs recognition → result is returned to LLM. This achieves a complete closed loop: device hardware → MCP protocol → AI vision recognition → LLM inference.

[0060] like Figure 9 As shown, Manager.ExecuteTool receives the tool name and parameters, acquires a read lock, iterates through all MCPClients, checks for each call to HasTool to see if it owns the tool, and if so, calls CallTool to execute it. Throughout the process, LLM only needs to provide the tool name and parameters, and is completely unaware of whether the tool is executed locally on the server, on a remote MCP server, or on the device.

[0061] To adapt to different transmission channels, this embodiment designs MCPConnAdapter (MQTT adapter, which sends MCP messages via MQTTClient.sendPublish) and WSRWAdapter (WebSocket adapter, which implements asynchronous communication through independent read and write coroutines), enabling XiaoZhiMCPClient to work transparently on different transmission channels.

[0062] Implementation Results: Deployed and validated on over 500,000 ESP32-S3 devices. The pre-initialization-delayed binding strategy reduces tool readiness latency during device connection establishment from several seconds to milliseconds. A single machine supports over 3000 concurrent online connections. Unified scheduling of three-source tools reduces LLM application layer code size by approximately 60%. The tool naming standardization mechanism is compatible with over 100 device-side tools.

[0063] The basic principles and main features of the present invention have been described above. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are only illustrative of the principles of the present invention. Various changes and modifications can be made to the present invention without departing from the spirit and scope of the present invention. All such changes and modifications fall within the scope of the present invention as claimed. The scope of protection of the invention is defined by the appended claims and their equivalents.

Claims

1. A method for extending the capabilities of IoT device tools based on the MCP protocol, characterized in that, Includes the following steps: S1 establishes a WebSocket or MQTT communication connection between IoT devices and cloud services; S2, encapsulate the standard MCP protocol JSON-RPC message into a device communication protocol message and transmit it bidirectionally through the communication connection; S3, the cloud service completes the MCP initialization handshake with the IoT device through the MCP initialize message and tools / list message to obtain the list of hardware tools registered on the IoT device; S4 registers device-side hardware tools, local tools, and remote MCP server tools into the function registry, allowing the large language model to obtain a complete list of tools through the Function Calling interface. In S5, when the large language model calls a tool during inference, the tool manager iterates through all tool clients, finds the client that owns the tool, executes the call, and returns the result to the large language model to continue inference.

2. The method for extending the capabilities of IoT devices and tools based on the MCP protocol according to claim 1, characterized in that, In step S2, the specific method for encapsulating the standard MCP protocol JSON-RPC message into a device communication protocol message is as follows: a type identifier field is set on the outer layer of the device communication protocol message, with the value of "mcp", and the MCP JSON-RPC message is used as the value of the outer payload field; and the MCP message pass-through includes an asynchronous request-response matching mechanism, specifically: Assign an auto-incrementing unique ID to each MCP tool call request, and create a corresponding result channel to store in a mapping table; Send an MCP tools / call request carrying the ID via the device communication connection; When a device returns a message, the ID field in the message is extracted, the corresponding result channel is looked up in the mapping table, and the result is delivered. The caller can return a result through the select multi-way waiting result channel, cancel the waiting context, or trigger a waiting timeout timer. When a timeout occurs or the connection is lost, the corresponding entry in the mapping table will be automatically cleared.

3. The method for extending the capabilities of IoT devices and tools based on the MCP protocol according to claim 1, characterized in that, The paginated list of tools supporting MCP initialization handshake is as follows: After sending a tools / list request, if the response data returned by the device contains a non-empty nextCursor field, a subsequent tools / list request carrying the cursor parameter will be automatically constructed to continue obtaining the list. The system iterates through the requests until the device's response does not contain the nextCursor field or the nextCursor is empty, aggregating all tools into a complete tool list. The capabilities field of the initialize message carries the access address and authentication token for the visual recognition service, enabling IoT devices to directly invoke the cloud-based visual recognition service when performing tool operations.

4. A method for extending the capabilities of IoT devices and tools based on the MCP protocol according to claim 1, characterized in that, It also includes a tool name normalization step: performing normalization processing on the device-side tool name, replacing characters not supported by the large language model Function Calling specification with underscore characters; maintaining a tool name mapping table to record the mapping relationship between the normalized name and the original name; registering and exposing the use of the normalized name externally, and restoring the original name through the mapping table when sending an MCP request to the device.

5. The method for extending the capabilities of IoT devices and tools based on the MCP protocol according to claim 1, characterized in that, In S5, the tool manager adopts a pre-initialization-delayed binding strategy: when the system starts, multiple tool manager instances are created and added to the resource pool. Each instance completes local tool registration and remote MCP server connection initialization in advance when it is created. When an IoT device connects, the pre-initialized tool manager instance is obtained from the resource pool, and only reference binding operations are performed to bind the device connection and function processor to the manager instance. The reference binding operations include setting connection references, creating or binding device-side MCP clients, performing health checks on remote MCP clients, and registering tools for all ready clients.

6. The method for extending the capabilities of IoT devices and tools based on the MCP protocol according to claim 5, characterized in that, The resource pool adopts a "return to old and innovate" recycling strategy: when a tool manager instance is returned, the old instance is not put back into the resource pool; a new tool manager instance is created asynchronously, and the new instance is put into the resource pool after performing a complete pre-initialization. The old instance performs a cleanup operation, closing all MCP client connections in sequence.

7. The method for extending the capabilities of IoT devices and tools based on the MCP protocol according to claim 1, characterized in that, The three types of tool clients—device-side, local, and remote MCP server—share a unified client interface, which includes methods for starting, stopping, querying tools, obtaining tool lists, calling tools, checking readiness, and checking health.

8. A system for extending the capabilities of IoT devices and tools based on the MCP protocol, characterized in that, include: The device-side MCP client module encapsulates JSON-RPC messages from the MCP protocol into the device communication protocol for transparent transmission, performs initial handshake and tool discovery with IoT devices, and implements asynchronous request-response matching and tool name normalization mapping; the local tool client module manages local tool functions directly called within the server process; and the remote MCP server client module connects to a remote MCP server via stdio, SSE, or StreamableHTTP to obtain and invoke remote tools. The tool manager module is used to manage the three types of tool clients mentioned above, enabling unified tool registration, discovery, and scheduling; the resource pool module is used to pre-create and cache tool manager instances, implementing a pre-initialization-delayed binding strategy. The function registry module is used to uniformly store tool information from all sources, providing a complete list of tools for Function Calling of large language models.

9. The IoT device tool capability extension system based on the MCP protocol according to claim 8, characterized in that, The device-side MCP client module also includes a connection adapter submodule, which includes an MQTT connection adapter and a WebSocket connection adapter, used to adapt communication connections of different types of devices to a unified message sending interface.

Images