Tool Calling
A panel discussion with experts from Arcade, Prosus Group, and MeaningStack who argue that most teams are building agents incorrectly. They dissect the failures of simple API wrappers, the pros and cons of MCP, and the critical role of governance and organizational structure in deploying agents successfully.
The Problem with Tooling: Beyond Simple API Wrappers
A fundamental mistake many developers make is simply wrapping an existing API in natural language and calling it a “tool.” This approach fails in production because it doesn’t account for the agent’s intent or the complexity of user queries.
Alex Salazar of Arcade explains that production-grade tools should be viewed in layers of abstraction:
- Low-Level System Tools: Direct integrations with services like Google Drive.
- Workflow Tools: Business-logic-specific workflows that a service provider like Google would never build for you.
- Domain-Specific Tools: Highly specialized tools for a particular agent’s function.
For example, instead of asking an agent to navigate Google Drive to find a sales document (forcing it to reason and burn tokens), you should build a specific
get_brochuretool that encapsulates that logic. The agent’s goal isn’t to use Google Drive; it’s to get a brochure.
Nishikant Dhanuka from Prosus Group shared a real-world example from a food ordering agent. A simple search API works when a user types “burger,” but fails when the user says, “I’m hungry, and I’m with two friends and not sure what to order.” The team had to build a more sophisticated search_dish tool that first understands the user’s intent, translates it into multiple queries for the underlying search API, and then reranks the results. Giving the agent the raw API would cause it to “fall flat.”
The MCP Dilemma: When to Use It and Its Hidden Dangers
The Multi-agent Communication Protocol (MCP) is a powerful standard for unlocking a world of tools without writing custom integrations. However, its application requires careful architectural consideration.
When to use MCP:
- Remote MCP: Ideal for connecting to third-party services with pre-built MCP servers (e.g., using Arcade for Gmail and Slack integrations).
- Local MCP: Useful within an organization to share a common, custom-built tool (e.g., a centralized RAG service) across multiple internal agents, preventing code duplication.
When not to use MCP:
- If you control the entire codebase for a single agent and its tools, creating an MCP server is unnecessary overhead.
However, MCP introduces significant challenges:
- Security & Quality: Many public MCP servers are “trash” and pose a security nightmare. There is no certification to validate their safety or reliability.
- Context Bloat: Connecting an agent to a few MCP servers can quickly give it access to hundreds of tools (e.g., GitHub’s MCP has 93 tools). This can bloat the context window with over 50,000 tokens per turn before the user even asks a question. This leads to high costs, latency, and poor performance, as the LLM struggles to select the correct tool from a massive list.
- Versioning: The lack of versioning in the current MCP spec is a critical issue for production systems that rely on CI/CD and stability.
Governance, Trust, and the Rise of Multi-Agent Systems
As agents become more autonomous, governance becomes paramount. Simple guardrails are insufficient for complex operational environments.
Luciana Ledesma of MeaningStack advocates for a more dynamic approach. Her team uses “reasoning blueprints” to define a “safe trajectory space” for an agent, rather than prescribing a rigid path. This allows for creativity and adaptation while providing insight into the agent’s “world map” and reasoning process. This is operationalized through:
- Steward Agents: Autonomous agents that observe, evaluate, and create evidence about other agents’ behavior, enabling interventions that scale to the level of risk.
- Service Integrity Agreements: Similar to SLAs for APIs, these agreements establish operational constraints (e.g., token budget, time) to hold agents accountable.
Interestingly, Nishi points out that the primary driver for adopting multi-agent architectures is often governance and organizational ownership. At their food delivery company, different departments (catalog, promotions, pricing) own and maintain their respective sub-agents. This ensures the business logic within each agent is managed by the domain experts, making the system more robust and maintainable. This structure avoids a central team becoming a bottleneck or lacking the necessary business knowledge.
The Blurring Lines: What is the Future of Agents, Apps, and Tools?
Alex posed a thought-provoking question: “What’s the difference between an app, an agent, and a tool?”
The panel concluded that these distinctions are rapidly disappearing. An application with an LLM is an agent. A tool with an LLM is an agent. As LLMs become integrated into every layer of the stack, we may soon see these three concepts merge into one.
Cybersecurity in Practice
While theoretical risks exist, the most immediate cybersecurity threat in production today is delegated user authorization. The key challenge is ensuring an agent can perform an action on behalf of a specific user with the correct permissions. This prevents two critical failure modes:
- An agent performing an unauthorized action (e.g.,
drop table) because it inherited the user’s high-level permissions. - A low-permission user escalating their privileges by accessing a high-permission agent.
Properly implemented delegated authorization (like OAuth) is crucial for securing agentic systems. Additionally, keeping a “human in the loop” for approving sensitive tool calls remains a vital, albeit sometimes cumbersome, safety measure.