Skip to content

Fix/1758 mcp screenshot#1774

Open
zhu6201976 wants to merge 2 commits intounclecode:developfrom
zhu6201976:fix/1758-mcp-screenshot
Open

Fix/1758 mcp screenshot#1774
zhu6201976 wants to merge 2 commits intounclecode:developfrom
zhu6201976:fix/1758-mcp-screenshot

Conversation

@zhu6201976
Copy link

The Fix:
Instead of relying on the shared filesystem (which is problematic in Docker), this PR modifies the MCP tool to return the base64-encoded screenshot data directly in the API response.

Why:
Users running Crawl4AI in Docker cannot access the container's /tmp or internal paths without complex volume mapping. Returning the data directly makes the tool "plug-and-play" for all MCP clients (like Claude Desktop or custom agents).

@ntohidi ntohidi changed the base branch from main to develop February 25, 2026 02:33
@ntohidi
Copy link
Collaborator

ntohidi commented Feb 25, 2026

hey @zhu6201976
Is this PR related to any existing issues? If so, could you please provide the issue number?

If it is not related to any issues, please specify the issue that this PR addresses, along with a sample code snippet.

Once I have this information, I will review the pull request. Thank you! :)

@zhu6201976
Copy link
Author

hey @zhu6201976 Is this PR related to any existing issues? If so, could you please provide the issue number?

If it is not related to any issues, please specify the issue that this PR addresses, along with a sample code snippet.

Once I have this information, I will review the pull request. Thank you! :)

Hi @ntohidi,

Thanks for the quick response!

This PR specifically addresses Issue #1758.

Problem: In Docker environments, saving screenshots to a local container path makes them inaccessible to the host machine/client without complex volume mounting.

Solution: This PR modifies the MCP tool to return the Base64-encoded image data directly in the response, ensuring a "plug-and-play" experience for all MCP clients.

Sample Code for Testing:
You can test this via the MCP bridge using a simple client call. Once the server is running in Docker, the response will now include the screenshot_base64 field:

Python

Example MCP Tool Call

result = await p.call_tool(
"crawl4ai_screenshot",
{
"url": "https://www.google.com",
"wait_for": "body"
}
)
The result now contains the direct base64 data:
print(result.content[0].text)
-> { "success": true, "screenshot_base64": "iVBORw0KGgoAAAANSUh..." }

Looking forward to your review!

@ntohidi
Copy link
Collaborator

ntohidi commented Feb 25, 2026

hey @zhu6201976 Is this PR related to any existing issues? If so, could you please provide the issue number?
If it is not related to any issues, please specify the issue that this PR addresses, along with a sample code snippet.
Once I have this information, I will review the pull request. Thank you! :)

Hi @ntohidi,

Thanks for the quick response!

This PR specifically addresses Issue #1758.

Problem: In Docker environments, saving screenshots to a local container path makes them inaccessible to the host machine/client without complex volume mounting.

Solution: This PR modifies the MCP tool to return the Base64-encoded image data directly in the response, ensuring a "plug-and-play" experience for all MCP clients.

Sample Code for Testing: You can test this via the MCP bridge using a simple client call. Once the server is running in Docker, the response will now include the screenshot_base64 field:

Python

Example MCP Tool Call

result = await p.call_tool( "crawl4ai_screenshot", { "url": "https://www.google.com", "wait_for": "body" } ) The result now contains the direct base64 data: print(result.content[0].text) -> { "success": true, "screenshot_base64": "iVBORw0KGgoAAAANSUh..." }

Looking forward to your review!

OK. got it! let me review and check. Thanks :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants