Skip to main content
Glama

mcp2tcp: 连接物理世界与AI大模型的桥梁

English | 简体中文

系统架构

Related MCP server: MCP2Serial

工作流程

项目愿景

mcp2tcp 将TCP设备接入AI大模型的项目,它通过 Model Context Protocol (MCP) 将物理世界与 AI 大模型无缝连接。最终实现:

  • 用自然语言控制你的硬件设备

  • AI 实时响应并调整物理参数

  • 让你的设备具备理解和执行复杂指令的能力

主要特性

  • 智能TCP通信

    • 自动检测和配置TCP设备 用户也可指定TCP号

    • 支持多种波特率(默认 115200)

    • 实时状态监控和错误处理

  • MCP 协议集成

    • 完整支持 Model Context Protocol

    • 支持资源管理和工具调用

    • 灵活的提示词系统

支持的客户端

mcp2tcp 支持所有实现了 MCP 协议的客户端,包括:

客户端

特性支持

说明

Claude Desktop

完整支持

推荐使用,支持所有 MCP 功能

Continue

完整支持

优秀的开发工具集成

Cline

资源+工具

支持多种 AI 提供商

Zed

基础支持

支持提示词命令

Sourcegraph Cody

资源支持

通过 OpenCTX 集成

Firebase Genkit

部分支持

支持资源列表和工具

支持的 AI 模型

得益于灵活的客户端支持,mcp2tcp 可以与多种 AI 模型协同工作:

云端模型

  • OpenAI (GPT-4, GPT-3.5)

  • Anthropic Claude

  • Google Gemini

  • AWS Bedrock

  • Azure OpenAI

  • Google Cloud Vertex AI

本地模型

  • LM Studio 支持的所有模型

  • Ollama 支持的所有模型

  • 任何兼容 OpenAI API 的模型

准备

Python3.11 或更高版本 Claude Desktop 或 Cline

快速开始

1. 安装

Windows用户

下载 install.py

python install.py

macOS用户

# 下载安装脚本
curl -O https://raw.githubusercontent.com/mcp2everything/mcp2tcp/main/install_macos.py

# 运行安装脚本
python3 install_macos.py

Ubuntu/Raspberry Pi用户

# 下载安装脚本
curl -O https://raw.githubusercontent.com/mcp2everything/mcp2tcp/main/install_ubuntu.py

# 运行安装脚本
python3 install_ubuntu.py

安装脚本会自动完成以下操作:

  • ✅ 检查系统环境

  • ✅ 安装必要的依赖

  • ✅ 创建默认配置文件

  • ✅ 配置Claude桌面版(如果已安装)

  • ✅ 检查TCP设备

手动分步安装依赖

windows
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"
MacOS
curl -LsSf https://astral.sh/uv/install.sh | sh

主要依赖uv工具,所以当python和uv以及Claude或Cline安装好后就可以了。

基本配置

在你的 MCP 客户端(如 Claude Desktop 或 Cline)配置文件中添加以下内容: 注意:如果使用的自动安装那么会自动配置Calude Desktop无需此步。 使用默认配置文件:

{
    "mcpServers": {
        "mcp2tcp": {
            "command": "uvx",
            "args": [
                "mcp2tcp"
            ]
        }
    }
}

注意:修改配置后需要重启Cline或者Claude客户端软件

配置TCP和命令: 注意下面的配置默认为COM11 需要根据实际进行修改

# config.yaml
tcp:
  # TCP服务器配置
  remote_ip: "127.0.0.1"  # 远端IP地址
  port: 9999  # 端口号
  connect_timeout: 3.0  # 连接超时时间,单位为秒
  receive_timeout: 2.0  # 接收超时时间,单位为秒
  communication_type: "client"  # 通信类型,client或server
  response_start_string: "CMD"  # 可选,TCP应答的开始字符串,默认为OK

commands:
  # PWM控制命令
  set_pwm:
    command: "CMD_PWM {frequency}"  # frequency为0-100的整数,表示PWM占空比
    need_parse: false  # 不需要解析响应内容
    data_type: "ascii"  # 数据类型,ascii或hex
    parameters:
      - name: "frequency"
        type: "integer"
        description: "PWM frequency value (0-100)"
        required: true
    prompts:
      - "把PWM调到最大 (frequency=100)"
      - "把PWM调到最小 (frequency=0)"
      - "请将PWM设置为{frequency} (0-100的整数)"
      - "关闭PWM (frequency=0)"
      - "把PWM调到一半 (frequency=50)"

