Skip to main content
Glama
XingtongCai

Multi-Protocol MCP Server

by XingtongCai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

一个同时支持stdio，streamableHttpless和sse三种协议的MCP服务框架

项目说明

目前MCP服务在AI方向的业务使用频率很高，但随着业务的加深，发现存在以下痛点： 1.不同平台对MCP服务协议要求不同，有支持streamableHttp，有仅支持sse的。相同功能重复开发，浪费时间成本 2.有些研发人员并不了解MCP，现学现开发会让研发周期加长，时间成本耗费过多 为了解决不同平台不同要求，降低研发人员开发成本，本人提出一个框架，同时支持stdio，streamableHttpless和sse三种模式，实现一次开发实现三种模式

Related MCP server: xiaozhi-mcp

目录结构

  • build: 编译之后的文件

  • src -- router: 配置streamableHttp和sse协议的路由 -- index.ts: 注册streamableHttp路由入口 -- mcp.ts: streamableHttp的配置路径，具体为process.env.MCP_BASE_PATH的路径请求,如果没有配置，默认/mcp -- sse.ts: sse的配置路径，具体为process.env.MCP_BASE_PATH的路径请求,如果没有配置，默认/mcp -- tools: mcp的工具 -- index.ts: 注册工具 -- mockFunc.ts: 模拟一个工具写法 - 这部分需要根据业务开发 -- cli.ts: 命令行解析工具 -- index.ts: 总入口 -- server.ts: 创建Mcp服务 -- sse.ts: 运行sse模式 -- stdio.ts: 运行stdio模式 -- streamableHttp.ts: 运行streamableHttp模式

  • xingyun/bin : 是根据我们业务使用的部署工具开发的部署脚本 - 这部分需要根据实际部署平台更改

  • build_xingyun.sh: 是根据我们业务使用的部署工具开发的部署脚本 - 这部分需要根据实际部署平台更改

启动服务

1.启动stdio: npm run start 是默认启动stdio

1.启动StreamableHttp: npm run start:http 是默认启动端口3001

2.更改端口启动StreamableHttp: npm run dev:http 或者 npm run start -- -t http -p 3001 -t httt: 代表启动StreamableHttp -p 3001: 代表启动端口3001

测试StreamableHttp方式

第一种方式 curl命令

1.cd demo && npm run dev:http // 这个会启动 http://localhost:3001/mcp 这个地址 2.终端curl命令

curl -X POST http://localhost:3001/mcp \
-H "Content-Type: application/json" \
-H "Accept: application/json, text/event-stream" \
-d '{
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"name": "mockfunc",
"arguments": {"desc": "测试参数","desc1": "测试参数"
}
},
"id": 1
}'

第二种方式 使用inspector工具

1.cd demo && npm run dev:http // 先启动自己服务 2.npm run inspector // 启动inspector工具 3.在URL地址配上自己服务地址

测试SSE方式

方式和测试StreamableHttp方式 相同，只不过启动是用 npm run start:sse

环境变量说明

内网使用配置

环境变量配置

# 监听特定内网IP（例如：192.168.1.100）
export MCP_HOST=192.168.1.100
export MCP_PORT=3001

# 使用内网域名（可选）
export MCP_DOMAIN=mcp-server.internal.com

# 修改基础路径（可选，默认是 /mcp）
export MCP_BASE_PATH=/api/mcp

端口配置优先级

  1. 环境变量 MCP_PORT（最高优先级）

  2. 命令行参数 --port

  3. 默认值：3001端口

访问地址优先级

  1. 环境变量 MCP_DOMAIN（最高优先级）

  2. 环境变量 MCP_HOST

  3. 默认: localhost

内网访问方式

假设你的内网服务器IP是 192.168.1.100，端口是 3001：

基础访问：

http://192.168.1.100:3001/sales

带域名的访问：

http://mcp-server.internal.com/sales

自定义路径：

http://192.168.1.100:3001/api/mcp

额外说明

1.在 xingyun/bin/control.sh中，这段代码是启动streamableHttpless的，如果需要启动sse，需要改为 npm run start:sse

start(){
    npm run start:http
    sleep 3
    status
}

2.在package.json中 stop的语句是 "stop": "pkill -f \"demo\" || true",这个demo是要根据你自己启动服务的名字相同

Available Tools

1 tool
mockfuncC

这是一个模拟接口的工具

ParametersJSON Schema
NameRequiredDescriptionDefault
descYes这个写法代表参数必须填写
desc2No这个写法代表参数不是必填

TDQS

C2.6/5.0
Behavior2/5

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

There are no annotations, so the description carries the full burden of behavioral disclosure. It only says it simulates interfaces, but does not reveal whether it makes external calls, returns generated data, or has side effects. This is insufficient for safe use.

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 a single short sentence with no unnecessary words, making it structurally concise and front-loaded. While the content is vague, the structure itself is efficient and free of redundancy.

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?

With no annotations, no output schema, and only a minimal description, the tool is not adequately described. The agent cannot anticipate return values, error behavior, or typical usage. The schema covers parameters but not the tool's overall behavior.

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 baseline is 3. However, the schema descriptions for 'desc' and 'desc2' only explain requiredness, not the actual meaning or purpose of the parameters. The tool description adds no parameter information, so it stays at baseline without adding value.

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 tool simulates/mocks interfaces, conveying a general purpose. However, it lacks specifics about what kind of mock or how it behaves, and the Chinese term '接口' is ambiguous. It is not a tautology, but it does not distinguish from potential alternatives.

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 usage guidance is provided. The description does not say when to use this tool, what scenarios it fits, or how it compares to alternatives, leaving the agent without selection criteria.

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.

  1. 1 tool updatev1.0.0
    • First observedmockfunc
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

C2.7/5.0

Scored across 1 tool

Disambiguation5/5

With only one tool, there is no possibility of confusing it with others. The tool is trivially distinct.

Naming Consistency5/5

There is only one tool name, so there is no pattern to be inconsistent with. The name is at least a valid identifier.

Tool Count1/5

The server is named 'Multi-Protocol MCP Server', implying support for multiple protocols, yet it exposes only a single vague mock tool. This is a severe mismatch between scope and implementation.

Completeness1/5

The single tool description is minimal and does not indicate any comprehensive coverage of multi-protocol functionality. There are no clear operations or lifecycle coverage, leaving the stated purpose unfulfilled.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • xiaozhi-mcp

    botwith
    A
    license
    Not graded
    quality
    D
    maintenance
    A versatile MCP server framework that enables AI capabilities like remote control, calculations, and email operations via multiple transport types. It supports stdio, SSE, and HTTP protocols for seamless integration between language models and external systems.
    MIT

  • my-mcp

    kcbabo
    F
    license
    B
    quality
    D
    maintenance
    An MCP server framework featuring dynamic tool loading and a modular one-tool-per-file architecture for rapid development. It supports both Stdio and HTTP transport modes, offering automated test generation and centralized configuration management.
    11
    -

  • pywss MCP Server

    czasg
    A
    license
    Not graded
    quality
    D
    maintenance
    A lightweight Python web framework that enables building MCP servers with SSE, StreamHTTP, and MCPO protocols for tool integration.
    99
    MIT