When will you guys start to fix bugs instead of implementing new features who dont work either or changing the layout? Can i use my ultra subscription this month normaly again or will this really be my last expirience wirh cursor?
Just cancled my ultra subscription, sadly leaving cursor after such a long time, i never thought that you guys could â– â– â– â– up that badly, cursor was ahead of everyone and destroys it by themselfes. The downfall of cursor and the lost money of the VC funds will be a chapter in the tech history
Hey, thanks for the feedback.
I see that a lot of users are running into different MCP issues right now, from tool detection to the browser component. The team is aware of a few bugs in this area.
If you’re willing to share details, it’d be really helpful to know what exact MCP problems you had:
- Which MCP servers you tried to use
- What the bugs looked like (can’t see tools, can’t connect, something else)
- Your Cursor version
This will help us prioritize fixes. I get the frustration, but detailed reports really do help.
For what it’s worth, the MCP tool that’d been giving me problems since the tool enumeration issue started is now working again without any changes on my part (I’m still on Cursor 2.4.21, so assume that back-end fixes must have been made). As I noted in the other thread on this topic, most of the MCP tools in my server always worked; it was just a couple that weren’t picked up on server initialization. @anonix98 , have you tried your MCP today?
That being said, I resonate with your comment that there should be more focus on Cursor’s part in fixing bugs and producing well-tested, quality releases rather than introducing unnecessary UI changes and non-core features – fixing issues isn’t the glamorous part of software engineering, but the focus should be on keeping paying customers happy!
The agent cant see mcp resources, its the same since 2 weeks
Im using the supabase and upstash redis mcp and the agent cant see them in the resources
Thanks for the details about the Supabase and Upstash Redis MCP.
This is a known issue in version 2.3.41. MCP servers connect (you can see the tools in logs), but the agent doesn’t detect them. There are already several similar reports here: Agent chat "No MCP resources available" when trying to use MCP
What to try:
Update to version 2.4.21. A few users said the issue went away after updating with no extra steps. You can download it here: https://cursor.com/download
If the issue is still there on 2.4.21:
- Send the Request ID from the chat (three dots in the top right > Copy Request ID)
- Share your Cursor version (Menu > About Cursor > Copy)
- Share the MCP server status in Cursor Settings > Tools & MCP (green, yellow, or red)
Let me know if it works.
same problem
same problem with v2.4.21 as well.
When using the Figma Desktop MCP server with an MCP client (Cursor IDE), the core design extraction tools get_metadata and get_design_context do not return any usable design data, despite the server being reachable, tools being discovered, and parameters being validated successfully.
Environment:
-
OS: macOS
-
Figma Desktop Stable: 125.11.6
-
Figma Desktop Beta: 126.1.0
-
MCP Transport tested:
/sseand/mcp -
MCP Client: Cursor IDE
-
MCP Server URL:
http://127.0.0.1:3845/sse(also tested with/mcp)
Observed Behavior:
-
The MCP server starts correctly and is reachable.
-
Cursor successfully connects to the server, enumerates available tools, and validates tool arguments.
-
Calls to
get_metadatawith a valid explicitnodeIdconsistently return only an instructional string (e.g., “IMPORTANT: After you call this tool, you MUST call get_design_context…”) instead of the expected XML metadata (node hierarchy, bounds, layout, etc.). -
Calls to
get_design_contextwith the same valid explicitnodeIdconsistently terminate withError: Aborted, without returning any design context payload, partial output, or actionable error information. -
This behavior occurs even when:
-
Passing an explicit valid
nodeId -
Using minimal parameters (
nodeIdonly) -
Using schema-correct parameters (
clientFrameworksandclientLanguagesas strings) -
Testing both Figma Desktop Stable and Beta
-
Testing both
/sseand/mcptransports
-
Expected Behavior:
-
get_metadatashould return structured XML metadata describing the selected node (type, hierarchy, bounds, layout, etc.). -
get_design_contextshould return a design context payload (layout, spacing, typography, colors, and other design properties), or at minimum return a clear, actionable error if generation fails.
Why this appears to be a bug:
-
The tools are callable and pass schema validation, but return no data.
-
The instructional strings appear to be fallback guidance text rather than actual tool results.
-
The
Error: Abortedresponse fromget_design_contextindicates a server-side termination after the request is accepted. -
The issue is reproducible across Figma Desktop versions, transports, and parameter combinations, strongly indicating a server-side Figma Desktop MCP implementation issue, not a client or configuration problem.
Impact:
This prevents any design-to-code or metadata extraction workflows using the Figma Desktop MCP server, leaving get_screenshot as the only functional tool and forcing visual inference instead of structured design data.
same problem of @Rinzler
I have this same problem as well!
and it’s tricky, it looks like Cursor reads it because you can see the `get_design_context` response in the tool-call mini-panel, but it actually can’t use that result when asked if it can.
Cursor version: 2.5.17
Figma Desktop MCP (6 tools), status: green
@deanrie should I share the request ID publicly?
Thanks for the screenshot. get_design_context is returning an empty response, just a hint to call get_screenshot, with no code or assets.
Right now it’s not fully clear which side the issue is on. The Figma MCP server might not be sending data, or Cursor might be handling the response incorrectly. To help us debug:
- Please share the Request ID. Request IDs are safe to share publicly, and only we can check them. You can find it in Chat, click the three dots in the top right, then Copy Request ID.
- Does this happen with any nodeId or frame, or only specific ones?
I’ll pass this to the team to look into.
hi @deanrie,
this seems to be a problem on the Cursor side, as the Figma MCP seems to respond and the response is visible in the panel, as per the previous screenshot!
this response, however, seems not to be read from the AI, which is only be able to read the final warning phrase `IMPORTANT: After you call this tool, you MUST call get_screenshot to get a screenshot of the node for context.`.
you can see that from the AI answer in this other screenshot:
I can’t seem to find the RequestID for the first conversation above, but here is the RequestID for this second chat: 2c65dee5-9d99-4fc8-a357-c3ceaea545ad
thanks!
I had this issue until today, but after getting the latest update seems to be resolved - Cursor Version: 2.5.25
yes, I did a quick check and it seems it was fixed on that version! 