Source URL: https://cloud.google.com/blog/topics/developers-practitioners/tools-make-an-agent-from-zero-to-assistant-with-adk/
Source: Cloud Blog
Title: Tools Make an Agent: From Zero to Assistant with ADK
Feedly Summary: Imagine that you’re a project manager at QuantumRoast, a global coffee machine company.
You help your teammates navigate a sea of engineering roadmaps, sudden strategy pivots (we’re doing matcha now!), and incoming tickets from customers— everything from buggy invoice systems to a coffee machine that’s making a high-pitched noise 24/7.
On a regular day, you have about fifty open browser tabs: the internal ticket system, email, chat, GitHub, Google Search, StackOverflow, and more. You like your job and your teammates— but some days, you get overwhelmed.
What if there was a helper we could build to help you create and triage software tickets, and debug issues? An AI agent makes this possible.
Tools 101
What makes AI agents unique from other software systems? In the post “AI Agents in a Nutshell," we discussed how AI agents use models, not just hardcoded logic, to reason their way through a problem. But more than just LLM-based reasoning, AI agents are uniquely powered to gather external data and then take action on behalf of the user. Rather than telling you how to solve a problem, an AI agent can help you actually solve it. How do we do this? With tools!
A tool is a capability that helps an AI agent interact with the world. A tool can be almost anything: an inline function, a hosted database, a third-party API, or even another agent. AI Agent frameworks like Agent Development Kit (ADK) have built-in support for tools, supporting a variety of tool types that we’ll cover in just a moment.
But how does an agent know not only when to call a certain tool, but also how to call it? The agent’s model plays a few key roles here.
The first is tool selection. We provide our agent with a list of tools and some instructions for how to use them. When a user prompts the agent, the agent’s model helps decide which tools to call, and why, in order to help the user.
The second key step is function-calling. Function calling is a bit of a misnomer because the model is not actually calling the tool, but rather, preparing to call it by formatting the request body that the framework then uses to call the tool.
Lastly, the model helps interpret the response from that tool — say, a list of open bugs from the database— and decides whether to take further action, or respond to the user with that information.
To see all this in action, let’s build the QuantumRoast bug assistant agent using ADK Python.
Function Tool
The simplest ADK tool is the function tool. This is an inline function that can perform a calculation or algorithm. For instance, we can write a function tool to get today’s date:
code_block
This way, if the user asks about bugs filed “in the last week,” the model understands what specific dates it should be adding to the request body when it calls our IT Ticket database. Here’s what that looks like in action:
Built-in Tool
Another type of ADK tool is a built-in tool. These are tools that work with Google’s flagship model features, like code execution inside the model itself. For instance, can attach the Google Search built-in tool to our bug assistant agent, to allow the agent to do basic web-searches in order to gather more information about a bug:
code_block
<ListValue: [StructValue([(‘code’, ‘from google.adk.tools import google_search\r\nfrom google.adk.tools.agent_tool import AgentTool\r\n\r\nsearch_agent = Agent(\r\n model="gemini-2.5-flash",\r\n name="search_agent",\r\n instruction="""\r\n You\’re a specialist in Google Search.\r\n """,\r\n tools=[google_search],\r\n)\r\nsearch_tool = AgentTool(search_agent)’), (‘language’, ‘lang-py’), (‘caption’, <wagtail.rich_text.RichText object at 0x3eb94a2d34f0>)])]>
Here, we’re actually wrapping that Google Search tool in its own agent with its own system instructions, effectively using an agent as a tool.
Third-party API Tool
To plug our bug agent into StackOverflow’s powerful Q&A data, we can pull from LangChain’s extensive tools library— specifically, the StackExchange API Wrapper tool. ADK supports third-party tools via LangChain, so adding this tool to our ADK agent requires just two lines of code.
code_block
<ListValue: [StructValue([(‘code’, ‘from google.adk.tools.langchain_tool import LangchainTool\r\nfrom langchain_community.tools import StackExchangeTool\r\nfrom langchain_community.utilities import StackExchangeAPIWrapper\r\n\r\nstack_exchange_tool = StackExchangeTool(api_wrapper=StackExchangeAPIWrapper())\r\nlangchain_tool = LangchainTool(stack_exchange_tool)’), (‘language’, ‘lang-py’), (‘caption’, <wagtail.rich_text.RichText object at 0x3eb94a2d3550>)])]>
Pulling in third-party API tools is great for re-using existing tools. But imagine that you’ve got a bunch of your own internal APIs and third-party APIs you want to integrate your agent with— GitHub, for example. In a standard software application, you’d have to write your own code to call GitHub’s APIs. But GitHub’s API is big! If every agent developer working with GitHub had to implement their own GitHub tools, that’s a lot of duplicated effort.
This is where a protocol called MCP comes in…
MCP Tool (API)
MCP stands for Model Context Protocol. It’s an open tool protocol introduced by Anthropic in 2024. MCP provides an abstraction layer between your AI agent and tool “backends” (APIs, databases).
MCP has some unique specifications. Unlike standard HTTP, MCP provides a stateful, two-way connection between the client and server. It has its own way of defining tools and tool-specific error messages. A tool provider can then build MCP Servers on top of their APIs, exposing one or more pre-built tools for developers and users. Then, agent frameworks can initialize MCP Clients inside an agent application, to discover and call those tools.
This is exactly what GitHub did in 2025. They created a remote MCP server to allow different types of AI applications— from AI coding assistants, to custom agents— to easily call GitHub’s APIs. The GitHub MCP server exposes different parts of GitHub’s functionality, from issue and pull requests, to notifications and code security. Here, we use ADK’s MCPToolset to call the GitHub remote MCP server:
For our bug assistant, we will expose just some read-only GitHub tools, to allow QuantumRoast employees to find issues related to open-source dependencies, to see if that can help root-cause bugs they’re seeing in the internal ticket system. We’ll use ADK’s MCPToolset with a tool_filter to set this up. The tool-filter exposes only the GitHub tools we need, which not only hides the tools we don’t want users accessing (think: sensitive repo actions), but also protects the agent’s model from getting overwhelmed when trying to choose the right tool for the job.
code_block
<ListValue: [StructValue([(‘code’, ‘from google.adk.tools.mcp_tool import MCPToolset, StreamableHTTPConnectionParams\r\n\r\nmcp_tools = MCPToolset(\r\n connection_params=StreamableHTTPConnectionParams(\r\n url="https://api.githubcopilot.com/mcp/",\r\n headers={\r\n "Authorization": "Bearer " + os.getenv("GITHUB_PERSONAL_ACCESS_TOKEN"),\r\n },\r\n ),\r\n # Read only tools\r\n tool_filter=[\r\n "search_repositories",\r\n "search_issues",\r\n "list_issues",\r\n "get_issue",\r\n "list_pull_requests",\r\n "get_pull_request",\r\n ],\r\n)’), (‘language’, ‘lang-py’), (‘caption’, <wagtail.rich_text.RichText object at 0x3eb94a2d3ac0>)])]>
Note how we also need to provide a GitHub Personal Access Token (PAT) to our MCPToolset definition, just like how you’d provide an auth token when setting up a standard API client in your code. This PAT is scoped to only access public repository data, with no scopes around sensitive user or repository actions.
Now, we have a set of GitHub MCP tools that our agent can call. For instance, let’s say that one of QuantumRoast’s services relies on XZ utils, a data compression tool. Our internal bug ticket system is tracking a CVE (security vulnerability) from last year, which we can trace back to the XZ Utils GitHub repo using the StackOverflow and Google Search tools. We can then use one of GitHub’s MCP tools, search_issues, to determine when and how that CVE was patched:
MCP Tool (Database)
The last tool to cover is QuantumRoast’s internal bug ticket database. This is a PostgreSQL database running on Google Cloud SQL. We have a table with bugs, each with a ticket_id, title, description, assignee, and other fields.
We could write our own Python code using an ORM like sqlalchemy to call our SQL database (eg. get ticket by ID). Then we could wrap that code in a Function Tool, just like we did for get_current_date(). But this could add toil — more lines of code, plus we’d have to write the database connection logic and handle auth on our own.
Instead, we are going to use MCP, much like we used it for the GitHub API. We will use a prebuilt MCP server again — but this time, the tool “backend” will be our own database. We’ll pull in the MCP Toolbox for Databases, a Google-built, open-source MCP server that provides connectors and production-grade features like auth, for a variety of data sources, from BigQuery to Redis.
To wire up the MCP toolbox to Cloud SQL, we’ll create a tools.yaml configuration file that tells the Toolbox MCP server where our database lives, and the tools we want to create for it. For example, we could transform our bug description column into searchable vector embeddings, to enable a fuzzy search-tickets tool within our agent:
code_block
<ListValue: [StructValue([(‘code’, "sources:\r\n postgresql: \r\n kind: cloud-sql-postgres\r\n project: my-gcp-project\r\n region: us-central1\r\n instance: software-assistant\r\n database: tickets-db\r\n user: postgres\r\n password: ${POSTGRES_PASSWORD}\r\ntools:\r\n search-tickets:\r\n kind: postgres-sql\r\n source: postgresql\r\n description: Search for similar tickets based on their descriptions.\r\n parameters:\r\n – name: query\r\n type: string\r\n description: The query to perform vector search with.\r\n statement: |\r\n SELECT ticket_id, title, description, assignee, priority, status, (embedding <=> embedding(‘text-embedding-005’, $1)::vector) as distance\r\n FROM tickets\r\n ORDER BY distance ASC\r\n LIMIT 3;\r\n…"), (‘language’, ”), (‘caption’, <wagtail.rich_text.RichText object at 0x3eb94a2d3610>)])]>
We can define several other tools, like create-new-ticket and update-ticket-status, in that tools.yaml file. From there, we can run the Toolbox MCP server locally:
code_block
<ListValue: [StructValue([(‘code’, ‘➜ mcp-toolbox git:(software-bug-github) ✗ ./toolbox –tools-file="tools.yaml"\r\n\r\n2025-06-17T11:07:23.963075-04:00 INFO "Initialized 1 sources."\r\n2025-06-17T11:07:23.963214-04:00 INFO "Initialized 0 authServices."\r\n2025-06-17T11:07:23.963281-04:00 INFO "Initialized 9 tools."\r\n2025-06-17T11:07:23.963341-04:00 INFO "Initialized 2 toolsets."\r\n2025-06-17T11:07:23.963704-04:00 INFO "Server ready to serve!"’), (‘language’, ”), (‘caption’, <wagtail.rich_text.RichText object at 0x3eb94a2d3f10>)])]>
Then finally, we can plug our bug assistant agent into that MCP Toolbox server:
code_block
<ListValue: [StructValue([(‘code’, ‘from toolbox_core import ToolboxSyncClient\r\n\r\nTOOLBOX_URL = os.getenv("MCP_TOOLBOX_URL", "http://127.0.0.1:5000")\r\ntoolbox = ToolboxSyncClient(TOOLBOX_URL)\r\ntoolbox_tools = toolbox.load_toolset("tickets_toolset")’), (‘language’, ‘lang-py’), (‘caption’, <wagtail.rich_text.RichText object at 0x3eb94a2d3a00>)])]>
From there, our agent has access to all those SQL database tools to create and triage bugs in the QuantumRoast ticket database:
Putting it all together
We just toured five different ADK tool types, from simple FunctionTools, to third-party LangChain tools, to powerful MCP tools.
Now, we can build a QuantumRoast bug assistant agent to help that busy project manager navigate their day-to-day work.
To do this, we’ll create a single LLMAgent using ADK Python, powered by Gemini 2.5 Flash (reasoning model):
code_block
<ListValue: [StructValue([(‘code’, ‘root_agent = Agent(\r\n model="gemini-2.5-flash",\r\n name="software_bug_assistant",\r\n instruction=agent_instruction,\r\n tools=[get_current_date, search_tool, langchain_tool, *toolbox_tools, mcp_tools],\r\n)’), (‘language’, ‘lang-py’), (‘caption’, <wagtail.rich_text.RichText object at 0x3eb94a2d3eb0>)])]>
We equip our root_agent with instructions. We outline the desired process that we want the agent to go through:
code_block
<ListValue: [StructValue([(‘code’, ‘agent_instruction = """\r\nYou are a skilled expert in triaging and debugging software issues for a coffee machine company, QuantumRoast.\r\n…\r\nYour general process is as follows:\r\n1. **Understand the user\’s request.** Analyze the user\’s initial request to understand the goal – for example, "I am seeing X issue. Can you help me find similar open issues?" If you do not understand the request, ask for more information. \r\n2. **Identify the appropriate tools.** You will be provided with tools for a SQL-based bug ticket database (create, update, search tickets by description). You will also be able to web search via Google Search. Identify one **or more** appropriate tools to accomplish the user\’s request. \r\n…’), (‘language’, ‘lang-py’), (‘caption’, <wagtail.rich_text.RichText object at 0x3eb94a2d3d60>)])]>
Inside our system instructions, we also provide details and context on all our tools. This helps the model understand when to invoke which tool.
code_block
<ListValue: [StructValue([(‘code’, ‘**TOOLS:**\r\n\r\n1. **get_current_date:**\r\n This tool allows you to figure out the current date (today). If a user\r\n asks something along the lines of "What tickets were opened in the last\r\n week?" you can use today\’s date to figure out the past week.\r\n\r\n2. **search-tickets**\r\n This tool allows you to search for similar or duplicate tickets by\r\n performing a vector search based on ticket descriptions. A cosine distance\r\n less than or equal to 0.3 can signal a similar or duplicate ticket.\r\n…’), (‘language’, ”), (‘caption’, <wagtail.rich_text.RichText object at 0x3eb94a2d3790>)])]>
Now that our agent code is ready to go, we can deploy this whole setup to Google Cloud, running the agent and MCP toolbox server on Cloud Run, the bug ticket database in Cloud SQL, with Gemini 2.5 Flash on Vertex AI. Check out the deployment instructions here.
Get started with agent tools
To sum up, tools “make an agent.” They’re the difference between an AI that can tell you what to do, and one that can help you actually do it.
If you’re new to AI agents and tools, start small. Write a basic ADK agent using an inline function. Then, consider pulling in an OpenAPI Tool for your API, or a Third-party LangChain tool like YouTube. Then, wade into the world of MCP by first using an off-the-shelf MCP server like the MCP Toolbox for Databases. Then, consider building your own MCP server for your own tool backend.
To get started today, check out these links, and thanks for reading!
ADK Documentation – Tools
GitHub – Software Bug Assistant (Python) – also available in the Agent Garden
Codelab – Build a Travel Agent using MCP Toolbox for Databases and Agent Development Kit
Blog – Build and Deploy a Remote MCP Server to Google Cloud Run in Under 10 Minutes
Video – MCP Toolbox for Databases in Action
AI Summary and Description: Yes
Summary: The text discusses the development of an AI agent to assist project managers at QuantumRoast, particularly focusing on debugging software issues and managing bug tickets. It explains how AI agents utilize tools to enhance interaction with external data sources, showcasing various tool types and integration methods in the context of software development.
Detailed Description:
The document outlines the construction and functionality of an AI agent to assist project managers in navigating software issues and bug ticket management at QuantumRoast, a coffee machine company. Key points include:
– **AI Agent Basics**:
– AI agents differ from traditional software systems by leveraging models to reason and take actionable steps.
– Rather than just providing instructions, AI agents can perform tasks on behalf of the user.
– **Types of Tools for AI Agents**:
– **Function Tool**:
– Inline capabilities like calculations (e.g., fetching the current date) for context-aware responses.
– **Built-in Tool**:
– Utilizes built-in functionalities from models, enabling direct interaction with the agent’s reasoning capabilities.
– **Third-party API Tool**:
– Tools that leverage existing Q&A databases or features of third-party services (e.g., StackOverflow) to enhance agent responses.
– **MCP Tool (API)**:
– Introduces a new protocol (Model Context Protocol) that enables a two-way connection to enhance interactions with APIs and tools, minimizing duplicated effort among developers.
– **MCP Tool (Database)**:
– Facilitates the integration with databases using a pre-built server to manage internal ticket systems efficiently.
– **Building the Agent**:
– The document illustrates creating a “QuantumRoast bug assistant agent” using the Agent Development Kit (ADK), which supports various tools.
– Deployment options include using Google Cloud services for seamless integration and scaling.
– **Practical Implementation**:
– The text includes code snippets that provide practical guidance on tool integration, such as using the MCP Toolbox for Databases and Google Cloud SQL for managing internal bug tickets.
– **Conclusion**:
– The closing remarks emphasize the transformative potential of tools in AI agents, encouraging developers to start with basic functionality and gradually explore more complex integrations.
This text is particularly relevant for professionals in software development, AI development, and organizations looking to implement AI-driven solutions for operational workflow improvements. It highlights the practicality of tools in AI applications, the ease of integration using established standards like MCP, and the overall business benefits of leveraging AI agents in software management practices.