Add option to await browser tasks via env var

[samanthavbarron]

First off, after trying a bunch of similar tools, this is the best I've found for my use case so far. Great job! 🎉

This PR adds an environment variable option to wait for API calls to complete before returning the task. There's probably a better way of doing this.

My motivation for doing this is that I'm using this MCP server in an n8n workflow, however in n8n there's not a way to insert a delay between tool calls when using the agent node (AFAIK).

[hashkode]

Hey @samanthavbarron,

thanks for the kudos and playing with this mcp server! Sounds great, especially your deployment in a n8n environment.

We didn't settle for a license of this repo and a related contribution handling, so please bear with us to figure this out in the next days. We'll check your implementation and your hint regarding possibly more elegant options on this behavior. The flag is certainly a valid option, another one might be a parameter to the mcp call or another mcp tool altogether, let's see.

If you have further remarks or concerns, feel free to comment over here or shoot us an email to info at cobrowser.xyz.

[michiosw]

Hey @samanthavbarron, thanks for the PR and the suggestion! The flag is a great idea—In addition I’d recommend adding it as a parameter to the existing mcp tool rather than creating a new tool. This approach offers greater flexibility on the client side, accommodating various integration scenarios depending on the specific MCP client used (e.g., cursor, MCP inspector), since each provides different interactions with MCP servers.

[wtberry]

Hey, sorry to comment in the middle.
Thanks for this awesome PR @samanthavbarron :)
Would it be more useful to make a modifications to return the result from browser_use tool, when PATIENT option is enabled, instead of returning the task status and id like before??

[michiosw]

Hey @wtberry — I think you made a great call. When we're awaiting the browser_use task itself, the response shouldn't include the job ID. Since there are no further updates at that point, the job ID doesn't really serve a purpose.

That said, I do think keeping the status field is still useful and makes sense.

[wtberry]

@michiosw Sounds good, I can create a PR to make that change once this PR is approved and merged.
Any idea when it might be approved?

[michiosw]

Hey @wtberry probably today or tomorrow. I will need to add some adjustments but then it should be ready to go so you can create your PR. Make sure to check our contribution docs.

[michiosw]

Hey @wtberry and @samanthavbarron , I added necessary changes and will merge the PR later today. Thank you for your contribution!

[wtberry]

@michiosw Thanks! I will go ahead and create PR when ready!

[michiosw]

@wtberry I think this PR covers all the features you suggested. However, feel free to review and open another PR if you see any room for improvement!

[michiosw]

🎉 This PR is included in version 1.0.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