Hi Team,
I have a MCP server built using FastMCP and is returning response in form of streams which is hosted on AgentCore Runtime. However, Quick is not able to consume it because looks like client is not configured to accept streaming response which is causing an issue since the timeout for Quick MCP client is also 60 secs and most of the agents take 2-4 minutes to return a response. So can you please suggest how to make this work?
Hi @shreyavj,
This is indeed the case because according to documentation, the fixed 60 second timeout causes an HTTP 424 error.
I would recommend (if possible via FastMCP) to have the job work in the background and then call an applicable endpoint through the Quick client. If this is achievable, then the streaming response can still occur without it going over the 60 second limit.
If this (or another similar workaround) is not possible, I would definitely reach out to AWS Support by creating a support case, as they may be able to assist with your issue further.
@WLS-Luis is streaming not supported by QS as of today? Is it in the roadmap? If yes, do you have an ETA?
This is interesting, I have this support case open for this exact problem.
—- cut from case —–
I have conducted additional testing to determine whether missing HTTP headers might be causing Quick’s failure to load tools from my AgentCore Runtime-hosted MCP server. I added request header logging middleware to my MCP server and captured all headers sent by Quick during connection attempts.
The logs confirm that Quick correctly sends the required’
Accept: application/json, text/event-stream
Content-Type: application/json
headers, so missing headers don’t appear to be the issue. However, I observe that Quick only sends ping requests repeatedly for approximately 60 seconds before timing out with “Could not load actions.” I don’t see any initialize or tools/list requests in the logs, which I believe are required by the MCP protocol to discover available tools. In contrast, when I test the same server with the Python MCP SDK, it successfully sends the full protocol sequence (initialize → tools/list → tools/call) and works correctly. This suggests Quick might not fully support the standard MCP protocol flow for AgentCore Runtime-hosted servers, though I’m not certain of the root cause. I would appreciate AWS engineering’s investigation into why Quick doesn’t appear to progress beyond the ping phase.
—– paste ——-
from the docs
”With the Amazon Quick MCP client, you can connect to remote hosted MCP servers or your own hosted MCP servers. The Amazon Quick service includes an MCP client that can be used to securely connect Amazon Quick with AI agents and applications through MCP servers. The Amazon Quick MCP client supports server-sent events (SSE) and streamable HTTP for transport, and several authentication mechanisms including three-legged OAuth (3LO), two-legged OAuth (2LO), and No Auth. Amazon Quick supports OAuth 2.0 Dynamic Client Registration protocol to obtain OAuth client IDs without user interaction.”
the docs claim it supports SSE and Streamable. But it seems that something is going wrong. I smell a bug.
My case has been escalated to the iternal team, and i had a case update
“Internal team found the exception causing Quick unable to retrieve the list of available MCP tools from the Bedrock AgentCore runtime for your requests.”
Hi @mrpackethead,
Thanks so much for sharing your research into this case and letting us know about your current support case! @shreyavj please feel free as well to put up a support case with the previous link I attached in case there are any differences with your use case. I will also retag this topic as an error and this issue will eventually be followed back by the AWS Team!
So we got this working;
Hi, there, a few thigns that we have discovered;
-
Quick has an undocumented feature; it only accepts a maximum of 100 tools. This is 100% confirmed by support
-
Quick also sends MCP version 2025-03-26. Depending on how yoru server is operating it might not work with this version, and try and return a differnet version. QS does’tn seem to work with eariler versions that this. ( to be confirmed )
The lack of logging or errors is really problematic.