[Question]: Timeout not working for workflow & MCP-usage

[liebki]

Question Validation

• I have searched both the documentation and discord for an answer.

Question

Hi again,

the same problem as a few hours ago.

No matter where or what I set as values for the timeouts, still the MCP-Client which is inside the Agents of llama-index, kills a task after 30 seconds. No matter the value after 30 seconds, the client sends a DELETE to the MCP-Server, because of that the framework eventually tries again, sometimes the agent does, sometimes it doesnt.

The problem is simply, why (in my case, does the framework kill the session, mid-run) even though I set the timeout way higher..?

I also have a basic code of what I am doing / trying, reduced to the problematic stuff, no imports etc.

Code:

async def create_gitlab_mcp_tools():
    """To create a MCP-Client, convert it into a ToolSpec and return it for usage in agent."""
    personal_token_gitlab = os.getenv("GITLAB_PERSONAL_TOKEN")
    mcp_client = BasicMCPClient("http://127.0.0.1:8000/mcp", headers={"Authorization":f"Bearer {personal_token_gitlab}"}, timeout=600)
    
    mcp_tool = McpToolSpec(client=mcp_client)
    return mcp_tool

async def start_workflow(model: LLM):
    mcp_tool_gitlab = await create_gitlab_mcp_tools()
    tool_list_gitlab = await mcp_tool_gitlab.to_tool_list_async()
    
    gitlab_agent = ReActAgent(
        name="GitlabAgent",
        description="Uses the GitLab tools to do several things in GitLab.",
        llm=model,
        tools=tool_list_gitlab,
        verbose=True,
        timeout=600
    )

    orchestrator_agent = ReActAgent(
        name="OrchestratorAgent",
        description="Orchestrates the user requests to the agents to do.",
        llm=model,
        can_handoff_to=["GitlabAgent"],
        verbose=True,
        timeout=600
    )

    agent_workflow = AgentWorkflow(
        agents=[gitlab_agent, orchestrator_agent],
        root_agent=orchestrator_agent.name,
        timeout=600
    )
    
    return agent_workflow


async def main():
    dotenv.load_dotenv()
    
    model = CustomOpenAiLike(
        model="gpt-oss-120b",
        is_chat_model=True,
        timeout=600,
        is_function_calling_model=True,
        max_tokens=128000,
        context_window=128000,
        api_base="https://base-url/v1",
        api_key="x",
        token_refresh_fn=get_new_token,
        system_prompt=BASE_SYSTEM_PROMPT,
    )
    
    memory = ChatMemoryBuffer.from_defaults(llm=model)
    workflow = await start_workflow(model=model)
    context = Context(workflow)
    
    while(True):
        print(Fore.BLUE + "\nPlease input your query.")
        query = input(">> ")
        
        if query in ["q", "quit", "exit"]:
            exit(0)

        resp = await workflow.run(user_msg=query, ctx=context, memory=memory)
        print("Answer of the agent:\n", str(resp))

if __name__ == "__main__":
    asyncio.run(main())

Additionally:

• The prompt works fine, the model is capable of running tools correctly, I have no problems in that regards.
• The model is a GPT OSS 120B, again everything works fine on that end.
• The custom "CustomOpenAiLike" also has nothing to do with it, it's just for authentication renewal, I switched back and forth between the vanilla version.

[dosubot]

The 30-second timeout is enforced by the MCP-Client itself. Even if you set higher timeout values in your agents or workflows, the BasicMCPClient defaults to a 30-second session timeout unless you explicitly set the timeout parameter when creating the client. This value is passed to the underlying session as read_timeout_seconds, and if not set (or if set incorrectly), the client will terminate the task after 30 seconds and send a DELETE to the MCP-Server, regardless of progress notifications—they do not extend or reset the timeout [source].

In your code, you are setting timeout=600 when creating the BasicMCPClient, which should override the default. If you are still seeing a 30-second timeout, double-check that the value is actually being passed through and not being overridden elsewhere. There are no hardcoded 30-second limits in the agent or workflow layers—they just forward the timeout parameter to the workflow base [source].

If the problem persists, make sure you are not accidentally creating a BasicMCPClient somewhere else in your code without the timeout parameter, and that the correct client instance is being used by your tool spec.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[logan-markewich]

ooc, what version of llama-index-tools-mcp do you have?

As far as I can tell, the timeout is getting passed to the underlying session in the latest version

llama_index/llama-index-integrations/tools/llama-index-tools-mcp/llama_index/tools/mcp/client.py

Line 204 in 3c47c2e

async def _run_session(self) -> AsyncIterator[ClientSession]:

