Tool Calling 2.0: Autonomous Discovery and Multi‑Agent Workflow

AI Tool Calling 2.0 Overview

Traditional tool calling (e.g., OpenAI function calling) requires the model to output a JSON schema that names a tool and supplies its parameters. An external dispatcher parses the JSON, executes the tool, and returns the result, causing two‑stage interaction with multiple network round‑trips.

AI Tool Calling 2.0, first implemented by Anthropic Claude, lets the model emit executable code (typically Python or a DSL) that performs the tool call directly inside a controlled interpreter, eliminating the separate dispatcher step.

Function Call Origin

Early large language models could only generate text and could not interact with external systems such as real‑time stock prices, email services, or databases.

The first way to give models “action” capability was to let them decide which external program to invoke. The model expresses an intent (e.g., “query Beijing weather for tomorrow”), an external program calls the appropriate API, and the result is fed back to the model for final response generation.

OpenAI released this capability in June 2023 for GPT‑3.5 and GPT‑4. The workflow consists of four steps:

Define the tool. Developers declare a function, e.g., get_weather with parameters city and date.

Model decision. For the query “How’s the weather in Beijing tomorrow?” the model outputs:

{"function": "get_weather", "arguments": {"city": "北京", "date": "明天"}}

Execution. An external program parses the JSON, calls a weather API, and obtains a result such as “light rain, 15 °C”.

Answer. The model incorporates the real data into its final reply.

In this pattern the model acts as a dispatcher; the actual execution is performed by external code.

Tool Calling 1.0 Limitations

Pre‑registered tools. Only functions defined beforehand can be used. Adding a new capability requires a new definition and corresponding execution code, increasing development effort.

Single‑step interaction. The model can invoke a tool once per request. Multi‑step logic (e.g., “if it rains, reschedule the meeting”) must be hard‑coded by developers.

Fragmented interfaces. OpenAI, Google Gemini, and Anthropic each use different calling formats, forcing developers to rewrite adapters when switching models.

High integration cost. Each new capability (flight lookup, Jira operation, etc.) demands custom glue code.

Tool Calling 2.0 Foundations

MCP – Unified Interface

In November 2024 Anthropic introduced the Model Context Protocol (MCP), an open protocol that standardizes AI‑tool communication. MCP defines three core concepts:

Tools : actions the AI can execute (query, modify, create).

Resources : data the AI can read (file contents, database records).

Prompts : predefined interaction templates that guide the model in using a specific tool.

With MCP, a tool provider implements a server that follows the protocol; any MCP‑compatible model can connect without rewriting adapters. MCP also supports dynamic discovery, allowing a model to query available tools at runtime.

By early 2025 OpenAI and other vendors announced MCP support, indicating industry convergence on the standard.

A2A – Agent‑to‑Agent Collaboration

In April 2025 Google, Atlassian, Salesforce and others released the Agent‑to‑Agent (A2A) protocol. A2A defines message formats for task hand‑off, state synchronization, and result return among multiple specialized agents, enabling decomposition of complex tasks across agents (e.g., understanding, retrieval, code generation, testing, verification).

Skills – Composite Capabilities

Skills bundle a goal, a process, a set of tools, and decision logic into a reusable capability. Example – Code Review Skill:

Read code changes (file‑read tool).

Check each line against coding standards (knowledge‑retrieval tool).

Locate issues with line numbers (code‑search tool).

Suggest fixes (language generation).

Prioritize security concerns (decision logic).

From the user’s perspective this is a single “review the code” request, while the model internally orchestrates multiple tool calls without step‑by‑step prompting.

Another example – Brainstorming Skill: the model gathers project context, asks clarifying questions, generates multiple proposals, evaluates pros and cons, and finally produces a document, invoking file‑read, information‑retrieval, dialogue, and document‑generation tools behind the scenes.

Agentic Workflow – Autonomous Planning and Execution

Building on MCP, A2A, and Skills, Tool Calling 2.0 adds autonomous multi‑step loops: the model repeatedly plans, executes, evaluates, adjusts, and continues within a single task.

Example – Fix a code defect:

Read the source file.

Identify the bug.

Propose a fix.

Modify the code.

Run tests.

If tests fail, revise the fix and repeat.

Safety checks require explicit user confirmation for high‑risk actions such as file deletion or code push.

Challenges and Limitations

Intent‑understanding errors. Misinterpreted user intent can trigger unintended operations; current mitigations separate low‑risk automatic execution from high‑risk actions that need user approval.

External data security. Fetched data may contain malicious instructions (prompt injection) that could steer the model toward unsafe behavior; no complete mitigation exists yet.

Trust in multi‑agent collaboration. Ensuring reliability and preventing impersonation or anomalous behavior among cooperating agents remains an open enterprise concern.

Evolution Timeline

Progression:

Function Call → Tool Calling 1.0 → Tool Calling 2.0

Corresponding capability growth:

Single function call → Multiple tool usage → Autonomous tool discovery, workflow orchestration, skill learning, multi‑agent collaboration

The four pillars—MCP (standardized connection), A2A (agent collaboration), Skills (composite abilities), and Agentic workflows (autonomous planning)—collectively shift AI from knowledge retrieval to actionable execution.