配置说明

配置文件位置

配置文件(config.yaml)可以放在位置: 用户主目录(推荐个人使用)

# Windows系统
C:\Users\用户名\.mcp2tcp\config.yaml

# macOS系统
/Users/用户名/.mcp2tcp/config.yaml

# Linux系统
/home/用户名/.mcp2tcp/config.yaml
  • 适用场景:个人配置

  • 需要创建 .mcp2tcp 目录:

    # Windows系统(在命令提示符中)
    mkdir "%USERPROFILE%\.mcp2tcp"
    
    # macOS/Linux系统
    mkdir -p ~/.mcp2tcp

TCP配置 命令配置进阶

config.yaml 中添加自定义命令:

使用真实TCP

# config.yaml
 # PICO信息查询命令
  get_pico_info:
    command: "CMD_PICO_INFO"  # 实际发送的命令格式,server会自动添加\r\n
    need_parse: true  # 需要解析响应内容
    data_type: "ascii"  # 数据类型,ascii或hex
    prompts:
      - "查询Pico板信息"
      - "显示开发板状态"

指定配置文件: 比如指定加载Pico配置文件:Pico_config.yaml

{
    "mcpServers": {
        "mcp2tcp": {
            "command": "uvx",
            "args": [
                "mcp2tcp",
                "--config",
                "Pico"  //指定配置文件名,不需要添加_config.yaml后缀
            ]
        }
    }
}

为了能使用多个TCP,我们可以新增多个mcp2tcp的服务 指定不同的配置文件名即可。 如果要接入多个设备,如有要连接第二个设备: 指定加载Pico2配置文件:Pico2_config.yaml

{
    "mcpServers": {
        "mcp2tcp2": {
            "command": "uvx",
            "args": [
                "mcp2tcp",
                "--config",
                "Pico2"  //指定配置文件名,不需要添加_config.yaml后缀
            ]
        }
    }
}

测试

在开始使用之前,建议先进行测试以确保一切正常工作。

1. 启动测试服务器

首先,启动测试目录下的 TCP 服务器来模拟硬件设备:

# 进入项目目录
cd tests

# 启动测试服务器
python tcp_server.py

服务器将在本地启动,监听端口 9999。你会看到类似这样的输出:

TCP server started on 127.0.0.1:9999
Waiting for connections...

启动客户端Claude 桌面版或Cline

从源码快速开始

  1. 从源码安装

# 通过源码安装:
git clone https://github.com/mcp2everything/mcp2tcp.git
cd mcp2tcp

# 创建虚拟环境
uv venv .venv

# 激活虚拟环境
# Windows:
.venv\Scripts\activate
# Linux/macOS:
source .venv/bin/activate

# 安装开发依赖
uv pip install --editable .

如果使用真实TCP

# config.yaml
tcp:
  # TCP服务器配置
  remote_ip: "127.0.0.1"  # 远端IP地址
  port: 9999  # 端口号
  connect_timeout: 3.0  # 连接超时时间,单位为秒
  receive_timeout: 2.0  # 接收超时时间,单位为秒
  communication_type: "client"  # 通信类型,client或server
  response_start_string: "CMD"  # 可选,TCP应答的开始字符串,默认为OK

commands:
  # PWM控制命令
  set_pwm:
    command: "CMD_PWM {frequency}"  # frequency为0-100的整数,表示PWM占空比
    need_parse: false  # 不需要解析响应内容
    data_type: "ascii"  # 数据类型,ascii或hex
    parameters:
      - name: "frequency"
        type: "integer"
        description: "PWM frequency value (0-100)"
        required: true
    prompts:
      - "把PWM调到最大 (frequency=100)"
      - "把PWM调到最小 (frequency=0)"
      - "请将PWM设置为{frequency} (0-100的整数)"
      - "关闭PWM (frequency=0)"
      - "把PWM调到一半 (frequency=50)"

MCP客户端配置

在使用支持MCP协议的客户端(如Claude Desktop或Cline)时,需要在客户端的配置文件中添加以下内容: 直接自动安装的配置方式 源码开发的配置方式

使用默认演示参数:

{
    "mcpServers": {
        "mcp2tcp": {
            "command": "uv",
            "args": [
                "--directory",
                "你的实际路径/mcp2tcp",  // 例如: "C:/Users/Administrator/Documents/develop/my-mcp-server/mcp2tcp"
                "run",
                "mcp2tcp"
            ]
        }
    }
}

