Summary: Google's Agent Tools & MCP Interoperability

Following our coverage of Google’s Introduction to Agents, 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) 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 where tools serve as the “hands” of an agent system.

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

    subgraph With["With Tools"]
        L2["LLM"] --> T["Tool Call"]
        T --> E["External System"]
        E --> O["Real-time Result"]
        O --> L2
    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.

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.

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.

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:

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

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:

flowchart TB
    subgraph Primitives["MCP Primitives"]
        direction LR
        T["Tools
99% adoption"]
        R["Resources
34%"]
        P["Prompts
32%"]
        S["Sampling
10%"]
        E["Elicitation
4%"]
        Ro["Roots
5%"]
    end

    classDef high fill:#27AE60,stroke:#333,stroke-width:2px,color:#fff
    classDef medium fill:#F39C12,stroke:#333,stroke-width:2px,color:#fff
    classDef low fill:#9B59B6,stroke:#333,stroke-width:2px,color:#fff

    class T high
    class R,P medium
    class S,E,Ro low

Tools (Model-Controlled)

Functions the LLM can invoke. This is the most adopted primitive.

{
  "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"
  }
}

Resources (Application-Controlled)

Data sources the application can access. Unlike tools, resources are explicitly requested by the host rather than invoked by the model.

Examples: file contents, database schemas, API documentation

Prompts (User-Controlled)

Pre-written prompt templates with optional arguments. Users explicitly select these as shortcuts.

Sampling (Server-to-Model)

Allows servers to request LLM completions through the host. Enables agentic patterns where servers need reasoning capabilities.

Elicitation (Server-to-User)

Servers request information directly from users. Useful for interactive workflows requiring user confirmation.

Roots (Filesystem Boundaries)

Define filesystem access boundaries for servers operating on local files.

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.

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:

Concept	Previous Coverage	MCP Extension
Tools as Agent Hands	Anatomy of an AI Agent	Standardized tool definitions
Multi-Agent Systems	Multi-Agent Patterns	AgentTool primitive
Agent Loop	From Chatbots to Agents	Tool invocation in loop
Context Management	Google Agents 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
• MCP GitHub Organization
• Anthropic MCP Announcement
• Google ADK Documentation