# Tool Calling

Alex Salazar, Arcade.dev & Nishikant Dhanuka, Prosus Group & Luciana Ledesma, MeaningStack | Agents in Production 2025 | 40:22
Hosted by Demetrios Brinkmann

Source: https://www.youtube.com/watch?v=mxD2Eeb_Bp0
Channel: MLOps Community, now AAIF Live (https://www.youtube.com/@AAIFLive-x1r). Summarised by MLOps Talks.
Page: https://mlopstalks.com/talks/tool-calling
Published: 2026-02-16
Tags: agents, governance, mcp, multi-agent, tool-use

## TL;DR
- A production tool is more than an API wrapped in natural language. It should reflect the agent's intent and handle the workflow needed to complete a task.
- MCP is useful for shared services and third-party connections, but it can create security problems and overload an agent's context with too many tools.
- Multi-agent systems often exist because different departments need to own different parts of the business logic, rather than only because of technical limits.

## Summary
The panel examines what tool calling requires when agents move beyond demos. Alex Salazar describes three tool layers: low-level service tools, organization-specific workflows, and agent-specific domain tools. Nishikant Dhanuka gives a food-ordering example where an agent interprets natural language, turns it into search queries, and reranks results instead of calling a basic search API. The panel discusses MCP as a useful way to connect agents to shared or external services, while warning that untrusted servers, excessive tool counts, and large context requirements create practical risks. Luciana Ledesma argues for reasoning blueprints, evaluations, operational constraints, and graded intervention. The speakers also discuss tool ownership, governance, versioning, authorization, and human approval. They describe multi-agent architectures as a way to assign responsibility for business domains to the teams that understand them. The discussion ends with the claim that apps, agents, and tools are becoming difficult to distinguish when an LLM is involved.

## Key ideas
### A production tool must express the agent's intent
[03:13](https://www.youtube.com/watch?v=mxD2Eeb_Bp0&t=193s)
Alex Salazar says teams often wrap an API in natural language and call it a tool. That can produce a working demo, but it often fails to reach production accuracy. He separates tools into service-level tools, organization-specific workflows, and agent-specific domain tools. In his sales-agent example, the agent does not really want to navigate Google Drive. It wants to retrieve the right brochure for a meeting with Spotify. A dedicated "get brochure" tool can perform the navigation and business logic, while a raw Google Drive tool forces the model to reason through irrelevant details and spend more tokens.

### Natural-language agents need tools that interpret intent
[06:15](https://www.youtube.com/watch?v=mxD2Eeb_Bp0&t=375s)
Nishikant Dhanuka describes a food-ordering agent that cannot rely on an existing search API. A person may say, "I'm hungry," or explain that they are with two friends and do not know what to order. The existing API works for a query such as "burger," but it does not handle those broader requests. The team built a "search dish" tool that understands the user's intent, converts it into queries for the search API, and reranks the results. That combined behavior is what makes the tool useful to the agent.

### Governance needs evidence about reasoning and room for safe exploration
[07:45](https://www.youtube.com/watch?v=mxD2Eeb_Bp0&t=465s)
Luciana Ledesma describes agents as maintaining a changing "world map" that can be wrong when the agent misunderstands its environment. Her team uses reasoning blueprints and evaluates how the agent's map relates to the intended world map. The goal is to define a safe trajectory space rather than prescribe every step. An agent can leave that space creatively, but people need evidence to judge whether the behavior still matches the intended goal. She also argues for sandboxes where agents can act with freedom inside bounded conditions.

### MCP is useful when tools are shared, external, or outside the agent runtime
[11:39](https://www.youtube.com/watch?v=mxD2Eeb_Bp0&t=699s)
Nishikant Dhanuka distinguishes remote and local MCP. Remote MCP can connect an agent development platform to services such as Gmail and Slack without each team writing separate integration code. Local tools owned by the same team and codebase do not automatically need an MCP server. MCP becomes more useful when a service is shared by several agents, such as a central FAQ retrieval service for restaurant-related agents. The panel frames the decision as an architectural one, based on ownership, sharing, and external connectivity.

### Uncontrolled MCP adoption can create security and context problems
[14:03](https://www.youtube.com/watch?v=mxD2Eeb_Bp0&t=843s)
Nishikant Dhanuka warns that many MCP servers are poorly built and may create security risks. He also points to the number of tools exposed by large services. GitHub's MCP server is described as having 93 tools, and adding Gmail and Slack can quickly give an agent hundreds of tools. The panel says those descriptions can consume a large context before the user asks a question, making tool selection harder. They discuss an Anthropic approach in which the model receives a code-execution tool and uses code to call and process MCP services instead of receiving every service directly.

### Tool architecture trades determinism against breadth
[18:43](https://www.youtube.com/watch?v=mxD2Eeb_Bp0&t=1123s)
Alex Salazar says a narrowly designed agent can use more predetermined code, tightly placed tools, and MCP servers. That approach can improve speed, accuracy, and cost. A broadly capable agent can instead receive a sandbox and write code to access many tools. This gives it more freedom, but increases token use, latency, and uncertainty. He says there is no universal choice because the right balance depends on the system being built. The panel also argues that good descriptions, parameters, separation by intention, and well-built MCP servers matter more than the particular mechanism used to call them.

### Governance should follow risk and start after teams learn from real agents
[25:36](https://www.youtube.com/watch?v=mxD2Eeb_Bp0&t=1536s)
The speakers reject a large governance exercise as the first step for an organization that has not yet shipped an agent. Alex Salazar recommends getting one or two agents into production, then examining which tools are shared and who should access them. Nishikant Dhanuka describes duplicated tools across teams and the difficulty of creating a central team without slowing delivery. Luciana Ledesma proposes agents that observe and evaluate other agents, collect evidence, and create graded intervention points. In her view, governance should scale to risk rather than apply the same controls everywhere.

### Multi-agent systems can assign ownership of business domains
[28:30](https://www.youtube.com/watch?v=mxD2Eeb_Bp0&t=1710s)
Nishikant Dhanuka says the practical reason to build a multi-agent system may be governance. In a restaurant system, catalog, promotions, and pricing can each have their own agents owned by the departments with the relevant business knowledge. Those departments can update their agents when business rules change. This avoids giving one team responsibility for maintaining logic it does not understand. The panel also raises the unresolved question of how agents should communicate, including whether treating an agent as an MCP tool loses useful reasoning information.

### Authorization and versioning are production requirements
[32:04](https://www.youtube.com/watch?v=mxD2Eeb_Bp0&t=1924s)
The panel treats versioning and authorization as basic requirements for production systems. Alex Salazar says tools must be versioned so teams can run CI and CD. Nishikant Dhanuka describes human approval before a tool call and a planned way for users to select only some tools from a large MCP server. The speakers also discuss runtime authorization, where the agent authenticates when it needs to act. Alex identifies delegated user authorization as a major current gap because an agent can otherwise act with more access than the user should have, or use a user's broad permissions in unsafe ways.

## Notable quotes
- Alex Salazar: "A lot of people will take an API, wrap it in natural language, and then say, "I've got a tool."" (03:13)
- Demetrios Brinkmann: "The tool itself means nothing if you don't know what the intention behind it is." (10:51)
- Nishikant Dhanuka: "MCP is amazing, but then it also makes easy to just bloat the context with all these tools." (15:42)
- Nishikant Dhanuka: "The real reason to build multi-agent is actually governance." (29:10)
- Alex Salazar: "The distinction between application, agent, and tool is very rapidly blurring." (31:16)

## Tools & references mentioned
- Arcade.dev
- Tukan
- Gmail
- Slack
- Google Drive
- MCP
- Model Context Protocol
- GitHub
- Anthropic
- Claude Code
- Manus
- iFood
- SLA
- service integrity agreement
- OAuth

## Who should watch
- You are building agents and need to decide whether an API, workflow, domain tool, or MCP server is the right abstraction.
- Your agents already have many tools and you are dealing with context size, authorization, tool ownership, or unreliable MCP servers.
- You are planning a multi-agent platform and need practical guidance on governance, department ownership, versioning, and human approval.

## Related talks

- [Expanding context engineering to the tooling layer](https://mlopstalks.com/talks/expanding-context-engineering-to-the-tooling-layer) (Frank Wittkampf, Databook, 26:18)
- [Building Agentic Tools for Production](https://mlopstalks.com/talks/building-agentic-tools-for-production) (Sam Partee, Arcade AI, 23:55)
- [Enterprise-ready MCP](https://mlopstalks.com/talks/enterprise-ready-mcp) (Jiquan Ngiam, MintMCP, 28:36)
- [MCP Security: What Happens When Your Agents Talk to Everything?](https://mlopstalks.com/talks/mcp-security-what-happens-when-your-agents-talk-to-everything) (, 24:26)
- [Tool definitions are the new Prompt Engineering](https://mlopstalks.com/talks/tool-definitions-are-the-new-prompt-engineering) (Chiara Caratelli, Prosus Group & Alex Salazar, Arcade.dev, 57:12)