# How to Integrate DeepSeek-Reasonix with Existing Tools: The Complete MCP Guide

> Easily integrate DeepSeek-Reasonix with your tools using MCP plugins. This guide explains how to wrap CLIs and web services into JSON-RPC functions for seamless connection.

- Repository: [YHH/DeepSeek-Reasonix](https://github.com/esengine/DeepSeek-Reasonix)
- Tags: how-to-guide
- Published: 2026-06-26

---

**DeepSeek-Reasonix integrates with existing tools through MCP (Message-Controlled-Protocol) plugins that wrap external CLI utilities and web services as JSON-RPC callable functions accessible via the tool registry.**

DeepSeek-Reasonix is architected as a single-binary Go engine that prioritizes runtime extensibility. According to the `esengine/DeepSeek-Reasonix` source code, you can integrate any existing command-line tool, script, or HTTP service by configuring MCP plugins in [`reasonix.toml`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/reasonix.toml), enabling the LLM to orchestrate external capabilities through standardized tool calls.

## Core Architecture and Configuration Hierarchy

When the Reasonix binary starts, it parses a three-tier configuration hierarchy: [`./reasonix.toml`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/./reasonix.toml) overrides user config, which in turn overrides built-in defaults. This configuration drives the initialization of both built-in tools and external plugins.

The **tool registry** serves as the central dispatcher. In [`internal/tool/tool.go`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/internal/tool/tool.go), the `tool.Init` function registers all built-in commands such as `bash`, `search`, and `read`. When plugins start, they register their RPC methods with this same registry, which preserves insertion order to ensure deterministic tool selection.

## MCP Plugin Transport Layers

DeepSeek-Reasonix supports two transport mechanisms for plugin communication, defined in [`internal/plugin/plugin.go`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/internal/plugin/plugin.go). Each plugin is declared under a `[[plugins]]` block in the TOML configuration with a specific `type` parameter.

### StdIO Transport for Local Subprocesses

The `type = "stdio"` configuration launches the plugin as a local subprocess. The implementation in [`internal/plugin/transport_stdio.go`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/internal/plugin/transport_stdio.go) handles process lifecycle management: the engine starts the command, exchanges JSON-RPC messages over stdin/stdout, and records startup latency in [`internal/plugin/stats.go`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/internal/plugin/stats.go) for load-balancing purposes.

This transport is ideal for wrapping existing CLI tools that need sandboxed execution.

### HTTP Transport for Remote Services

The `type = "http"` configuration connects to a Streamable-HTTP server implementing the MCP specification. The [`internal/plugin/transport_http.go`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/internal/plugin/transport_http.go) file manages persistent connections to remote endpoints, forwarding tool calls as HTTP requests.

This mode suits microservices or long-running daemons that expose functionality via JSON-RPC over HTTP.

## Step-by-Step Integration Workflow

The integration process follows a six-phase initialization sequence as implemented in the source code:

1. **Configuration Parsing** – The CLI reads [`reasonix.toml`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/reasonix.toml) and builds a `Config` struct, parsing the `[[plugins]]` array.
2. **Built-in Registration** – The engine calls `tool.Init` in [`internal/tool/tool.go`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/internal/tool/tool.go) to register native capabilities.
3. **Plugin Instantiation** – For each plugin entry, the engine creates a `plugin.Host` object.
4. **Transport Launch** – The Host initializes the appropriate transport layer—either spawning a subprocess via [`transport_stdio.go`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/transport_stdio.go) or dialing the HTTP endpoint via [`transport_http.go`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/transport_http.go).
5. **Tool Registration** – The plugin registers its methods with the Host, which adds them to the global `Registry` under the naming convention `mcp__<server>__<tool>`.
6. **Dynamic Dispatch** – When the LLM requests a tool, the engine locates the matching registry entry and forwards the JSON-RPC call through `tool.Call` to `plugin.Call`.

## Practical Integration Examples

### Wrapping a CLI Tool with StdIO

To integrate a shell script, declare it in [`reasonix.toml`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/reasonix.toml):

```toml
[[plugins]]
name    = "my-shell-tool"
type    = "stdio"
command = "my-tool-wrapper.sh"

```

Create the wrapper script [`my-tool-wrapper.sh`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/my-tool-wrapper.sh) that reads JSON-RPC from stdin and writes responses to stdout:

```bash
#!/usr/bin/env bash
read -r request
method=$(echo "$request" | jq -r .method)

case "$method" in
  "list_files")
    dir=$(echo "$request" | jq -r .params.dir)
    files=$(ls -1 "$dir" | jq -R . | jq -s .)
    jq -n --argjson result "$files" '{jsonrpc:"2.0", result:$result, id: .id}'
    ;;
  *)
    jq -n --arg error "unknown method $method" '{jsonrpc:"2.0", error:{code:-32601, message:$error}, id: .id}'
    ;;
esac

```

The model can now invoke `mcp__my-shell-tool__list_files`, and Reasonix routes the call through the stdio transport while enforcing `bash_timeout_seconds` limits defined in the config.

### Exposing a Microservice via HTTP

For HTTP-based integration, implement a server conforming to the MCP JSON-RPC spec:

```go
// server.go
package main

import (
    "encoding/json"
    "log"
    "net/http"
)

type rpcRequest struct {
    JSONRPC string          `json:"jsonrpc"`
    Method  string          `json:"method"`
    Params  json.RawMessage `json:"params"`
    ID      interface{}     `json:"id"`
}

type rpcResponse struct {
    JSONRPC string      `json:"jsonrpc"`
    Result  interface{} `json:"result,omitempty"`
    Error   *rpcError   `json:"error,omitempty"`
    ID      interface{} `json:"id"`
}

type rpcError struct {
    Code    int    `json:"code"`
    Message string `json:"message"`
}

func handler(w http.ResponseWriter, r *http.Request) {
    var req rpcRequest
    if err := json.NewDecoder(r.Body).Decode(&req); err != nil {
        http.Error(w, "bad request", http.StatusBadRequest)
        return
    }

    var resp rpcResponse
    resp.JSONRPC = "2.0"
    resp.ID = req.ID

    switch req.Method {
    case "ping":
        resp.Result = "pong"
    default:
        resp.Error = &rpcError{Code: -32601, Message: "method not found"}
    }

    w.Header().Set("Content-Type", "application/json")
    json.NewEncoder(w).Encode(resp)
}

func main() {
    http.HandleFunc("/", handler)
    log.Fatal(http.ListenAndServe(":8081", nil))
}

```

Configure the plugin in [`reasonix.toml`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/reasonix.toml):

```toml
[[plugins]]
name    = "my-http-tool"
type    = "http"
url     = "http://localhost:8081"

```

The LLM accesses this as `mcp__my-http-tool__ping`.

## Configuration Security and Permissions

The engine enforces isolation through the `[permissions]` section in [`reasonix.toml`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/reasonix.toml) and per-tool timeouts. Because stdio plugins run in separate subprocesses, they cannot affect the core process. Configure `bash_timeout_seconds` to prevent runaway operations, and use permission rules to restrict which directories or commands the plugin can access.

For complex workflows, configure multiple providers in the same [`reasonix.toml`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/reasonix.toml) to enable two-model collaboration, where a planner model calls plugin tools while an executor model handles heavy code generation.

## Summary

- **MCP Protocol** – DeepSeek-Reasonix uses Message-Controlled-Protocol to standardize communication between the engine and external tools.
- **File Locations** – Key integration logic resides in [`internal/plugin/plugin.go`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/internal/plugin/plugin.go), [`internal/tool/tool.go`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/internal/tool/tool.go), and the transport implementations in [`internal/plugin/transport_stdio.go`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/internal/plugin/transport_stdio.go) and [`internal/plugin/transport_http.go`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/internal/plugin/transport_http.go).
- **Configuration** – Define plugins in [`reasonix.toml`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/reasonix.toml) using `[[plugins]]` blocks with either `type = "stdio"` for subprocesses or `type = "http"` for remote servers.
- **Naming Convention** – Plugin methods appear to the LLM as `mcp__<server_name>__<tool_name>`.
- **Sandboxing** – StdIO plugins run in isolated subprocesses with configurable timeouts and permission rules, ensuring core engine stability.

## Frequently Asked Questions

### What is MCP in DeepSeek-Reasonix?

MCP (Message-Controlled-Protocol) is the JSON-RPC-based protocol that Reasonix uses to communicate with external tools. It standardizes how the engine discovers tool capabilities and invokes them, whether through local subprocesses or HTTP endpoints. The protocol ensures that any compliant tool can be integrated without modifying the core engine source code.

### Can I integrate Python scripts with DeepSeek-Reasonix?

Yes. Create a Python script that reads JSON-RPC requests from stdin and writes JSON-RPC responses to stdout, then declare it as a `type = "stdio"` plugin in [`reasonix.toml`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/reasonix.toml). The script must parse the JSON-RPC method and params, execute the Python logic, and return a properly formatted JSON-RPC response with `result` or `error` fields.

### How does the tool naming convention work?

When a plugin registers with the engine, its tools are prefixed following the pattern `mcp__<plugin_name>__<method_name>`. For example, a plugin named `git-helper` exposing a method `commit` becomes callable as `mcp__git-helper__commit`. This namespacing prevents collisions between plugins and built-in tools while making capabilities discoverable to the LLM.

### What are the performance implications of HTTP vs StdIO plugins?

StdIO plugins incur process spawn overhead but benefit from OS-level isolation and are suitable for commands that execute quickly and exit. HTTP plugins maintain persistent connections and are better suited for long-running services or tools requiring warm caches. The engine tracks startup latency in [`internal/plugin/stats.go`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/internal/plugin/stats.go) to optimize scheduling, but HTTP plugins generally offer lower latency for frequent calls while StdIO plugins provide stronger isolation guarantees.