Why does the Puppeteer MCP server fail with a network error after taking a screenshot?
Using the Puppeteer MCP server from modelcontextprotocol/servers with the Claude desktop app, I asked Claude to describe a webpage. It navigates to the site and takes the screenshot, but then an error popup about a network issue appears and the request fails before Claude analyzes the image. My mcp.log only shows successful MCP connections. Is there a fix?
Originally asked on GitHub: https://github.com/modelcontextprotocol/servers/issues/146
3 answers
Closed as NOT_PLANNED — no fix is coming. In May 2025 a maintainer announced this server was moved to the archived
modelcontextprotocol/servers-archivedrepository, is no longer actively maintained, and recommended checking the alternatives listed in the Readme ofmodelcontextprotocol/servers.What the thread establishes: navigation and the screenshot permission succeed, then Claude shows an error popup about a network issue and the request dies before it can analyze the image. The reporter's
mcp.logonly records server connection attempts and successes, with no helpful error. One commenter reported that even after a screenshot is taken, the PNG file is nowhere on the filesystem. Another commenter suggested the failure appears to be the server returning the image as a base64 response instead of writing it to the filesystem, citing a Cursor forum post about MCP image support — that diagnosis is tentative and was not verified in this thread.What was tried: retrying the same request immediately triggers a separate failure (issue #140), and quitting and relaunching Claude.app before retrying only reproduces the bug described here.
General advice: since the image never appears on disk, prefer a replacement server that writes screenshots to the filesystem rather than returning them as base64.
Did this work for you?What a GitHub user tried on GitHub (Didn't work)
The reporter retried the same request right after the network error, which led to a different failure (issue #140). Quitting Claude.app and relaunching before retrying only reproduced the original bug.
Source: https://github.com/modelcontextprotocol/servers/issues/146 (opens external site)
Did this work for you?What @andrewluetgers tried on GitHub (Outcome unclear)
A commenter suggested the failure appears to be the server returning the screenshot as a base64 response instead of writing it to the filesystem, citing a Cursor forum comment about MCP image support. This was a tentative diagnosis; no fix was verified.
Did this work for you?
Related questions
- mcp-server-fetch: 'AnyUrl' object has no attribute 'decode' error
- Does the official MCP Postgres example validate SQL before executing it?
- How to fix UTF-8 Japanese text corruption/crash in mcp-server-sqlite with Claude Desktop on Windows?
- MCP Knowledge Graph Memory Server fails with ${workspaceFolder} in MEMORY_FILE_PATH
- npx @modelcontextprotocol/server-filesystem: ERR_MODULE_NOT_FOUND for zod-to-json-schema