F
licenseNot graded
qualityF
maintenanceA Model Context Protocol server that extends AI capabilities by providing file system access and management functionalities to Claude or other AI assistants.
157 npm
5
-
MCP Server with OpenAI-Compatible Model Support
by agaonker
Provides tools to interact with OpenAI-compatible API endpoints for text generation, including streaming responses from models like GPT-4o-mini.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@MCP Server with OpenAI-Compatible Model SupportGenerate a story about a robot."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP Server with OpenAI-Compatible Model Support
A small, readable Model Context Protocol server that exposes a handful of tools to any MCP client (Goose, Claude Desktop, OpenAI Agents, etc.). It supports both stdio and streamable HTTP transports, and one of its tools streams output from an OpenAI-compatible model.
Tools
Tool | Needs an LLM? | Description |
| No | Reports server status and provider config |
| No | Returns the configured model metadata |
| No | Returns the provided message back |
| No | Lists files/folders at a path on the host machine |
| No | Reads the text contents of a file on the host machine |
| Yes | Streams text from the configured OpenAI-compatible model |
The filesystem tools (list_directory, read_file) only make sense over stdio, because the server runs on the user's own machine and can reach their disk — the canonical "local" MCP use case.
Related MCP server: MCP Server
Architecture
src/server.ts— bootstraps the server, registers tools, selects the transportsrc/config.ts— loads environment configurationsrc/providers/— OpenAI-compatible clientsrc/tools/— one file per tool
Transports
Set MCP_TRANSPORT to choose how clients reach the server:
Value | Behavior |
| The client launches the server as a subprocess and talks over stdin/stdout. Local, single-client. |
| The server listens on a port ( |
| Runs stdio and HTTP simultaneously in one process. |
generate_text streams its tokens as notifications/message. Over HTTP these ride the single request's own SSE response, so the server stays stateless (no session affinity needed).
Setup
npm install
cp .env.example .env # then fill in your provider settings
npm run build
npm startEnvironment variables (see .env.example):
MCP_TRANSPORT=stdio # stdio | http | both
MCP_HTTP_HOST=127.0.0.1
MCP_HTTP_PORT=3000
OPENAI_API_KEY=... # only needed for generate_text
OPENAI_BASE_URL=https://api.openai.com/v1
OPENAI_MODEL=gpt-4o-miniTesting with Goose
Goose is an open-source AI agent (by Block) that speaks MCP. It uses its own LLM as the "brain" to decide which of your tools to call. See the Goose docs and repo.
1. Give Goose a brain (its own LLM)
Goose needs an LLM provider — this is separate from this server's OPENAI_* config. Using Anthropic as an example, run it inline so the values reach Goose:
export GOOSE_DISABLE_KEYRING=1 # read secrets from env instead of the OS keychain
export GOOSE_PROVIDER=anthropic
export GOOSE_MODEL=claude-sonnet-4-6
export ANTHROPIC_API_KEY=sk-ant-...(Or run goose configure to store these in the keychain once.)
2. Launch a session with this server attached
npm run build
goose session --with-extension 'node /absolute/path/to/dist/server.js'Goose calls MCP servers extensions; the tools appear namespaced (e.g. echo, list_directory).
To test the HTTP transport instead, start the server first and point Goose at the URL:
# terminal 1
MCP_TRANSPORT=http MCP_HTTP_PORT=3000 node dist/server.js
# terminal 2
goose session --with-streamable-http-extension 'http://127.0.0.1:3000/'3. Ask in plain English — the brain picks the tool
You don't name the tool; Goose decides:
echo the words "it works"
list the files in /absolute/path/to/src/tools
read the package.json in this project and tell me the version
what model is the server configured to use?
is the server healthy?Note: the agent may sometimes prefer one of its own built-in tools over yours (e.g. it may run a shell
lsinstead oflist_directory). That's the brain choosing — phrase the request toward your tool, or disable conflicting built-ins, if you want to force it.
Screenshots
echo — Goose's brain calls the echo tool and reports the result:
Listing files in the project:
Inspecting without an agent
To poke the server directly (no LLM needed):
# Browser UI:
npx @modelcontextprotocol/inspector node dist/server.js
# Raw JSON-RPC over HTTP (server in http mode):
curl -s -X POST http://127.0.0.1:3000/ \
-H 'Content-Type: application/json' \
-H 'Accept: application/json, text/event-stream' \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'Example stdio client config
{
"mcpServers": {
"mcp-openai-server": {
"command": "node",
"args": ["/absolute/path/to/dist/server.js"],
"env": {
"OPENAI_API_KEY": "your-key",
"OPENAI_BASE_URL": "https://api.openai.com/v1",
"OPENAI_MODEL": "gpt-4o-mini"
}
}
}
}Available Tools
6 toolsechoA
Returns the provided message back. Useful for testing the connection.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description fully discloses behavior: returns the input message. No side effects are expected, so transparency is adequate.
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?
Two short sentences, front-loaded with purpose, no wasted words. Every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter, no output schema, and no annotations, the description fully covers the tool's purpose and behavior. There is nothing missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description implies the 'message' parameter by stating 'the provided message back'. This adds meaning beyond the schema's type-only definition.
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?
Description clearly states 'Returns the provided message back' with a specific verb and resource. It distinguishes from siblings like generate_text or list_directory by indicating it's a simple echo operation for testing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Useful for testing the connection', providing clear context for when to use. No when-not or alternatives given, but for a simple tool this is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_textC
Generate text using the configured OpenAI-compatible model.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | ||
| model | No | ||
| temperature | No | ||
| maxTokens | No |
TDQS
C2.5/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks disclosure of important behavioral traits such as network dependency, latency, authentication requirements, or side effects. It only states the basic action, leaving the agent unaware of potential costs, rate limits, or the need for configuration.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (one sentence) but fails to provide enough context for a tool with four parameters. It essentially restates the tool name, making it under-specified rather than efficiently concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description is far from complete. It does not explain what the tool returns, how errors are handled, what happens if the model is not configured, or the relationship between parameters. This inadequacy would confuse an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and no additional explanation in the description, the agent gets no guidance on the parameters. The description does not explain what 'prompt', 'model', 'temperature', or 'maxTokens' do, nor does it mention defaults or constraints beyond what is in the schema.
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 generates text using an OpenAI-compatible model. It uses a specific verb ('generate') and resource ('text'), and it distinguishes well from sibling tools which focus on file operations, listing, and server health.
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 guidelines are provided on when to use this tool versus alternatives. For instance, there is no mention that 'list_models' should be used first to see available models, or that this tool is for generating new content as opposed to echoing or reading files.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_directoryB
Lists the files and folders at a path on the machine running this server.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
TDQS
B3.4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose return format, permission requirements, or behavior for invalid paths. However, with no annotations and a simple listing operation, the description is minimally adequate but lacks depth.
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 of 14 words with no extraneous information. It is highly concise and front-loaded.
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 simplicity (one parameter, no annotations, no output schema), the description is adequate but incomplete. It does not mention what the output contains beyond 'files and folders'.
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 coverage is 0% for the 'path' parameter. The description adds that path is a filesystem path on the machine, but does not specify format, constraints, or typical values.
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 lists files and folders at a given path. It uses a specific verb ('lists') and resource ('files and folders'), and distinguishes from siblings like 'read_file' (reads content) and 'echo' (repeats text).
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 is provided on when to use this tool versus alternatives like 'read_file' or 'list_models'. The description gives no context about appropriate use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_modelsB
Returns the currently configured model metadata for the MCP server.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| details | No |
TDQS
B3/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the basic action of returning metadata. It does not disclose potential behaviors such as read-only nature, required permissions, or performance implications. The description adds minimal 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that directly conveys the purpose. It is efficiently front-loaded with no wasted words, but could benefit from more detail about the parameter or return value.
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?
For a simple tool with one boolean parameter and no output schema, the description does not explain what 'model metadata' includes or how the 'details' parameter affects output. This leaves the agent with incomplete information to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one boolean parameter 'details' with 0% description coverage, and the tool description does not explain its meaning or effect. The description adds no value beyond the schema, failing to compensate for the lack of schema description.
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 it returns 'currently configured model metadata for the MCP server'. The verb 'returns' and resource 'model metadata' are specific. It distinguishes from sibling tools which handle files, text, or health.
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 retrieving model metadata but provides no explicit guidance on when to use it over alternatives or when not to use it. No exclusions or contexts are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
read_fileB
Reads and returns the text contents of a file on the machine running this server.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
TDQS
B3.1/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a read-only operation (non-destructive), but it lacks details about handling of non-text files, error conditions, or any restrictions. Without annotations, the burden is higher, but the core behavior is transparent.
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 that quickly conveys the tool's purpose. It is appropriately front-loaded, but could be slightly improved by adding parameter context without becoming verbose.
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 tool with one parameter and no output schema, the description covers the basic function but omits parameter format and return value details. It is minimally adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention the 'path' parameter at all. With 0% schema description coverage, the description should add meaning (e.g., absolute vs relative, supported encodings), but it fails to do so.
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 that the tool reads and returns the text contents of a file. It uses a specific verb ('reads') and resource ('file'), which distinguishes it from sibling tools like 'list_directory' and 'echo'.
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 is provided on when to use this tool versus alternatives. There is no mention of prerequisites, such as file existence or permissions, nor 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.
server_healthC
Checks whether the MCP server and provider configuration are ready.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| includeConfig | No |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided and description does not disclose behavioral traits such as whether tool is read-only, idempotent, or causes side effects. Lacks transparency beyond basic purpose.
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?
Single sentence, 15 words, front-loaded with verb. No unnecessary words or repetition.
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?
Simple tool with one optional param and no output schema; description states basic purpose but lacks detail on return value, 'ready' definition, and parameter behavior.
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 has one parameter (includeConfig) with 0% description coverage. Description does not explain this parameter's meaning or effect, adding no value beyond schema.
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?
Description clearly states tool checks health of MCP server and provider configuration. Distinguishes from sibling tools like echo or generate_text which have different purposes.
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 or alternatives. Does not specify prerequisites or situations where tool is appropriate.
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.
6 tool updates
v1.0.0- First observed
echo - First observed
generate_text - First observed
list_directory - First observed
list_models - First observed
read_file - First observed
server_health
TDQS
B3.1/5.0
Scored across 6 tools
Disambiguation5/5
All six tools have clearly distinct purposes: echo is for testing, generate_text for model generation, list_directory and read_file for file operations, list_models for model metadata, and server_health for checking configuration. There is no overlap or ambiguity.
Naming Consistency3/5
Most tools follow a verb_noun pattern (generate_text, list_directory, list_models, read_file), but echo is a single verb and server_health is a noun phrase, breaking consistency. The pattern is still readable but not uniform.
Tool Count4/5
With six tools, the count is reasonable for an MCP server. However, the server's stated focus on OpenAI-compatible model support is somewhat diluted by the inclusion of file system tools (list_directory, read_file), which slightly reduces the sense of a well-scoped set.
Completeness2/5
For a server claiming OpenAI-compatible model support, the tool surface is notably sparse: only a single generate_text tool and a list_models tool. Missing capabilities like context management, streaming, or role-based chat severely limit model interaction. File access is also one-sided (read only).
Maintenance
ActivityInactive
ResponsivenessNo issues
Related MCP Connectors
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Shared memory and actions for Claude, Kiro, OpenAI, Cursor, and other MCP-compatible AI clients.
OCR, transcription, file extraction, and image generation for AI agents via MCP.
Share one project context across ChatGPT, Claude, Telegram and any MCP client.
Related MCP Servers
- FlicenseNot gradedqualityNot gradedmaintenanceProvides remote filesystem operations, git repository management, and process execution capabilities for AI agents through the Model Context Protocol.-
- FlicenseNot gradedqualityCmaintenanceA secure Model Context Protocol server providing HTTP endpoints for AI agent tool execution, including file system operations, shell commands, and LLM-based code generation.1-
- FlicenseNot gradedqualityDmaintenanceEquips AI coding agents with filesystem, Git, database, and computation tools via the Model Context Protocol.1-