[liebki]

@dosu

You have seen the code, this is more or less the code, I just reduced stuff that's not relevant.

Could the usage of workflow stuff, combined with MCP stuff make problems or, could the MCP client have a logical bug?

Because what you see is my code, nothing else and it does not work with setting the timeouts to 600, it definitely cuts of after 30 all the time.

[liebki]

ooc, what version of llama-index-tools-mcp do you have?

As far as I can tell, the timeout is getting passed to the underlying session in the latest version

llama_index/llama-index-integrations/tools/llama-index-tools-mcp/llama_index/tools/mcp/client.py

Line 204 in 3c47c2e

async def _run_session(self) -> AsyncIterator[ClientSession]:

I installed the latest versions today, these are the versions for all llama-packages:
llama-cloud==0.1.35
llama-cloud-services==0.6.54
llama-index==0.14.8
llama-index-cli==0.5.3
llama-index-core==0.14.8
llama-index-embeddings-openai==0.5.1
llama-index-indices-managed-llama-cloud==0.9.4
llama-index-instrumentation==0.4.2
llama-index-llms-openai==0.6.9
llama-index-llms-openai-like==0.5.3
llama-index-readers-file==0.5.4
llama-index-readers-llama-parse==0.5.1
llama-index-tools-mcp==0.4.3
llama-index-workflows==2.11.1
llama-parse==0.6.54

[dosubot]

Based on the code and the latest implementation, the MCP client timeout should be fully controlled by the timeout parameter you set when creating the BasicMCPClient—there are no hidden 30-second caps in the workflow or tool layers, and the workflow just passes your value through to the underlying session. If you set timeout=600, that value should be used for the session timeout, and progress notifications do not extend or reset it [source].

Given that your code sets the timeout to 600 everywhere but the client still cuts off at 30 seconds, this points to either a bug in the MCP client itself or a misconfiguration/environment issue. There’s no evidence that combining workflow and MCP usage should cause the timeout to revert to 30 seconds if the correct client instance is used [source].

If you’re certain the right client instance is being used and the timeout is set, double-check your package version and ensure there’s no accidental override or multiple client instantiations. If everything checks out, this may be a bug in the MCP client’s session handling logic.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[liebki]

@dosu

Again, you have seen the code. This is exactly the code that I use just a more narrow version.

I use the latest versions as far as I know, you also have the versions in my last message.

So this is either back in the framework I suppose or a bug in the MCP library? 🥲

If I can provide anything else, let me know!

[dosubot]

Based on the code and the latest package versions, the MCP client should fully respect the timeout you set—there’s no hidden 30s cap in the workflow or agent layers, and the timeout parameter is passed directly to the underlying session for all transports. If you’re still seeing a 30-second cutoff, it’s not due to a known bug in the MCP client code itself; the logic for propagating the timeout is correct and there’s no override or clamp internally cite.

This points to either an environment-specific factor (like a proxy, firewall, or server config) or possibly a different client instance being used somewhere. To isolate: try running a minimal script that just instantiates BasicMCPClient with a high timeout and calls a long-running tool, outside of any workflow/agent context. Also, enable debug logging on both client and server to confirm what timeout is actually being used and where the cutoff happens. If the minimal script still fails at 30s, it’s likely something external to the codebase is enforcing the limit.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[liebki]

@dosu

I don't know if this is relevant but if I use debug logging for the whole script, I can see 30 seconds timeout set for "httpcore" somehow even though I have multiple usages of 600 instead of 30. Has the httpcore anything to do with the fact that the MCP client sends DELETE to the Server after 30 seconds or is this not related?

[dosubot]

Yes, httpcore is directly involved here. The MCP client passes its timeout setting down to the underlying HTTP session, which is ultimately handled by httpcore. If you see a 30-second timeout in httpcore debug logs, that means the value being used at the transport layer is still 30 seconds, not the 600 seconds you set. This is why the MCP client sends a DELETE after 30 seconds—the lower-level timeout triggers, not your configured value.

This usually means either a different BasicMCPClient instance is being created without the high timeout, or the timeout argument isn't reaching the class as intended. Double-check that the exact BasicMCPClient instance used by your tool is the one you configured with timeout=600, and that nothing is overriding it before it reaches the HTTP layer. If httpcore logs show 30s, that's the value actually being enforced, regardless of what you set elsewhere.

So yes, httpcore's timeout is the reason for the 30s cutoff and DELETE, and the user-supplied timeout isn't being propagated as expected in your current setup.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[liebki]

Could you verify that this is the case, then this would mean it's an error, right?

@logan-markewich