simple-gpt-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| OPENAI_API_KEY | Yes | API key required at startup. | |
| OPENAI_BASE_URL | No | Optional trusted startup configuration for the OpenAI base URL. Credentials are sent to this URL, so use only a trusted service. HTTPS is required except for loopback test endpoints. | |
| SIMPLE_GPT_MCP_DATA_DIR | No | Override the state/data directory with an absolute path. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| chatB | Ask an OpenAI model or continue a persistent session. Explicit per-call overrides; no local code or file access. Save request_id for interruption recovery. |
| sessionsA | List/get local session metadata, configure defaults, or DELETE local session data. Never deletes upstream OpenAI data. Instructions and response contents are excluded from metadata. |
| request_statusA | Inspect a known local request, recover its recorded OpenAI response without generating a new one, or explicitly abandon an unresolved request. Abandoning does not cancel upstream work or prevent billing. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
Each tool targets a distinct layer: chat generates model responses, sessions manages session-level metadata/config, and request_status handles individual request recovery. The main risk is mild confusion between chat and request_status around retrieving responses, but the descriptions explicitly contrast generating vs. recovering without generating.
Names mix conventions: 'chat' is a bare verb, 'sessions' a plural noun, and 'request_status' a snake_case noun phrase. Each name is readable and meaningful in isolation, but there is no predictable pattern across the set.
Three tools is a compact but reasonable surface for this scope, and each tool earns its place. However, each tool bundles multiple operations (sessions does list/get/configure/delete; request_status does inspect/recover/abandon), which slightly overloads the small set.
The surface covers response generation, session lifecycle management, and request interruption recovery, which are the core workflows. Minor gaps exist around model discovery and retrieving session response contents, but the stated exclusions and recovery paths make these workable.