Repository navigation
Should concurrent tool execution be allowed? #47
Description
Activity
yes it should be allowed and shouldn't be our concern
all these tools are regular functions at the end of the day, so the author of them should take into account that they can be called in quick succession (i.e. before the first one completed).
i don't think this proposal needs to be concerned with userland architectural decisions like that
all tools will essentially be
awaited(or callback-style, whatever we go with in the end). the tool author can block until previous tool calls finish if they must.Reacted by Arnab Mondal and rektideFTR, the group discussed this issue and decided to punt this for later: https://www.w3.org/2026/01/22-webmachinelearning-minutes.html#1e43
Continued issue discussions is welcome. Depends on #51.
Comment in other issue addressing concurrency and proposing a solution: #51 (comment)
If these were simple tools then yes.
and with a single agent then the answer could still be yes.
but these actions can cause mutated state so if multiple agents are operating on the page independent of one another probably not.
i think the problem has more to do with coordination than with concurrency.
it would make alot of sense for the browser native agent to purposefully delegate to the subordinate/in page agents with a registered set of tools
in this way their would be inherent safety on these functions.
but if that's an impossibility then in-page agents shouldn't be using webmcp at all.
or the inpage agent having subsumed modelcontext prevents the browser agent from having seen them.
Since tool execution is async, multiple tools can be invoked in parallel. We should define whether that's expected behaviour that the site author should be expected to handle. I think yes, there will be enough cases where that makes sense and parallel execution will be a perf boost.
We can consider an annotation to indicate if a tool should be executed serially if there's cases where site authors need that guarantee.