Skip to main content
Glama
Roxanne299

GPT Proxy MCP Server

by Roxanne299
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Hybrid

GPT Proxy MCP Server

一个用于 Claude Code 的 MCP (Model Context Protocol) 服务器，用于中转 GPT API 调用。

功能特点

  • 🔄 GPT API 中转：支持所有主流 GPT 模型

  • 🔒 安全：通过环境变量管理 API 密钥

  • 🚀 流式响应：支持流式和常规两种响应模式

  • ⚡ 高性能：基于 MCP SDK 构建，高效稳定

  • 🛠️ 易用：简单的配置和启动流程

Related MCP server: codex-cli-mcp-tool

快速开始

本地部署（stdio 传输）

1. 安装依赖

npm install

2. 配置环境变量

# 复制环境变量模板
cp .env.example .env

# 编辑 .env 文件，添加你的 OpenAI API 密钥
nano .env

在 .env 文件中添加：

OPENAI_API_KEY=your_openai_api_key_here
OPENAI_BASE_URL=https://api.openai.com/v1

3. 启动服务器

# 开发模式启动（推荐）
npm run dev

# 或者使用启动脚本（会检查环境变量）
./start.sh

# 生产模式启动
npm run build
npm start

远程部署（HTTP 传输）

对于需要在远程服务器部署并从本地 Claude Code 连接的场景：

1. 在远程服务器上部署

# 克隆项目到远程服务器
git clone <your-repo-url>
cd mcp-server

# 安装依赖
npm install

# 配置环境变量
cp .env.example .env
nano .env

在 .env 文件中配置：

OPENAI_API_KEY=your_openai_api_key_here
OPENAI_BASE_URL=https://api.openai.com/v1
HTTP_PORT=3001
HTTP_HOST=0.0.0.0

2. 启动 HTTP 服务器

# 使用启动脚本（推荐，会检查配置）
./start-http.sh

# 或者手动启动
npm run build
npm run start:http

# 开发模式
npm run dev:http

3. 配置防火墙（如需要）

# Ubuntu/Debian 示例
sudo ufw allow 3001/tcp

# CentOS/RHEL 示例
sudo firewall-cmd --permanent --add-port=3001/tcp
sudo firewall-cmd --reload

在 Claude Code 中使用

本地连接配置

对于本地部署的 MCP 服务器，在你的 Claude Code MCP 配置文件中添加：

{
  "mcpServers": {
    "gpt-proxy": {
      "command": "node",
      "args": ["/path/to/your/mcp-server/dist/index.js"],
      "env": {
        "OPENAI_API_KEY": "your_api_key_here"
      }
    }
  }
}

或者对于开发环境：

{
  "mcpServers": {
    "gpt-proxy": {
      "command": "npm",
      "args": ["run", "dev"],
      "cwd": "/path/to/your/mcp-server",
      "env": {
        "OPENAI_API_KEY": "your_api_key_here"
      }
    }
  }
}

远程连接配置

对于部署在远程服务器的 MCP 服务器，在你的 Claude Code MCP 配置文件中添加：

{
  "mcpServers": {
    "gpt-proxy-remote": {
      "url": "http://your-server-ip:3001"
    }
  }
}

如果你使用了 HTTPS（推荐用于生产环境）：

{
  "mcpServers": {
    "gpt-proxy-remote": {
      "url": "https://your-domain.com"
    }
  }
}

远程连接使用步骤

  1. 确保远程服务器正在运行

    # 在远程服务器上检查服务状态
curl http://localhost:3001

  2. 更新 Claude Code 配置

    • 找到你的 Claude Code MCP 配置文件（通常在 ~/.config/claude-code/ 目录）

    • 添加上述远程服务器配置

    • 重启 Claude Code

  3. 测试连接

    • 在 Claude Code 中应该能看到 gpt_chat 和 gpt_chat_stream 工具

    • 尝试使用工具发送消息测试连接

使用工具

配置完成后，在 Claude Code 中你可以使用以下工具：

gpt_chat - 标准聊天

使用 gpt_chat 工具发送消息到 GPT-4：
message: "请帮我解释什么是机器学习"
model: "gpt-4"
temperature: 0.7

gpt_chat_stream - 流式聊天

使用 gpt_chat_stream 工具获取流式响应：
message: "写一段关于 AI 发展历史的文章"
model: "gpt-4-turbo"
max_tokens: 2000

支持的模型

  • gpt-3.5-turbo (默认)

  • gpt-3.5-turbo-16k

  • gpt-4

  • gpt-4-turbo

  • gpt-4-turbo-preview

  • gpt-4-0125-preview

  • gpt-4-1106-preview

API 参数说明

通用参数

  • message (必需): 发送给 GPT 的消息

  • model (可选): 要使用的 GPT 模型，默认为 gpt-3.5-turbo

  • max_tokens (可选): 响应的最大 token 数，默认为 1000

  • temperature (可选): 响应的随机性 (0-2)，默认为 1

  • system_prompt (可选): 系统提示词，用于设置 AI 的行为

项目结构

mcp-server/
├── src/
│   ├── index.ts          # 主服务器文件
│   └── types.ts          # TypeScript 类型定义
├── .env.example          # 环境变量模板
├── .gitignore           # Git 忽略文件
├── start.sh             # 启动脚本
├── package.json         # 项目配置
├── tsconfig.json        # TypeScript 配置
├── CLAUDE.md           # Claude Code 指导文件
└── README.md           # 项目说明

开发指南

