Summary
All remote MCP servers — and local MCP servers that use SSE/HTTP transport internally — fail to initialise in Amazon Quick v0.631.0. The error is MCPClientInitializationError: client failed to initialize and occurs before any network connection is attempted. Only pure-stdio local MCP servers are unaffected.
Environment
- Amazon Quick version: 0.631.0
- macOS version: 15.7.5
- Date first observed: 2026-05-11
Steps to Reproduce
- Open Amazon Quick → Settings → Capabilities → Connections
- Add any remote MCP server (e.g. Cloudflare at
https://mcp.cloudflare.com/mcp)
- Alternatively, add a local MCP server that uses SSE/HTTP transport internally (e.g.
@cloudflare/mcp-server-cloudflare npm package, or Figma MCP)
- Attempt to use any tool from that connector
Result: The connector fails to initialise. The error appears in logs immediately — it does not even attempt a network connection.
Error
MCPClientInitializationError: client failed to initialize
Full traceback (from logs):
Traceback:
mcp_client.py:209
mcp_client.py:754
user_mcp.py:444
typing_extensions.py:3004 ← TypeError originates here
The root cause is a TypeError in typing_extensions.py line 3004, within the strands SDK shipped with v0.631.0. This is a code-level crash, not a network or authentication failure.
What I’ve Ruled Out
Not a token/auth issue — removing and re-adding the API token does not fix it
Not a network issue — the error occurs before any connection is attempted (confirmed via traceback)
Not server-specific — affects all remote MCPs and all local MCPs using HTTP/SSE transport
Not fixed by full restart — restarting Amazon Quick does not resolve it
Affected Connectors (Confirmed)
| Connector |
Type |
Result |
| Cloudflare (remote) |
Remote MCP via HTTPS |
MCPClientInitializationError |
| Cloudflare (local npm package) |
Local, SSE/HTTP transport |
MCPClientInitializationError |
| Figma MCP (local) |
Local, SSE/HTTP transport |
MCPClientInitializationError |
Working Connectors (for reference)
| Connector |
Type |
Result |
Xero (@xeroapi/xero-mcp-server) |
Local, pure stdio |
Works correctly |
Analysis
The failure pattern strongly suggests the issue is in how the strands SDK (bundled with Amazon Quick v0.631.0) handles MCP type annotations during client initialisation. The typing_extensions.py:3004 TypeError fires before any protocol handshake occurs — meaning the client crashes while setting up its internal type machinery, not while communicating with the server.
Pure-stdio MCPs like Xero appear to bypass the affected code path, which is why they work. Any MCP that requires the HTTP/SSE client stack hits the crash.
Expected Behaviour
Remote MCP servers and local MCP servers using SSE/HTTP transport should initialise successfully and be available as connectors.
Workaround
None available within Amazon Quick. Current workarounds:
- Use the built-in browser skill to interact with affected services manually
- Use stdio proxy wrappers (e.g.
mcp-remote or supergateway) around remote URLs — these convert remote MCP endpoints to stdio, which avoids the broken code path
Additional Notes
Happy to provide full log output if that would help diagnose. I can reproduce this consistently across multiple MCP server configurations.
Hello @tscole, welcome to the Quick Community!
Thanks for providing such a detailed write up here. From what I understand, the partitioning between stdio working and HTTP/SSE failing is a strong signal, and the workaround you found with stdio proxies like mcp-remote actual reinforces the diagnosis since those don’t fix the underlying code path, they just route around it by re-presenting the remote server as stdio to the client.
Some additional details would help narrow down to the root cause:
- Can you share the exact TypeError message from
typing_extensions.py:3004? Since the line moves between releases of typing_extensions, the actual error message would point to different root causes.
- Can you confirm the bundled versions of
typing_extensions, mcp, and strands-agents that ship with Quick v0.631.0? If you can locate the Python environment Quick uses, a pip show on those three packages would be ideal.
- Does the crash happen at the moment you save the connector configuration, or only on first tool invocation? The traceback path through
user_mcp.py:444 suggests the latter, but confirming this could help narrow down the potential issues.
- Have you checked the Strands Agents GitHub repo (
strands-agents/sdk-python) for existing issues? Maybe it has been reported on if it is an SDK level bug and we might be stuck waiting for a release to roll out.
Happy to take another look once you are able to provide some additional details. This should be easier to pinpoint once I can see the exact error message.
Hi @DylanMorozowski, thanks for the detailed follow-up — happy to provide the additional details.
1. Exact TypeError message
The full error as it appears in the Amazon Quick logs:
TypeError: issubclass() arg 1 must be a class
File “…/typing_extensions.py”, line 3004
2. Bundled package versions
How would I locate Python environment Amazon Quick uses? Could you provide a bit more info on how to do that — step-by-step instructions on where to find it (and how to run pip show typing_extensions mcp strands-agents against it) would be really helpful if possible.
3. Crash timing — config save vs. first tool invocation
The crash happens on first tool invocation, not at config save. The connector saves successfully and shows as connected in the UI. The MCPClientInitializationError only surfaces the moment I attempt to use a tool from that connector.
4. Strands Agents GitHub
I checked the Strands Agents repo before posting and didn’t find an exact match for this specific typing_extensions:3004 + issubclass combination. It may be specific to how Amazon Quick bundles the SDK rather than an upstream issue.
Happy to pull full log output if that would help too.
Hi @tscole,
To run find the bundled Python environment, I would run both of the below commands (feel free to tweak these based on your Terminal) to obtain a respective full path:
find /Applications/Amazon\ Quick.app -name "python3" 2>/dev/null
find ~/Library/Application\ Support/Amazon\ Quick -name "python3" 2>/dev/null
Then run this following command with that full path:
/path/to/python3 -m pip show typing_extensions mcp strands-agents
Once you have the output, feel free to paste it here. My suspicion is that there’s a version mismatch at play, specifically that typing_extensions is older than what mcp and strands-agents require, which would explain why the HTTP/SSE client stack crashes on initialization while stdio continues to work fine.
Let me know if this helps!
Hi @tscole,
Just checking back in since this thread hasn’t received a response in a while. Was my most recent reply helpful to you and/or were you able to find a solution yourself in the meantime? Please help the community by marking this answer as “Solution” or following up in general within the next 3 business days!
Thanks!
Hi @tscole,
Since I haven’t received any further updates from you, I’ll treat this inquiry as complete for now. If you have any additional questions, feel free to create a new post in the community and link this discussion for context.
Thank you!