Skip to main content
Glama
code-wgl

MCP Server with OpenAI Integration

by code-wgl
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Remote

MCP Server with OpenAI Integration

A production-ready Model Context Protocol server implemented in TypeScript. The server provides:

  1. OpenAI connectivity demo – prove the API key works end-to-end via npm run demo:openai.

  2. MCP tool demo – spawn the server and call tools through an MCP client using npm run demo:tool.

  3. Extensibility demo – hot-load third-party tools from disk via npm run demo:ext or MCP_TOOL_MODULES.

  4. Browser UI demo – launch an interactive web page that exercises the OpenAI call and knowledge-search tool with npm run demo:ui.

The codebase focuses on clean abstractions, schema validation, and commercial readiness (logging, config safety, tests).

Requirements

  • Node.js 18+ (Node 20 recommended to avoid optional engine warnings).

  • npm 9+.

  • A valid OPENAI_API_KEY with access to the desired models.

Related MCP server: PMCP - Perfect Model Context Protocol Server

Quick start

npm install
cp .env.example .env   # fill in OPENAI_API_KEY
npm run build
npm start               # runs the compiled MCP server on stdio

To run the TypeScript entry directly during development:

npm run dev

Environment variables

Variable

Description

OPENAI_API_KEY

Required. API key for OpenAI.

OPENAI_BASE_URL

Override base URL for Azure/OpenAI proxies.

OPENAI_TIMEOUT_MS

Timeout (ms) applied to OpenAI API calls. Defaults to 20000.

MCP_SERVER_NAME

Name advertised to MCP clients.

LOG_LEVEL

fatal → trace. Defaults to info.

MCP_TOOL_MODULES

Comma-separated absolute paths to extra tool modules (see extensibility demo).

MCP_PORT

Reserved for future transports; defaults to 7337.

UI_DEMO_PORT

Optional port for the browser UI demo. Defaults to 4399.

Demo workflows

1. OpenAI connectivity

Verifies credentials and model access:

npm run demo:openai

Outputs the model reply plus token usage metrics via Pino logs.

2. MCP tool invocation

Spawns the compiled MCP server (node dist/index.js) and connects with the official MCP client SDK:

npm run build
npm run demo:tool

Set MCP_DEMO_SERVER_COMMAND / MCP_DEMO_SERVER_ARGS if you want the client to launch a different command (for example npx tsx src/index.ts). The script lists tools and invokes knowledge_search end-to-end.

3. Extensibility via plugins

Ships with src/examples/plugins/stockQuoteTool.ts. After npm run build the compiled module lives at dist/examples/plugins/stockQuoteTool.js.

Load it either through the demo script:

npm run build
npm run demo:ext

or by setting an environment variable before starting the server:

export MCP_TOOL_MODULES=$(pwd)/dist/examples/plugins/stockQuoteTool.js
npm start

The server automatically registers every tool exported from the referenced module(s).

4. Browser UI walkthrough

Launch a lightweight HTTP server that serves public/ui-demo.html:

npm run demo:ui

Visit http://localhost:4399 (or UI_DEMO_PORT) to:

  • Send prompts directly to OpenAI using the configured API key.

  • Call the built-in knowledge_search tool through a REST façade.

Responses render inline so you can validate both flows without leaving the browser.

Tooling

  • TypeScript strict mode with tsc for builds.

  • Vitest for unit testing (npm test).

  • ESLint + Prettier for linting/formatting (npm run lint, npm run format).

  • Pino structured logging with pretty printing in development.

Test & quality gates

npm run lint
npm test

Coverage reports are emitted under coverage/ via V8 instrumentation.

Project structure

  • src/config/env.ts – centralized, validated environment loading.

  • src/clients/openaiClient.ts – resilient OpenAI wrapper implementing the LLMProvider contract.

  • src/mcp/registry.ts – tool lifecycle management + dynamic module loading.

  • src/mcp/server.ts – MCP server wiring, tool adapters, and plugin APIs.

  • src/demos/* – runnable scripts covering the three required scenarios.

  • src/examples/plugins/* – sample plugin(s) for extensibility demos.

  • tests/* – Vitest coverage for critical units.

For a deeper architectural overview, read docs/architecture.md.

Available Tools

2 tools
text_summarizerC

Summarizes long text into concise bullet points using the configured LLM.

ParametersJSON Schema
NameRequiredDescriptionDefault
textYes
modelNogpt-4o-mini

TDQS

C2.8/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. While it mentions the tool uses 'the configured LLM,' it doesn't disclose important behavioral traits like rate limits, authentication requirements, cost implications, or what happens with very long inputs. The description is minimal and lacks operational 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 extremely concise - a single sentence that efficiently communicates the core functionality. Every word earns its place, and it's front-loaded with the essential information. No wasted words or unnecessary elaboration.

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 the tool has no annotations, no output schema, and 0% schema description coverage, the description is inadequate. It doesn't explain what the tool returns, how the summarization works, quality expectations, or error conditions. For a tool that processes text with an LLM, this leaves significant gaps in understanding.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate. It mentions 'configured LLM' which relates to the 'model' parameter, but doesn't explain the 'text' parameter's requirements or constraints. The description adds minimal value beyond what the bare schema provides, failing to adequately compensate for the 0% coverage.

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 tool's purpose: 'Summarizes long text into concise bullet points using the configured LLM.' It specifies the verb ('summarizes'), resource ('long text'), and output format ('concise bullet points'). However, it doesn't explicitly differentiate from the sibling tool 'knowledge_search' (which likely searches rather than summarizes).

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 the sibling tool 'knowledge_search' or any other summarization methods. There's no context about when this tool is appropriate versus other approaches.

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

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3/5.0
Disambiguation5/5

The two tools have clearly distinct purposes: knowledge_search retrieves information from a knowledge base, while text_summarizer condenses provided text. There is no overlap in functionality, and an agent would easily differentiate between them.

Naming Consistency4/5

Both tools use snake_case naming, which is consistent. However, knowledge_search follows a noun_verb pattern (knowledge_search), while text_summarizer uses a noun_verb pattern with a suffix (text_summarizer), showing a minor deviation in naming style.

Tool Count2/5

With only 2 tools, the server feels thin for an 'OpenAI Integration' purpose, which typically implies broader capabilities like text generation, translation, or analysis. This limited set may not adequately cover the expected scope.

Completeness2/5

Given the server's name suggests OpenAI integration, there are significant gaps: no tools for text generation, translation, sentiment analysis, or other common LLM tasks. The surface is incomplete, likely causing agent failures for broader use cases.

Maintenance

ActivityInactive
ResponsivenessSyncing

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/code-wgl/McpServer'

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