MCP plugin Error and timeouts?

Contribution Plugins
,
1

im having trouble running large task via the MCP server? And MCP giving a error and time out?

2

Have you tried checking your configuration settings for this? A few things that commonly cause this type of issue:

  1. Check if there are any recent updates or changes to your setup that might have triggered this behavior.

  2. Look at the logs for any error messages around the time this started happening. The specific error codes will point you to the root cause faster than guessing.

  3. If you are self-hosting, make sure your environment variables and config files are properly set. Sometimes a missed setting after an upgrade causes exactly this kind of problem.

What version are you running, and did this start after a specific change?

4

Thanks for the pointers.

Config: I’m on the default/local MCP setup (Cursor → http://localhost:4401/mcp, Penpot MCP plugin loading the dev plugin URL on localhost:4400). Nothing exotic changed besides normal Cursor updates.

Recent changes: It correlates with bigger execute_code payloads (one large script) — small calls still work. Our main workflow is bulk-adding Material icons via a pipeline script (many SVG strings embedded in one JS payload), which is when it shows up.

Logs: I’ll grab the exact error text + timestamp next time; I haven’t saved a clean snippet yet.

Self-hosting: I run the Penpot MCP server locally from the npx @penpot/mcp cache (standard env; no custom tuning). Penpot itself is [cloud / self-hosted — pick one]. Optional Cloudflare tunnel sometimes, but the issue also happens on pure localhost.

Versions: Cursor 3.0.9 (arm64). Penpot MCP @penpot/mcp 1.0.0 (from my npx-installed package). It didn’t start from one single upgrade I can name — it got worse as tasks and payloads got larger.

5

What you’re running into doesn’t look like a random MCP failure. It’s much more likely a scaling issue in how the workload is being executed.

From your description (small calls work, large payloads with many SVGs fail), the pattern is pretty clear: once the payload and execution time grow, you start hitting limits. Either in MCP itself or in the client (Cursor).

What I’d recommend

  • Split the workload into smaller chunks (e.g. 20–50 icons per call instead of one big script)

  • Avoid embedding large amounts of SVG data in a single payload if possible

  • Keep each execute_code focused and short-lived

  • If you’re doing heavy bulk import pipelines, MCP might not be the best layer for that. A direct plugin or external processing step will be more reliable

In short: MCP works best with iterative, smaller operations, not large monolithic scripts.

There’s also a second factor that might be contributing here: client-side timeouts.

You’re using Cursor, and some clients have fairly aggressive timeout limits for tool execution. If your script runs too long, the client may terminate the request even if MCP hasn’t technically failed.

  • If Cursor allows increasing the timeout, it’s worth trying

  • That said, documentation on this is unclear, and some users report that it’s not configurable

If that’s the case, another practical option is to try the same workflow with a different MCP-compatible client and see if the behavior changes.