The reason to reach for this is specific: OpenAI's web search and code interpreter are mature, and MCP clients cannot call them directly. Everything runs through your own OpenAI key over the Assistant API, so it is a routing layer, not a free lunch — and you decide per launch which of the four tools the client actually sees.
A bridge in one direction: it takes tools that live inside OpenAI's Assistant API and republishes them over MCP, so a client that speaks MCP can use them. You choose which tools to expose when you start the server, and requests are translated into OpenAI's format and the responses back into MCP's.
- OpenAI's web search available inside an MCP client, which is the case the project demonstrates first
- Code interpreter reachable from any MCP-compatible model
- Web browser and file management listed alongside those two in the supported set
- The exposed set chosen at launch — either as `tools=[OpenAIBuiltInTools.WEB_SEARCH.value]` in a few lines of Python, or on the command line with `--tools retrieval code_interpreter`
- Stdio transport, which is the form MCP clients expect for a local server
An OpenAI API key with access to the Assistant API, exported as `OPENAI_API_KEY` — the tools are OpenAI's, so the usage is billed to your OpenAI account. Python 3.10+. The README's install line names `openai-tool2mcp`, which PyPI does not have; its Claude Desktop config launches from a checkout, using `uv --directory` with the project path, and `uv` is recommended over plain Python for that. The project describes itself as in active development.