Depends a bit on where your agent runs and how/if you built it.
I'm not arguing if one or the other is better but I think the distinction is the following:
If an agent understands MCP, you can just give it the MCP server: It will get the instructions from there.
Tool-Calling happens at the level of calling an LLM with a prompt. You need to include the tool into the call before that.
So you have two extremes:
- You build your own agent (or LLM-based workflow, depending on what you want to call it) and you know what tools to use at each step and build the tool definitions into your workflow code.
- You have a generic agent (most likely a loop with some built-in-tools) that can also work with MCP and you just give it a list of servers. It will get the definitions at time of execution.
This also gives MCP maintainers/providers the ability/power/(or attack surface) to alter the capabilities without you.
Of course you could also imagine some middle ground solution (TCDCP - tool calling definition context protocol, lol) that serves as a plugin-system more at the tool-calling level.
But I think MCP has some use cases. Depending on your development budget it might make sense to use tool-calling.
I think one general development pattern could be:
- Start with an expensive generic agent that gets MCP access.
- Later (if you're a big company) streamline this into specific tool-calling workflows with probably task-specific fine-tuning to reduce cost and increase control (Later = more knowledge about your use case)
I've rarely seen any non elementary use cases where just giving access to an MCP server just works, often times you need to update prompts to guide agents in system prompts or updated instructions. Unless you are primarily using MCP for remote environments (coding etc or to a persons desktop) the uses of it over normal tool calling doesn't seem to scale with complexity.
Depends a bit on where your agent runs and how/if you built it.
I'm not arguing if one or the other is better but I think the distinction is the following:
If an agent understands MCP, you can just give it the MCP server: It will get the instructions from there.
Tool-Calling happens at the level of calling an LLM with a prompt. You need to include the tool into the call before that.
So you have two extremes:
- You build your own agent (or LLM-based workflow, depending on what you want to call it) and you know what tools to use at each step and build the tool definitions into your workflow code.
- You have a generic agent (most likely a loop with some built-in-tools) that can also work with MCP and you just give it a list of servers. It will get the definitions at time of execution.
This also gives MCP maintainers/providers the ability/power/(or attack surface) to alter the capabilities without you.
Of course you could also imagine some middle ground solution (TCDCP - tool calling definition context protocol, lol) that serves as a plugin-system more at the tool-calling level.
But I think MCP has some use cases. Depending on your development budget it might make sense to use tool-calling.
I think one general development pattern could be:
- Start with an expensive generic agent that gets MCP access.
- Later (if you're a big company) streamline this into specific tool-calling workflows with probably task-specific fine-tuning to reduce cost and increase control (Later = more knowledge about your use case)
I've rarely seen any non elementary use cases where just giving access to an MCP server just works, often times you need to update prompts to guide agents in system prompts or updated instructions. Unless you are primarily using MCP for remote environments (coding etc or to a persons desktop) the uses of it over normal tool calling doesn't seem to scale with complexity.