本地开发

# 安装依赖
npm install

# 启动开发服务器（热重载）
npm run dev

# 类型检查
npm run type-check

# 构建项目
npm run build

环境变量

通用配置:

  • OPENAI_API_KEY (必需): OpenAI API 密钥

  • OPENAI_BASE_URL (可选): API 端点，默认为 https://api.openai.com/v1

  • OPENAI_ORGANIZATION (可选): OpenAI 组织 ID

HTTP 服务器配置（仅用于远程部署）:

  • HTTP_PORT (可选): HTTP 服务器端口，默认为 3001

  • HTTP_HOST (可选): HTTP 服务器主机，默认为 0.0.0.0（监听所有网络接口）

故障排除

常见问题

  1. API 密钥错误

    • 确保在 .env 文件中设置了正确的 OPENAI_API_KEY

    • 检查 API 密钥是否有效且有余额

  2. 模型不可用

    • 确认你的 API 密钥有访问所请求模型的权限

    • 某些模型可能需要等待列表或特殊权限

  3. 连接问题

    • 检查网络连接

    • 如果在中国大陆，可能需要配置代理

日志查看

服务器启动时会在控制台输出日志信息，包括：

  • 启动状态

  • 错误信息

  • API 调用状态

安全注意事项

  • 🔐 永远不要提交包含真实 API 密钥的 .env 文件

  • 🛡️ 使用环境变量管理敏感配置

  • 🔒 服务器通过 stdio 传输运行，确保安全的 Claude Code 集成

  • 📝 定期轮换你的 API 密钥

许可证

MIT License

贡献

欢迎提交 Pull Request 和 Issue！

更新日志

v1.0.0

  • 初始版本发布

  • 支持 GPT API 中转

  • 支持流式和标准响应

  • 完整的错误处理

  • Claude Code MCP 集成

Available Tools

2 tools
gpt_chatB

Send a message to GPT and get a response

ParametersJSON Schema
NameRequiredDescriptionDefault
modelNoGPT model to use (default: gpt-3.5-turbo)gpt-3.5-turbo
messageYesThe message to send to GPT
max_tokensNoMaximum number of tokens in the response (default: 1000)
temperatureNoTemperature for response randomness (0-2, default: 1)
system_promptNoSystem prompt to set context for GPT

TDQS

B3.1/5.0
Behavior2/5

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

With no annotations, the description carries full burden. It only states the basic behavior without disclosing traits like synchronous vs streaming, latency, or error handling. The behavior is straightforward but incomplete.

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 a single, clear sentence with no wasted words. It is appropriately short given the simplicity of the tool.

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 simple chat tool with no output schema and a sibling tool, the description is adequate but could mention the streaming alternative or limitations (e.g., synchronous response). It is minimally complete.

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 coverage is 100%, and each parameter has a description. The tool description adds no additional meaning beyond what the schema provides, so baseline score of 3 is appropriate.

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 (send) and resource (a message to GPT) with outcome (get a response). It is specific but does not distinguish from the sibling tool 'gpt_chat_stream', which likely streams responses.

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 guidance on when to use this tool over alternatives like 'gpt_chat_stream'. The description lacks context about use cases or warnings about when not to use it.

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

gpt_chat_streamA

Send a message to GPT and get a streaming response

ParametersJSON Schema
NameRequiredDescriptionDefault
modelNoGPT model to use (default: gpt-3.5-turbo)gpt-3.5-turbo
messageYesThe message to send to GPT
max_tokensNoMaximum number of tokens in the response (default: 1000)
temperatureNoTemperature for response randomness (0-2, default: 1)
system_promptNoSystem prompt to set context for GPT

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations, the description must disclose key behaviors. It reveals streaming as a major trait, but omits other relevant details like authentication, rate limits, or that it initiates a write operation (sending data).

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, front-loaded sentence with no superfluous words, achieving conciseness while communicating the core purpose.

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?

Given 5 parameters, no output schema, and no annotations, the description is too sparse. It fails to specify how the streaming response is delivered (e.g., SSE, chunks), authentication needs, or error handling, leaving the agent underinformed.

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?

All 5 parameters are described in the schema (100% coverage), so baseline is 3. The description does not add extra context beyond the schema parameter descriptions.

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

Purpose5/5

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

The description explicitly states the action (send a message) and the resource (GPT) with a clear distinction from sibling gpt_chat by adding 'streaming response', differentiating the streaming nature of this tool.

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

Usage Guidelines3/5

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

The description implies usage for real-time responses due to 'streaming', but does not explicitly state when to use this over gpt_chat or list alternatives/exclusions.

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. 2 tool updatesv1.0.0
    • First observedgpt_chat
    • First observedgpt_chat_stream
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0
Disambiguation5/5

The two tools are clearly distinct: one returns a complete response, the other streams. An agent can easily choose based on whether streaming is needed.

Naming Consistency5/5

Both tools use a consistent 'gpt_chat_' prefix with an underscore, and the streaming variant is differentiated by '_stream'. Naming is predictable and clear.

Tool Count3/5

With only 2 tools, the set is minimal. While it covers the core chat functionality, it feels slightly thin for a server named 'GPT Proxy' which might imply broader capabilities like model selection or configuration.

Completeness2/5

The tool surface is incomplete for a general GPT proxy: it lacks tools for listing models, setting system prompts, managing conversations, or adjusting parameters. Agents have no way to configure or extend interactions beyond basic chat.

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

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/Roxanne299/mcp-server'

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