Transcript & Summary: How to build an AI Agent and MCP Server (step-by-step)

[00:04] In this video, we are going to connect an AI agent to an MCP server. You will learn what an MCP server is, why it matters, and how to connect it to your ADK agent. By the end, your agent won't just write and plan, it will also pull from an external tool over MCP. So what exactly is MCP. MCP stands for Model context protocol. That sounds complicated, but here's the simple idea. It's a standard way for agents to talk to external tools. Think of it like a translator. On one side, you have your agent, which [00:40] is powered by a language model. And on the other side, you might have tools that do very specific things, looking up Google Trends or querying a database or running code. The agent itself can't do these things directly, so MCP sits in the middle. So here's how it works. The tool runs as its own little program, usually in its own process. The agent connects to it over a standard input and output, and then the agent asks, what tools do you have. The MCP server replies with a list of tool names, their arguments, and what they return. [01:14] Then the agent says, OK, call this tool. With these arguments, the tool runs and the result comes back as JSON. The important part is how cleanly this is separated. Each tool runs in its own process, like its own program. The agent doesn't need to know how the tool is built, what libraries it uses, or even what language it's written in. As long as the tool speaks MCP, the agent can use it. So why is this so powerful. First off, isolation. If a tool crashes, your agent doesn't go down with it. Secondly, it's interoperable. [01:50] You could write tools in Python go or node and the agent doesn't care. Third, it's discoverable tools describe themselves in schemas so agents can figure out at runtime how to use them. And finally, it's scalable. You can add more tools, swap them out, or version them without rewriting your entire agent code. So if you think of the agent as the brain, MCP is the wire that connects it to its hands and eyes in the real world, the brain decides what to do. MCP carries the request across and the hands do the work. [02:25] The results come back to the brain. That's the loop that makes agents more than just chatbots. In the last video, we built an agent that writes blog posts. You gave it a topic and it planned out the entire sections, wrote a draft, and even suggested alternative titles. If you haven't seen that yet, check out the first video or grab the link from the repository LinkedIn the description box below. Now that agent is great, but right now it only relies on the model. It doesn't know what's happening in the real world, what [02:56] is trending and what is in the news. So in this video, we are going to connect it to an MCP server that pulls live data from Google Trends. That way, our blog writing agent can ground its posts in what's actually trending right now. Let's open the project directory and create a file. We are going to look at one Python file that does one job. It exposes a single tool called trends over MCP. So our agent can call it in order to see what is trending on Google Trends. Think of this file as a tiny web service, but instead of HTTP, [03:31] it talks over a standard input and output using the model context protocol. Let's Zoom in on four pieces of code that make this MCP server work with our ADK agent. First, we wrap our plain Python function trends as an SDK tool. This line is doing a lot for us. We wrote a normal Python function that takes JSON friendly arguments and returns a JSON friendly dictionary function tool inspects that function's signature and docstring, and it builds a schema and gives the tool a name. From this point on, ADK knows what arguments a tool expects [04:09] and what it returns, so there's no manual schema writing which is needed. Next, we create the MCP server object. Think of this as a tiny program that sits between the agent and our tool. It speaks the model context protocol over a standard input and output. The name is just an identifier. The client will see during the handshake. Now the two handlers that matter which is listing tools and calling a tool. So listing tools is how the agent discovers what this server can do. And when the agent connects to it, [04:43] it asks, what tools do you have. We answer with a list containing 1 item, which is the trends tool. Convert it into an MCP tool schema and then the helper ADK to MCP tool type function takes the ADK function tool metadata and turns it into exactly what the MCP client expects. That means the agent can see the tools names, its parameters, their types, and a description everything it needs to construct a valid call at runtime. The agent sends a tool name and a JSON dictionary of arguments. We sanity check the name and then forward [05:23] those arguments straight into our Python function by calling async on the function tool. Whatever the function returns, we JSON dump it and then send it back as a text content payload. If anything goes wrong, we return a small JSON error and log the details to standard error. The important idea here is that the protocol is really simple. Name plus arguments in and JSON results out. Finally, we attach the server to standard input and output and run the handshake. This function opens the standard input output [06:00] transport and hence the read and write streams to the MCP server. Initialization options contain metadata and the capabilities that the client will see in the main block. We call async I/O run, which starts the server process from there. ADK can launch the script, ask for the tools, and call trends like any other tool. Finally, in the main agent py file, we just add trends MCP to the root agents list of tools right next to the planner and the writer. From the agent's perspective, there's no difference. [06:38] Calling trends looks exactly like calling a local function tool. But now, instead of making something up, the agent can fetch real trending queries before it starts writing a blog post. Now let's open up ADK web UI with this command and interact with our agent that is now connected to the MCP server. And that's how you connect with your AI agent to an MCP server. We started with the blog writing agent from the last video, then added a new server that exposes a trend tool by wiring that into our root agent. [07:14] We gave it the ability to pull in live Google Trends data before it even started writing. This pattern is powerful because it keeps your agent lightweight while letting it reach out to the real world through external tools. Thank you for watching, and you can check out the description box below for all the resources and code mentioned in this video. Check out the next video to learn how to build multi-agent systems with SDK.