Tools & Connectors: APIs, Databases, and MCP

Before you start: this is a billed cloud service

• Cost and account. A Google Cloud project with billing enabled and the relevant APIs on. The Integration Connectors used here provision a connection that bills while it exists; tear it down when done.
• Authored against the docs, not executed live. The Python is written against the official ADK/platform docs and syntax-checked, not run during authoring. Toolset class names and parameters evolve — pin your SDK version and adjust if yours differs.
• Hybrid: SDK + console. You wire tools in code and create a connector connection in the console.

About this series

This is Part 4 of the eleven-part Gemini Enterprise Agent Platform series. So far your agent can reason (Lab 2) and answer from documents (Lab 3). This lab gives it hands — the ability to reach real systems: REST APIs, databases and SaaS apps, and external MCP servers.

What you'll build

You'll connect the Acme Orders assistant to live systems through four kinds of tools, from simplest to most powerful:

1. A function tool — plain Python (the baseline you already know).
2. An OpenAPI tool — an entire REST API turned into tools from its spec.
3. A data connector — a governed connection to a database or SaaS app via Integration Connectors.
4. An MCP toolset — tools served by an external Model Context Protocol server.

By the end, the agent can look up an order in code, call Acme's REST API, query the orders database through a governed connector, and use tools from an MCP server — all through one consistent interface.

Why this matters (the 5-minute business case)

Read this before handing the lab to your team.

Tools are where an agent stops talking and starts doing. A grounded agent can tell a customer their return window; a tool-using agent can look up their actual order and start the return. Everything valuable an agent does in production runs through tools — and how you connect them is an architecture decision, not a detail.

Three reasons this is a leadership-level concern:

1. It's M×N versus M+N integration economics. Without a standard, every agent (M) needs a bespoke integration to every system (N) — an M×N explosion of glue code nobody maintains. Standardized tooling — OpenAPI specs, connectors, and MCP — turns that into M+N: build the connection once, any agent can use it. That's the same leverage the MCP lab argued for, now at the platform layer.
2. It makes tool access governable. When tools go through the platform's connectors and toolsets rather than ad-hoc API keys sprinkled through code, you get one place to manage credentials, scope what each agent can reach, and audit what it did. Ungoverned tool access is how a helpful agent becomes a security incident.
3. It meets your systems where they are. Most enterprise value is locked in existing APIs, databases, and SaaS apps. The platform's job is to connect agents to those safely — OpenAPI for your own services, connectors for databases and SaaS, MCP for the growing ecosystem of external tools — without a rewrite.

The honest caveats:

• A tool is a permission. The moment an agent can call an API or query a database, "what is it allowed to do, and on whose behalf?" is a live security question. Keep tools least-privilege and read-only until you've added the identity and safety layers (Labs 8–9). This lab keeps writes out.
• More tools, more surface. Each connected system is another thing that can fail, leak, or be abused. Connect what the agent needs, not everything it might.
• Toolset APIs are young. Class names and parameters here move between SDK versions. Pin versions and expect to adjust.

A framing for a non-technical stakeholder: "Tools are how the agent actually reaches our systems — our APIs, our database, outside services. We connect them through governed, reusable connections so any agent can use them safely, instead of every project wiring its own."

Concepts you'll use (2-minute primer)

• Function tool — a plain Python function the agent can call. Simplest possible tool; great for logic you own.
• `OpenAPIToolset` — point it at an OpenAPI (v3) spec and it generates one callable tool per endpoint automatically. No hand-writing a function per route.
• Integration Connectors / `ApplicationIntegrationToolset` — the platform's governed connections to databases and SaaS apps (Postgres, BigQuery, Salesforce, and many more). You create a connection once in the console, then expose chosen entities/actions to the agent.
• `MCPToolset` — connects the agent to an external MCP server and turns its tools into agent tools. This is how you consume the server you built in the MCP lab.

One sentence: function tools for code you own, OpenAPI for your REST APIs, connectors for databases and SaaS, and MCP for the external tool ecosystem — all surfaced to the agent as ordinary tools.

Prerequisites

Step 1 — Function tool (the baseline)

You've seen this in earlier labs. A plain Python function with a docstring and type hints becomes a tool; ADK reads the signature to build the schema the model sees.

def get_order_status(order_id: str) -> dict:
    """Look up the status of an Acme order by its ID.

    Args:
        order_id: The customer's order identifier, e.g. "AC-10231".
    """
    return {"order_id": order_id, "status": "shipped", "eta": "2026-07-02"}

Reach for function tools for logic you own and want in your own code. The next three steps are about not hand-writing a function for every external capability.