指定参数文件名

{
    "mcpServers": {
        "mcp2tcp": {
            "command": "uv",
            "args": [
                "--directory",
                "你的实际路径/mcp2tcp",  // 例如: "C:/Users/Administrator/Documents/develop/my-mcp-server/mcp2tcp"
                "run",
                "mcp2tcp",
                "--config", // 可选参数,指定配置文件名
                "Pico"  // 可选参数,指定配置文件名,不需要添加_config.yaml后缀
            ]
        }
    }
}

配置文件位置

配置文件(config.yaml)可以放在不同位置,程序会按以下顺序查找:

1. 当前工作目录(适合开发测试)

  • 路径:./config.yaml

  • 示例:如果你在 C:\Projects 运行程序,它会查找 C:\Projects\config.yaml

  • 适用场景:开发和测试

  • 不需要特殊权限

2. 用户主目录(推荐个人使用)

# Windows系统
C:\Users\用户名\.mcp2tcp\config.yaml

# macOS系统
/Users/用户名/.mcp2tcp/config.yaml

# Linux系统
/home/用户名/.mcp2tcp/config.yaml
  • 适用场景:个人配置

  • 需要创建 .mcp2tcp 目录:

    # Windows系统(在命令提示符中)
    mkdir "%USERPROFILE%\.mcp2tcp"
    
    # macOS/Linux系统
    mkdir -p ~/.mcp2tcp

3. 系统级配置(适合多用户环境)

# Windows系统(需要管理员权限)
C:\ProgramData\mcp2tcp\config.yaml

# macOS/Linux系统(需要root权限)
/etc/mcp2tcp/config.yaml
  • 适用场景:多用户共享配置

  • 创建目录并设置权限:

    # Windows系统(以管理员身份运行)
    mkdir "C:\ProgramData\mcp2tcp"
    
    # macOS/Linux系统(以root身份运行)
    sudo mkdir -p /etc/mcp2tcp
    sudo chown root:root /etc/mcp2tcp
    sudo chmod 755 /etc/mcp2tcp

程序会按照上述顺序查找配置文件,使用找到的第一个有效配置文件。根据你的需求选择合适的位置:

  • 开发测试:使用当前目录

  • 个人使用:建议使用用户主目录(推荐)

  • 多用户环境:使用系统级配置(ProgramData或/etc)

  1. 运行服务器:

# 确保已激活虚拟环境
.venv\Scripts\activate

# 运行服务器(使用默认配置config.yaml 案例中用的LOOP_BACK 模拟TCP,无需真实TCP和TCP设备)
uv run src/mcp2tcp/server.py
或
uv run mcp2tcp
# 运行服务器(使用指定配置Pico_config.yaml)
uv run src/mcp2tcp/server.py --config Pico
或
uv run mcp2tcp --config Pico

文档

Available Tools

3 tools
ledC

打开LED (state=on)

ParametersJSON Schema
NameRequiredDescriptionDefault
stateYesParameter state for the led command

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. It states the action ('打开LED') which implies a write/mutation operation, but doesn't disclose whether this requires specific permissions, whether the change is persistent, what happens if the LED is already on, or what the response looks like. For a mutation tool with zero annotation coverage, this is insufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise - a single phrase with embedded parameter example. While efficient, it might be too terse for optimal understanding. Every word earns its place, but the structure could be improved with clearer separation of purpose and parameter guidance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no annotations and no output schema, the description is inadequate. It doesn't explain what happens after execution, what errors might occur, or the broader context of LED control. The agent would need to guess about the tool's behavior and response format based on minimal information.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents the single parameter. The description adds minimal value by showing an example value ('on') in context, but doesn't provide additional semantics beyond what's in the schema's examples array. Baseline 3 is appropriate when schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('打开LED' meaning 'turn on LED') and specifies the required parameter (state=on). It distinguishes from potential siblings by focusing on LED control rather than info retrieval (pico_info) or PWM control (pwm). However, it doesn't explicitly mention the resource being controlled beyond 'LED'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, when this tool is appropriate versus pwm for LED control, or any constraints. The only usage hint is the parameter value 'on', but no context about when to use on vs off states.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

pico_infoB

