Skip to main content
Glama
deenesjakoruzh
boghyjunior-dot

OpenAI GPT MCP Server

by boghyjunior-dot
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

OpenAI GPT MCP Server

표준 입력/출력을 통해 OpenAI GPT 텍스트 생성을 제공하는 로컬 Model Context Protocol 서버입니다.

사전 요구 사항

  • 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: OPENAI_MODEL을 재정의하는 GPT 모델 ID입니다.

  • max_output_tokens: 최대 응답 크기로, 1부터 16,384까지입니다.

서버는 OpenAI Responses API를 사용하며 생성된 텍스트를 MCP 클라이언트에 반환합니다. API 키를 출력이나 로그에 기록하지 않습니다.

도구: generate_image

하나의 PNG 이미지를 생성하여 MCP 클라이언트에 직접 반환합니다.

  • prompt (필수): 상세한 이미지 설명입니다.

  • model (선택): OPENAI_IMAGE_MODEL을 재정의하는 이미지 모델 ID입니다.

  • size (선택): 1024x1024, 1536x1024, 또는 1024x1536입니다.

  • quality (선택): low, medium, 또는 high입니다.

이미지 생성은 Claude 사용과 별개로 OpenAI API 크레딧을 소비합니다.

직접 실행

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