Skip to main content
Glama
Supermaxman

OpenAI MCP Server

by Supermaxman
OverviewSchemaRelated ServersScoreDiscussions
Python
Remote

OpenAI MCP Server

A Model Context Protocol server that provides tools to manage OpenAI API keys & spending.

CAUTION

This server can access the OpenAI API and may represent a security risk. Exercise caution when using this MCP server to ensure this does not expose any sensitive data.

Available Tools

TODO: Add tool info here

Related MCP server: Open WebUI MCP Server

Installation

Using uv (recommended)

When using uv no specific installation is needed. We will use uvx to directly run mcp-server-openai.

Using PIP

Alternatively you can install mcp-server-openai via pip:

pip install mcp-server-openai

After installation, you can run it as a script using:

python -m mcp_server_openai

Configuration

Configure for Claude.app

Add to your Claude settings:

{
  "mcpServers": {
    "openai": {
      "command": "uvx",
      "args": ["mcp-server-openai"],
      "env": {
        "OPENAI_ADMIN_API_KEY": "your_openai_admin_api_key"
      }
    }
  }
}
{
  "mcpServers": {
    "openai": {
      "command": "docker",
      "args": ["run", "-i", "--rm", "mcp/openai"],
      "env": {
        "OPENAI_ADMIN_API_KEY": "your_openai_admin_api_key"
      }
    }
  }
}
{
  "mcpServers": {
    "openai": {
      "command": "python",
      "args": ["-m", "mcp_server_openai"],
      "env": {
        "OPENAI_ADMIN_API_KEY": "your_openai_admin_api_key"
      }
    }
  }
}

Debugging

You can use the MCP inspector to debug the server. For uvx installations:

npx @modelcontextprotocol/inspector uvx mcp-server-openai

Or if you've installed the package in a specific directory or are developing on it:

cd path/to/servers/src/openai
npx @modelcontextprotocol/inspector uv run mcp-server-openai

Contributing

We encourage contributions to help expand and improve mcp-server-openai. Whether you want to add new tools, enhance existing functionality, or improve documentation, your input is valuable.

Pull requests are welcome! Feel free to contribute new ideas, bug fixes, or enhancements to make mcp-server-openai even more powerful and useful.

License

mcp-server-openai is licensed under the MIT License. This means you are free to use, modify, and distribute the software, subject to the terms and conditions of the MIT License. For more details, please see the LICENSE file in the project repository.

Available Tools

2 tools
get_costsB

Fetches OpenAI costs for the specified period.

ParametersJSON Schema
NameRequiredDescriptionDefault
start_timeYesThe start time as a UTC timestamp.
end_timeNoThe end time as a UTC timestamp (defaults to now).
group_byNoThe fields to group by (optional). Group the costs by the specified fields. Support fields include project_id, line_item and any combination of them.
project_idsNoThe project IDs to filter by (optional).

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.2/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. It states 'fetches' which implies a read operation, but doesn't mention authentication needs, rate limits, error conditions, or what the output contains (though an output schema exists). For a tool with no annotation coverage, this leaves significant behavioral gaps.

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, efficient sentence that immediately conveys the core functionality without any wasted words. It's appropriately sized for a straightforward data retrieval tool and is perfectly front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/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, 1 required), 100% schema coverage, and the presence of an output schema, the description is reasonably complete. It states what the tool does, though it could better address behavioral aspects given the lack of annotations. The output schema reduces the need to describe return values.

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 schema fully documents all parameters. The description adds no parameter-specific information beyond implying temporal filtering ('for the specified period'), which is already covered in the schema. This meets the baseline for high schema coverage without adding extra value.

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 ('fetches') and resource ('OpenAI costs') with temporal scope ('for the specified period'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from the sibling tool 'get_projects', which appears to be a different resource type, so it misses the highest score.

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 or in what context. It mentions 'for the specified period' but doesn't clarify prerequisites, constraints, or comparison with 'get_projects', leaving the agent with no usage direction beyond the basic purpose.

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

get_projectsB

Fetches OpenAI projects for the current organization.

ParametersJSON Schema
NameRequiredDescriptionDefault
include_archivedNoWhether to include archived projects. Defaults to False.

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.2/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 states 'fetches' which implies a read operation, but doesn't mention any behavioral traits like authentication requirements, rate limits, pagination, or what happens when no projects exist. This leaves significant gaps for a tool that interacts with organizational data.

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, efficient sentence that directly states the tool's purpose without any unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity (one optional parameter) and the presence of both a complete input schema and an output schema, the description is reasonably complete. However, the lack of annotations means some behavioral context is missing, preventing a perfect score.

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?

The description doesn't mention any parameters, but the input schema has 100% description coverage for its single parameter 'include_archived'. Since the schema fully documents this parameter, the baseline score of 3 is appropriate—the description adds no parameter information beyond what's already in the structured data.

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 ('fetches') and resource ('OpenAI projects for the current organization'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from its sibling tool 'get_costs', which appears to be a different resource type, so it doesn't reach the highest score for sibling differentiation.

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, such as its sibling 'get_costs'. It doesn't mention any prerequisites, exclusions, or contextual triggers, leaving usage entirely implicit based on the tool name and purpose alone.

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. Dates show when Glama detected each change.

  1. 2 tool updates
    • First observedget_costs
    • First observedget_projects
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.3/5.0
Disambiguation5/5

The two tools have clearly distinct purposes: get_costs retrieves financial data for a specified period, while get_projects fetches organizational project information. There is no overlap in functionality, making it easy for an agent to select the correct tool based on the task.

Naming Consistency5/5

Both tools follow a consistent verb_noun pattern (get_costs and get_projects), using the same verb 'get' and snake_case formatting. This uniformity makes the tool set predictable and easy to understand.

Tool Count2/5

With only two tools, the server feels thin and under-scoped for an OpenAI MCP server, which might be expected to handle more operations like managing models, generating completions, or listing usage. The limited count suggests incomplete coverage of the domain.

Completeness2/5

The tool set is severely incomplete for an OpenAI server, lacking core operations such as creating or managing projects, generating text or images, or accessing model details. This will likely cause agent failures when attempting common OpenAI-related tasks.

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/Supermaxman/mcp-server-openai'

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