OpenAI's Assistants API gives you thread ids, which are unusable from a chat client — nobody remembers which of two opaque strings held the conversation about the migration. Storing them locally with a name and a description turns threads into something you can ask for. The deletion path is the other detail done right: removing a thread from both sides together avoids the usual state where the local list shows conversations that no longer exist upstream. Understand the shape: this reaches a second model from inside your client, so a call here is a call you pay OpenAI for, on top of whatever is running the client.
A client for OpenAI's Assistants API with a local thread store on top: create and modify assistants, and keep named persistent conversations that survive the session.
- create_assistant, list_assistants, retrieve_assistant and update_assistant cover the assistant itself — name, instructions and model can be changed after creation.
- Threads are named and described rather than referred to by id: create_new_assistant_thread takes a name, list_threads reads them from the local database, and update_thread renames one.
- ask_assistant_in_thread sends a message into a specific thread and streams the reply back, so context accumulates where you put it.
- delete_thread removes the conversation from OpenAI's servers and the local database together, rather than leaving one of the two behind.
OPENAI_API_KEY, and UV_PYTHON — it launches through uv, so the interpreter is named rather than inherited. Usage bills against your own OpenAI account.
One command plus a key — pip install mcp-simple-openai-assistant, then supply credentials