---
title: "Summary: Google's Agent Tools & MCP Interoperability"
url: "https://vanducng.dev/2026/01/11/Google-Agent-Tools-MCP-Whitepaper-Summary/"
date: "2026-01-11"
series: "agentic-ai"
categories: ["AI"]
tags: ["llm","agentic-ai","tool-calling","mcp"]
---

# Summary: Google's Agent Tools & MCP Interoperability

Following our coverage of [Google's Introduction to Agents](https://vanducng.dev/2026/01/10/Google-Introduction-to-Agents-Whitepaper-Summary/), this post dives into the companion whitepaper on **Agent Tools and Model Context Protocol (MCP)**. While the first paper covered agent architecture, this one focuses on *how agents interact with the world* through tools and the emerging interoperability standard.

> **Source**: [Agent Tools & Interoperability with MCP (PDF)](https://drive.google.com/file/d/1ENMUDzybOzxnycQQxNh5sE9quRd0s3Sd/view) by Google

## Why Tools Matter

Without tools, LLMs are fundamentally limited. They are pattern prediction engines trained on historical data with a fixed knowledge cutoff. Tools transform them from passive responders into active participants capable of:

- **Accessing real-time information** (search, APIs, databases)
- **Taking consequential actions** (sending emails, creating files, executing code)
- **Interacting with external systems** (enterprise apps, third-party services)

We explored this transformation in [Anatomy of an AI Agent](https://vanducng.dev/2025/10/30/Anatomy-of-an-AI-Agent-Building-Blocks-and-Workflows/) where tools serve as the "hands" of an agent system.

```mermaid
flowchart TB
    subgraph With["With Tools"]
        direction LR
        L2["LLM"] --> T["Tool Call"]
        T --> E["External System"]
        E --> O["Real-time Result"]
        O --> L2
    end

    subgraph Without["Without Tools"]
        direction LR
        L1["LLM"] --> R1["Static Response
(Knowledge Cutoff)"]
    end

    classDef blueClass fill:#4A90E2,stroke:#333,stroke-width:2px,color:#fff
    classDef orangeClass fill:#F39C12,stroke:#333,stroke-width:2px,color:#fff
    classDef greenClass fill:#27AE60,stroke:#333,stroke-width:2px,color:#fff

    class L1,L2 blueClass
    class T,E orangeClass
    class R1,O greenClass
```

## Types of Tools

The whitepaper categorizes tools into three distinct types:

### 1. Function Tools

Custom functions defined by developers for specific tasks. The LLM receives function signatures (name, description, parameters) and decides when to call them.

```python
def set_light_values(
    brightness: int,
    color_temp: str,
    context: ToolContext) -> dict[str, int | str]:
    """Sets brightness and color temperature of room lights.

    Args:
        brightness: Light level from 0 to 100. Zero is off.
        color_temp: Color temperature: 'daylight', 'cool', or 'warm'.
        context: ToolContext object for user's location.
    Returns:
        Dictionary with set brightness and color temperature.
    """
    # Implementation
    return {"brightness": brightness, "colorTemperature": color_temp}
```

Key aspects:
- Developer controls logic and implementation
- Schema defines input/output contracts
- LLM uses description to determine when/how to invoke

### 2. Built-in Tools

Pre-built capabilities provided by model hosts:

| Tool | Purpose |
|------|---------|
| **Google Search** | Real-time web information via grounding |
| **Code Execution** | Run Python in sandboxed environment |
| **URL Context** | Fetch and process web page content |

These require no custom code, just enabling in configuration.

### 3. Agent Tools

Entire agents wrapped as tools for other agents to invoke. This enables hierarchical architectures where a parent agent delegates specialized tasks.

```python
from google.adk.agents import LlmAgent
from google.adk.tools import AgentTool

# Specialized sub-agent
capital_agent = LlmAgent(
    model="gemini-2.5-flash",
    name="capital_agent",
    description="Returns capital city for any country or state"
)

# Parent agent with sub-agent as tool
user_agent = LlmAgent(
    model="gemini-2.5-flash",
    name="user_advice_agent",
    tools=[AgentTool(agent=capital_agent)]
)
```

This pattern enables the multi-agent architectures we discussed in [Multi-Agent Patterns and Coordination](https://vanducng.dev/2025/11/20/Multi-Agent-Patterns-and-Coordination/).

## Tool Design Best Practices

The whitepaper emphasizes that tool quality directly impacts agent effectiveness:

| Principle | Description |
|-----------|-------------|
| **Clear Naming** | Use intuitive, action-oriented names (`get_weather`, `send_email`) |
| **Rich Documentation** | Detailed descriptions help LLM understand when to use |
| **Explicit Parameters** | Type annotations, constraints, defaults |
| **Granularity** | Single-purpose tools over multi-function monoliths |
| **Concise Output** | Only return what's needed; verbose outputs waste context |
| **Validation** | Validate inputs before execution |
| **Error Messages** | Return actionable error messages, not stack traces |

> A well-documented tool is used correctly. A poorly documented tool is a liability.

## The N×M Integration Problem

Before standardization, connecting AI applications to external tools required custom integrations:

```mermaid
flowchart TB
    subgraph Apps["AI Applications (N)"]
        A1["App 1"]
        A2["App 2"]
        A3["App 3"]
    end

    subgraph Tools["External Tools (M)"]
        T1["Tool A"]
        T2["Tool B"]
        T3["Tool C"]
    end

    A1 --> T1
    A1 --> T2
    A1 --> T3
    A2 --> T1
    A2 --> T2
    A2 --> T3
    A3 --> T1
    A3 --> T2
    A3 --> T3

    classDef blueClass fill:#4A90E2,stroke:#333,stroke-width:2px,color:#fff
    classDef orangeClass fill:#F39C12,stroke:#333,stroke-width:2px,color:#fff

    class A1,A2,A3 blueClass
    class T1,T2,T3 orangeClass
```

**Problem**: N applications × M tools = N×M custom integrations. Adding a new tool requires updating every application.

**Solution**: A standardized protocol where each application implements one interface and each tool exposes one interface.

## Model Context Protocol (MCP)

MCP is an open protocol (initiated by Anthropic, now community-driven) that standardizes how AI applications connect to external data sources and tools. It draws inspiration from the Language Server Protocol (LSP) which solved the same N×M problem for IDE integrations.

### Architecture

```mermaid
flowchart TB
    subgraph Host["MCP Host (e.g., Claude Desktop)"]
        App["AI Application"]
        C1["MCP Client"]
        C2["MCP Client"]
    end

    subgraph Servers["MCP Servers"]
        S1["Server: GitHub"]
        S2["Server: PostgreSQL"]
        S3["Server: Slack"]
    end

    App --> C1
    App --> C2
    C1 --> S1
    C1 --> S2
    C2 --> S3

    classDef blueClass fill:#4A90E2,stroke:#333,stroke-width:2px,color:#fff
    classDef orangeClass fill:#F39C12,stroke:#333,stroke-width:2px,color:#fff
    classDef greenClass fill:#27AE60,stroke:#333,stroke-width:2px,color:#fff

    class App blueClass
    class C1,C2 orangeClass
    class S1,S2,S3 greenClass
```

**Three roles**:
- **Host**: Application managing connections (Claude Desktop, IDE, custom app)
- **Client**: Protocol handler within host, maintains 1:1 connection to server
- **Server**: Lightweight service exposing specific capabilities

### Communication Layer

MCP uses **JSON-RPC 2.0** over two transport options:

| Transport | Use Case | Communication |
|-----------|----------|---------------|
| **stdio** | Local processes | stdin/stdout |
| **Streamable HTTP** | Remote services | HTTP + Server-Sent Events |

The shift from WebSocket to Streamable HTTP enables easier deployment in serverless environments while supporting bidirectional communication.

## MCP Primitives

MCP defines six core primitives, each solving specific interaction patterns:

| Primitive | Adoption | Control | Purpose |
|-----------|----------|---------|---------|
| **Tools** | 99% | Model | Functions the LLM can invoke |
| **Resources** | 34% | Application | Data sources explicitly requested by host |
| **Prompts** | 32% | User | Pre-written templates users select |
| **Sampling** | 10% | Server→Model | Servers request LLM completions |
| **Roots** | 5% | Server | Filesystem access boundaries |
| **Elicitation** | 4% | Server→User | Servers request user input |

### Tool Definition Example

```json
{
  "name": "get_stock_price",
  "title": "Stock Price Retrieval Tool",
  "description": "Get current or historical stock price for a ticker symbol",
  "inputSchema": {
    "type": "object",
    "properties": {
      "symbol": {
        "type": "string",
        "description": "Stock ticker symbol (e.g., GOOGL, AAPL)"
      },
      "date": {
        "type": "string",
        "description": "Date for historical price (YYYY-MM-DD)"
      }
    },
    "required": ["symbol"]
  },
  "annotations": {
    "readOnlyHint": "true"
  }
}
```

## Tool Annotations

The `annotations` field provides behavioral hints without changing core functionality:

| Annotation | Purpose |
|------------|---------|
| `readOnlyHint` | Tool only reads data, no side effects |
| `destructiveHint` | Tool may delete or modify data irreversibly |
| `idempotentHint` | Multiple calls produce same result |
| `openWorldHint` | Tool interacts with external entities |

These hints enable:
- Permission systems (warn before destructive actions)
- Caching (safe to cache idempotent results)
- Security policies (restrict open-world tools in sensitive contexts)

## Security Challenges

The whitepaper dedicates significant attention to security risks:

### 1. Dynamic Capability Injection

Malicious content manipulates tool definitions at runtime.

**Mitigation**: Validate all tool definitions from untrusted sources.

### 2. Tool Shadowing

Attacker-controlled server defines tool with same name as legitimate tool, intercepting calls.

**Mitigation**: Implement tool namespace isolation, verify server authenticity.

### 3. Malicious Tool Definitions

Tools with harmful implementations disguised by innocuous descriptions.

**Mitigation**: Sandboxing, code review, capability restrictions.

### 4. Sensitive Information Leakage

Context containing secrets passed to untrusted tools.

**Mitigation**: Context filtering, credential isolation, output sanitization.

### 5. Confused Deputy Problem

Agent with legitimate permissions manipulated into misusing them.

```mermaid
flowchart LR
    U["Attacker Input"] --> A["Agent
(Deputy)"]
    A --> T["Tool with
Elevated Perms"]
    T --> D["Unauthorized
Action"]

    classDef redClass fill:#E74C3C,stroke:#333,stroke-width:2px,color:#fff
    classDef blueClass fill:#4A90E2,stroke:#333,stroke-width:2px,color:#fff

    class U,D redClass
    class A,T blueClass
```

**Mitigation**: Intent verification, action confirmation for sensitive operations.

## Enterprise Readiness Gaps

While MCP adoption is growing, the whitepaper identifies areas needing maturation:

| Gap | Current State | Needed |
|-----|---------------|--------|
| **Authentication** | Basic API keys | OAuth 2.0, SAML federation |
| **Identity Management** | Per-server credentials | Centralized identity provider |
| **Observability** | Limited logging | Distributed tracing, metrics |
| **Multi-Tenancy** | Single-tenant focus | Tenant isolation, quotas |
| **Rate Limiting** | Application-level | Protocol-level throttling |

## Connecting the Dots

This whitepaper extends concepts from our [Agentic AI series](https://vanducng.dev/series/agentic-ai/):

| Concept | Previous Coverage | MCP Extension |
|---------|------------------|---------------|
| **Tools as Agent Hands** | [Anatomy of an AI Agent](https://vanducng.dev/2025/10/30/Anatomy-of-an-AI-Agent-Building-Blocks-and-Workflows/) | Standardized tool definitions |
| **Multi-Agent Systems** | [Multi-Agent Patterns](https://vanducng.dev/2025/11/20/Multi-Agent-Patterns-and-Coordination/) | AgentTool primitive |
| **Agent Loop** | [From Chatbots to Agents](https://vanducng.dev/2025/10/15/From-Chatbots-to-Agents-Understanding-Intelligent-AI-Systems/) | Tool invocation in loop |
| **Context Management** | [Google Agents Summary](https://vanducng.dev/2026/01/10/Google-Introduction-to-Agents-Whitepaper-Summary/) | Resources primitive |

## Key Takeaways

1. **Tools are essential**: Without tools, LLMs remain limited to their training data
2. **Standardization solves N×M**: MCP reduces integration complexity from N×M to N+M
3. **Six primitives cover most patterns**: Tools, Resources, Prompts, Sampling, Elicitation, Roots
4. **Security is not optional**: Tool-enabled agents introduce new attack surfaces
5. **Enterprise gaps remain**: Auth, observability, multi-tenancy need protocol-level solutions
6. **Tool quality matters**: Well-designed tools lead to better agent behavior

The shift toward standardized tool interfaces marks a maturation of the agentic AI ecosystem. As MCP adoption grows, expect the enterprise gaps to close and security patterns to solidify.

## References

- [MCP Specification](https://spec.modelcontextprotocol.io/)
- [MCP GitHub Organization](https://github.com/modelcontextprotocol)
- [Anthropic MCP Announcement](https://www.anthropic.com/news/model-context-protocol)
- [Google ADK Documentation](https://google.github.io/adk-docs/)