查询Pico板信息

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.2/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. '查询' (query) implies a read-only operation, but the description doesn't explicitly state this or mention any other behavioral traits like authentication requirements, rate limits, error conditions, or what format the information returns. For a tool with zero annotation coverage, this is inadequate behavioral transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise at just four Chinese characters ('查询Pico板信息'), which directly states the tool's purpose with zero wasted words. It's appropriately sized for a simple query tool with no parameters, and the meaning is immediately clear without unnecessary elaboration.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter query tool with no annotations and no output schema, the description provides the minimum viable information about what the tool does. However, it doesn't explain what information is returned or in what format, which would be helpful given the lack of output schema. The description is complete enough to understand the basic purpose but lacks details about the tool's behavior and output.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters with 100% schema description coverage, so the baseline is 4. The description doesn't need to explain parameters since none exist, and it correctly doesn't attempt to describe non-existent parameters. The description focuses appropriately on the tool's purpose rather than parameter details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description '查询Pico板信息' clearly states the tool's purpose as querying information about a Pico board, using a specific verb ('查询' - query) and resource ('Pico板' - Pico board). It distinguishes from sibling tools 'led' and 'pwm' which likely control hardware components rather than query information. However, it doesn't specify what type of information is retrieved, keeping it from a perfect score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when this tool is appropriate, what prerequisites might exist, or how it differs from the 'led' and 'pwm' sibling tools. The agent receives no usage context beyond the basic purpose statement.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

pwmC

把PWM调到最大 (frequency=100)

ParametersJSON Schema
NameRequiredDescriptionDefault
frequencyYesParameter frequency for the pwm command

TDQS

C2.6/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool 'adjusts PWM to maximum' which implies a write/mutation operation, but doesn't disclose any behavioral traits like side effects, permissions needed, error conditions, or what happens to existing PWM settings. The frequency=100 mention provides minimal context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise single sentence that gets straight to the point. No wasted words or redundant information. However, the brevity comes at the cost of completeness - it's arguably too terse for a tool with no annotations or output schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'maximum' means, what values are valid, what the tool returns, or what side effects occur. The single sentence leaves too many questions unanswered for proper tool understanding and invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% with the parameter well-documented in the schema. The description adds minimal value beyond the schema - it mentions frequency=100 as an example but doesn't explain the semantic meaning of the frequency parameter or how it relates to 'maximum' PWM. Baseline 3 is appropriate given the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the action ('调到最大' - adjust to maximum) and target resource (PWM), but it's vague about what '最大' means in context. It mentions frequency=100 but doesn't clarify if this is the maximum value or just an example. The description distinguishes from sibling tools (led, pico_info) by focusing on PWM control.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives. The description implies this sets PWM to maximum, but doesn't specify use cases, prerequisites, or when not to use it. No comparison with sibling tools is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 3 tool updates
    • First observedled
    • First observedpico_info
    • First observedpwm

TDQS

C2.9/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: 'led' controls an LED, 'pico_info' queries board information, and 'pwm' adjusts PWM settings. There is no overlap in functionality, making it easy for an agent to select the correct tool for each task without confusion.

Naming Consistency3/5

The naming is mixed in style: 'led' and 'pwm' are acronyms or abbreviations, while 'pico_info' uses snake_case. However, all names are short and readable, with no chaotic variations, but they lack a consistent verb_noun pattern or uniform casing.

Tool Count3/5

With only 3 tools, the set feels thin for a server named 'mcp2tcp', which might imply broader capabilities like TCP communication or device control. While each tool is distinct, the count is borderline low for the apparent scope of interacting with a Pico board.

Completeness2/5

The tool surface is severely incomplete for controlling a Pico board via TCP. There are no tools for basic operations like reading sensor data, sending/receiving TCP data, or managing connections. The existing tools cover only LED, PWM, and info queries, leaving significant gaps that could cause agent failures in broader tasks.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • A
    license
    B
    quality
    D
    maintenance
    Links IoT devices to AI large models using the MCP and MQTT protocols, enabling natural language control, real-time AI responses, and complex instruction execution for interconnected IoT devices.
    3
    371
    MIT
  • A
    license
    B
    quality
    Not graded
    maintenance
    An MCP server that bridges the physical world and AI models by enabling natural language control of IoT hardware via the MQTT protocol. It supports real-time device monitoring, command publishing, and response handling for seamless integration between AI clients and physical devices.
    3
    -
  • F
    license
    Not graded
    quality
    D
    maintenance
    Bridges the Model Context Protocol (MCP) with ESP32 devices running Tasmota firmware, enabling LLMs to send structured commands like toggling relays or reading sensors via HTTP.
    1
    -

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mcp2everything/mcp2tcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server