Skip to main content
Glama
deenesjakoruzh
boghyjunior-dot

OpenAI GPT MCP Server

by boghyjunior-dot
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

OpenAI GPT MCP Server

一个本地 Model Context Protocol 服务器，通过标准输入/输出提供 OpenAI GPT 文本生成功能。

前置条件

  • Node.js 18 或更高版本

  • 一个 OpenAI API 密钥

Related MCP server: gpt-mcp

安装与构建

npm install
npm run build

将 .env.example 复制为 .env，然后设置你的 API 密钥：

OPENAI_API_KEY=your_api_key

OPENAI_MODEL 是可选的，默认值为 gpt-5。OPENAI_IMAGE_MODEL 也是可选的，默认值为 gpt-image-2。

MCP 客户端配置

先构建，然后将此服务器添加到你的 MCP 客户端配置中。请将 <absolute-path-to-repository> 替换为你克隆仓库的绝对路径。

{
  "mcpServers": {
    "openai-gpt": {
      "command": "node",
      "args": ["<absolute-path-to-repository>\\dist\\index.js"]
    }
  }
}

工具：generate_text

必需输入：

  • prompt：要发送给模型的文本。

可选输入：

  • instructions：响应的系统级行为。

  • model：GPT 模型 ID，用于覆盖 OPENAI_MODEL。

  • max_output_tokens：最大响应长度，范围为 1 到 16,384。

该服务器使用 OpenAI Responses API，并将生成的文本返回给 MCP 客户端。它绝不会将 API 密钥写入输出或日志。

工具：generate_image

生成一张 PNG 图片，并将其直接返回给 MCP 客户端。

  • prompt（必需）：详细的图片描述。

  • model（可选）：图片模型 ID，用于覆盖 OPENAI_IMAGE_MODEL。

  • size（可选）：1024x1024、1536x1024 或 1024x1536。

  • quality（可选）：low、medium 或 high。

图片生成会单独消耗 OpenAI API 额度，与 Claude 的使用量分开计算。

直接运行

npm start

用于交互式检查：

npm run inspect

Available Tools

2 tools
generate_imageGenerate an image with OpenAIB

Generate one image from a text prompt using OpenAI's image generation API.

ParametersJSON Schema
NameRequiredDescriptionDefault
sizeNoImage dimensions. Defaults to 1024x1024.
modelNoOptional image model ID. Defaults to gpt-image-2.
promptYesA detailed description of the image to generate.
qualityNoImage quality. Defaults to medium.

TDQS

B3.3/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that it generates one image, which is minimal. It does not mention output format (e.g., URL or file), potential costs, rate limits, or any side effects. For a generation tool that might involve external API calls and delays, 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.

Conciseness5/5

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

The description is a single sentence that is front-loaded with the core action. It is concise and free of filler or redundancy, earning full marks for efficiency.

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?

Given the tool's moderate complexity (4 parameters, 2 enums, no output schema), the description is under-specified. It covers the basic action but lacks usage guidance, behavioral notes, and any explanation of what the response will contain. While parameters are well-documented in schema, the overall description is too sparse for a complete evaluation.

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%, so the schema already describes all parameters. The description adds no additional meaning beyond restating that it uses a text prompt, which is already in the prompt parameter's description. Per rubric, baseline is 3 for high schema coverage, and no extra value is added.

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 clearly states the tool's function: generating one image from a text prompt using OpenAI's image generation API. It specifies the verb 'generate', the resource 'image', and distinguishes from the sibling generate_text by focusing on image output.

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 versus alternatives. The sibling tool generate_text is not mentioned, and there are no conditions, exclusions, or context for selecting image generation over text generation. The description provides only the basic action without usage context.

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

generate_textGenerate text with OpenAIA

Generate a text response using an OpenAI GPT model via the Responses API.

ParametersJSON Schema
NameRequiredDescriptionDefault
modelNoOptional model ID. Defaults to gpt-5.
promptYesThe user prompt to send to the model.
instructionsNoOptional system-level instructions for the model.
max_output_tokensNoOptional maximum number of generated tokens (up to 16,384).

TDQS

A3.5/5.0
Behavior3/5

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

No annotations are provided, so the description carries the burden. It mentions the API used ('OpenAI GPT model via the Responses API') which hints at behavior but does not disclose details like rate limits, costs, or that the tool invokes an external service. It does not state what happens with token limits or error handling. Given the lack of annotations, this is a minimal but adequate level of behavioral context.

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 one sentence, front-loaded with the purpose, and contains no fluff. It is appropriately concise and focused.

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?

This is a medium-complexity tool with 4 parameters, all documented in the schema, and no output schema. The description covers the primary action and API, but lacks details about return structure (text response) and any constraints like model availability or fallbacks. However, given schema completeness and simplicity, a score of 3 is reasonable—adequate but not rich.

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. The description adds no additional parameter-specific details beyond what the schema already states. It doesn't explain the implications of max_output_tokens or instructions, but schema descriptions are sufficient. No contradictions.

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 verb (generate) and the resource (text response using an OpenAI GPT model via the Responses API). It distinguishes from sibling generate_image by specifying 'text response' and 'GPT model', though it does not explicitly contrast with that tool. The title and description are aligned and specific.

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 the tool is for generating text from a prompt but does not explicitly specify when to use it vs. alternatives. With only one sibling (generate_image), context strongly suggests text generation, but no explicit when/when-not guidance is given. The description could mention that this is for textual completions as opposed to image generation.

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. 2 tool updatesv1.0.0
    • First observedgenerate_image
    • First observedgenerate_text
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

A3.7/5.0

Scored across 2 tools

Disambiguation5/5

The two tools are clearly distinct: one generates text and the other generates images. There is no overlap or ambiguity in their purposes.

Naming Consistency5/5

Both tools follow the same consistent generate_noun pattern using snake_case. The naming convention is uniform and predictable.

Tool Count3/5

Two tools is borderline for a coherent server; they are well-scoped but the surface feels thin for a general OpenAI GPT server. Each tool earns its place, but the count is on the low end.

Completeness4/5

The two-generation capabilities cover the core domain of text and image generation with no obvious dead ends. Minor gaps exist if considering broader OpenAI features like embeddings or audio, but for the stated GPT-focused purpose the coverage is reasonable.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers