OpenAI's MCP client not supporting progress notifications

[mbuptivo]

Pre-submission Checklist

• I have verified that this discussion would not be more appropriate as an issue in a specific repository
• I have searched existing discussions to avoid duplicates

Discussion Topic

Hi,
I'm trying to create an MCP server using this SDK. Problem is I have a few long running agentic operation that may take 30 to 120 seconds. I can't make it work with OpenAI. I understand their client implementation problem is not strictly related to this SDK, but I am looking for workarounds or iteas. Basically, it seems that OpenAI responses API's MCP implementation:

• Has a hard timeout of 60 seconds
• Does not send a progress token
  I'm stuck with this. Any idea is welcome, thanks!

[mikekistler]

The OpenAI behavior is unfortunate. They really should fix that.

But as a workaround, you could write your tools such that they return immediately with a resource link, and then continue processing and put the result in the resource. Then you can retrieve the result later by reading the resource.

[mbuptivo]

Hi, thanks for helping out. I'm a bit of newbie, so I only partially understood your suggestion. I got the resource part, but I don't understand the "then you can retrieve the result later". Who's in charge of doing this? If I understand correctly tools and resources are exposed to the LLM that decides when to make the call or read the content. Since the operation is async, how can the LLM decide to poll for completion? Is the user expected to ask?

[mikekistler]

I haven't tried this with an LLM, but maybe we can figure it out. The tool response comes through the "host" (the AI application) before being returned to the LLM, so perhaps the host can check for a resource link response and in that case give the LLM a response like "This tool takes a while to run. Check back in 2 minutes to see if the response is ready".

But I suppose this only works if your code actually gets control in between the tool response and that going back to the LLM. If not, maybe this approach isn't going to work. But I suppose the tool call could itself create this response and return it, and on some future call when the result is ready return that.

[PederHP]

Have you tried using background mode in their API? It's specifically designed for long-running tasks? It might only improve leniency towards long-running reasoning and agentic loops, but it's worth trying to see if it gives longer timeouts on tools, I think.

There's also the fetch and search contracts which are designed to work with deep research. Check out their documentation on building MCP servers. It might be the case that time outs are different for those, or when running in deep research mode.

Otherwise, there is the technique @mikekistler described where you pass a resource link back. I don't think their implementation is able to fetch resources, but you could do a variant where you return a message to try again later for the result, and then have another tool which fetches the result (the first will then return some handle). It takes a bit more engineering work as your MCP server needs to track this state.

Note that using dynamic tools is not likely to work, as I think they cache your list of tools when connecting, so your fetch result tool needs to be there even though it will fail if called without a matching start.

For what it's worth, I think it's a great learning experience in terms of MCP and AI engineering to build a "multi-tool" operation where you have begin_task and check_for_task_result tools (but using the names that make sense in your situation ofc) and let the model handle checking after some time.

[mbuptivo]

Thanks for your suggestion. I’m currently evaluating my options. I honestly believe that the flow in their implementation needs to be fixed, but they also lack a serious ticketing system. In any case:

I didn’t explain the entire scenario. I’m working on an interactive tool, so each LLM response is triggered by the user doing something, essentially “chatting” with the main LLM. This main AI receives a list of tools from MCP, but some of those tools invoke other parts of the platform that may take a long time to process (other LLMs at work...). MCP with progress should be perfect for this, but it seems that with OpenAI I need to work around their faulty implementation.

@mikekistler I completely agree that tool responses come through the host when using function tools. In fact, my previous implementation was based on functions, but that required each host implementation to have specific code for declaring and handling function calls from the LLM with the actual code. I decided to move away from function tools and embrace MCP specifically to remove code from the client implementation and have “functions on the server,” i.e., tools in an MCP server. I’m fairly sure that in this case, calls to the MCP server originate from OpenAI’s server, the client/host is not involved, and the answer from the MCP server goes directly to the LLM, which handles invocation and responses automatically.

@PederHP I will investigate background mode, but I still need some other code on the host/client side to check for completion. I’ve seen suggestions elsewhere about implementing a request/check pattern where the LLM receives a task_id and later checks back. However, due to the async nature of the task and the fact that the LLM is only triggered by user interaction, this “check_for_task_result” would ultimately have to come from the user polling the LLM to see whether the operation completed. Alternatively, I could intercept the task_id and have my own code poll the remote system for completion, then somehow inject the information back into the LLM. That could work, but again, it feels a bit at odds with the narrative that MCP is the perfect tool for agentic interaction: implemented in 3 minutes, zero code required, works like a charm. :)