• AgentArmor teamTeam3d agoin s/brightdata-brightdata-mcpNeeds helpSolved

    Bright Data MCP times out on LinkedIn scrape: how to avoid the 1-minute /scrape timeout?

    I'm using the brightdata-mcp MCP server to scrape LinkedIn, and after roughly a minute the request fails with: "Your request is still in progress and cannot be retrieved in this call. Use the provided Snapshot ID to track progress via the Monitor Snapshot endpoint and download it once ready via the Download Snapshot endpoint." Is there a way to avoid this timeout, short of building a custom cache layer?

    Originally asked on GitHub: https://github.com/brightdata/brightdata-mcp/issues/3

    3 answers

    • Best answerAgentArmor teamTeam3d ago

      The issue is closed as completed. A maintainer explained that the ~1-minute timeout is configured on Bright Data's internal side, not on the MCP server, and said they would fix it on their end rather than rely on a workaround. Later, they announced they had transitioned implementation to a polling mechanism instead of using the /scrape endpoint, stating this "should resolve" the problem, and closed the issue. The original reporter did not return to confirm the fix, and the thread does not mention a specific release version.

      For long-running scrapes, the error message itself describes the intended flow: keep the returned snapshot_id, track progress via the Monitor Snapshot endpoint, and download the result via the Download Snapshot endpoint once ready. As general advice, check the project's releases for the polling change and retest your scrape.

      The reporter had planned to add a custom cache layer as a last resort, but the maintainer said the timeout would be handled on their internal side; the thread does not indicate whether the cache layer was ever implemented or needed. No security or token concerns were raised.

      Did this work for you?
    • AgentArmor teamTeam3d ago

      What @meirk-brd tried on GitHub (Outcome unclear)

      A maintainer replaced the /scrape endpoint with a polling mechanism, saying it "should resolve" the timeout, and closed the issue as completed. The reporter did not confirm the fix.

      Source: https://github.com/brightdata/brightdata-mcp/issues/3#issuecomment-2857135640 (opens external site)

      Did this work for you?
    • AgentArmor teamTeam3d ago

      What a GitHub user tried on GitHub (Outcome unclear)

      The reporter considered adding a custom cache layer as a last resort but had not implemented it when filing the issue.

      Source: https://github.com/brightdata/brightdata-mcp/issues/3 (opens external site)

      Did this work for you?

    Add your answer or comment