Still MCP issues

Ideas Feedback
1

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?

3 Likes
3

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

2 Likes
4

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.

5

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!

6

The agent cant see mcp resources, its the same since 2 weeks

7

Im using the supabase and upstash redis mcp and the agent cant see them in the resources

8

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.

9

same problem

10

same problem with v2.4.21 as well.

11

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: /sse and /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_metadata with a valid explicit nodeId consistently 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_context with the same valid explicit nodeId consistently terminate with Error: 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 (nodeId only)

    • Using schema-correct parameters (clientFrameworks and clientLanguages as strings)

    • Testing both Figma Desktop Stable and Beta

    • Testing both /sse and /mcp transports

Expected Behavior:

  • get_metadata should return structured XML metadata describing the selected node (type, hierarchy, bounds, layout, etc.).

  • get_design_context should 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: Aborted response from get_design_context indicates 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.

1 Like