Step 2 — OpenAPI tool (a whole REST API from its spec)

If Acme already has a REST API with an OpenAPI spec, you don't write a tool per endpoint — you hand the spec to OpenAPIToolset and get them all:

from google.adk.tools.openapi_tool import OpenAPIToolset

with open("acme_orders_api.yaml") as f:
    spec = f.read()

api_tools = OpenAPIToolset(spec_str=spec, spec_str_type="yaml")
# For an authenticated API, pass auth_scheme / auth_credential here.

Each operation in the spec becomes a callable tool, named and described from the spec's operationId and summaries — which is exactly why good API descriptions matter: they're now the agent's interface, too.

Step 3 — Data connector (governed access to a database or SaaS app)

For databases and SaaS apps, use Integration Connectors — the platform's managed, governed connections.

In the console: open Integration Connectors, create a connection to your system (for example, a Postgres database holding Acme orders), and authorize it. This is where credentials live and access is governed — once, centrally, not scattered in agent code.

In code: expose chosen entities/actions to the agent with ApplicationIntegrationToolset:

from google.adk.tools.application_integration_tool import ApplicationIntegrationToolset

orders_db = ApplicationIntegrationToolset(
    project="your-project-id",
    location="us-central1",
    connection="acme-orders-postgres",      # the connection you created
    entity_operations={"Orders": ["GET", "LIST"]},  # read-only on purpose
    tool_name_prefix="orders_db",
)

Note that we grant only GET and LIST — read-only. The connector is where you enforce what the agent may touch; keep it minimal until the safety and identity labs are in place.

Step 4 — MCP toolset (tools from an external server)

To consume an external MCP server — like the one you built in the MCP lab — attach an MCPToolset. ADK queries the server, discovers its tools, and converts them into agent tools:

from google.adk.tools.mcp_tool.mcp_toolset import MCPToolset
from mcp import StdioServerParameters

mcp_tools = MCPToolset(
    connection_params=StdioServerParameters(
        command="python",
        args=["acme_mcp_server.py"],  # a local MCP server over stdio
    )
)
# For a remote server, use a streamable-HTTP connection instead of stdio.

This is the M+N payoff made concrete: the MCP server you built once is now usable by this agent — and any other MCP-aware agent — without new glue.

Wire them all onto the agent

ADK accepts functions and toolsets together in the tools list:

from google.adk.agents import Agent

root_agent = Agent(
    name="acme_orders_assistant",
    model="gemini-3.5-flash",
    instruction=(
        "You are the Acme Orders assistant. Use your tools to look up orders, "
        "call the Acme API, query the orders database, and use connected "
        "services. Prefer the most specific tool for the task. If no tool can "
        "answer, say so — don't guess."
    ),
    tools=[get_order_status, api_tools, orders_db, mcp_tools],
)

The model now picks the right tool per request — and because each tool's name and description is its interface, clear descriptions are what make that choice reliable.

A note on governed access

You just gave one agent four routes into real systems. Before any of this goes near production:

• Keep it read-only until the safety (Lab 8) and identity/registry (Lab 9) layers are in place. Every tool added above is read-only on purpose.
• Scope at the connection, not in the prompt. The connector's entity/action grants and the API's auth scope are real enforcement; an instruction telling the agent "don't delete things" is not.
• Prefer connectors and MCP over raw keys in code. Centralized credentials and access are auditable; scattered keys are a breach waiting to happen.

Cost & cleanup

• Delete the Integration Connectors connection you created — it bills while it exists.
• Stop any local MCP server you ran for Step 4.
• If you deployed a tool-using agent to Agent Engine to test, delete it (see Lab 2's cleanup).
• Confirm in Billing → Reports that nothing is still accruing.

If a lab created it and you're done, delete it today.

Verified against

• ADK `OpenAPIToolset`, `MCPToolset`, and `ApplicationIntegrationToolset` docs, and the `google-cloud-aiplatform[agent_engines,adk]` SDK, June 2026.
• Toolset class names and parameters (and the MCP connection-params classes) vary across SDK versions; code is syntax-checked against the docs but not executed during authoring. Pin your version.

What's next

Your agent can now reach real systems. Next:

• Lab 5 — Sessions & Memory Bank: give the agent managed short-term and long-term memory so it carries context across turns and conversations.
• Cross-links: the MCP lab (build the server this lab consumes) and the ADK series (function tools and the MCP toolset in the code-first framework). The governed-access concerns here are paid off in Lab 8 (Model Armor & safety) and Lab 9 (Agent Identity & Registry).