Winter is coming [music] and for you

there in the Alps that means Avalanche

safety is top of mind, right Kristoff?

And you told me there is an MCP server

for that.

>> Yes, people rely on LLM responses more

and more when it comes to planning out

their adventures. The data and

information need to be accurate. Let me

show you how I set up this MCP server.

Welcome to the show, Kristoff. What do

you do here at Google?

>> Thanks for having me, Martin. I'm

currently doing a rotation as a software

engineer in the Cloudr run team, working

on the user experience, but I also work

with the largest customers on Google

Cloud to bring their serverless

applications up and running. Okay, now

show me this Avalanche MCP server.

>> Someone might build the next generation

ski body AI app which can answer your

questions about skiing and also inform

you about the current avalent risk. Such

agent can connect to MCP servers to

fetch this up-to-date data. For the

purpose of this demo, I've connected my

Gemini CLI to the URL of the Avalanche

Warning MCP server, which runs on Google

Cloud Run. But think of any app or

agent. I'm going to ask here, what is

the current avalanche danger level at

Mountain Solstein?

Tell me what the snow pack is like.

>> Okay, it's thinking. Look at that. It

asked me for permission to use those

tools.

Found the region ID for the mountain

solinine. Put the current data for this

region and got us a grounded answer

based on the official records. No

hallucinations.

>> All right. Now, why do we need an MCP

server for avalanche data?

>> It is actually a perfect use case. So

the model context protocol or MCP is

basically a standardized way to plug in

real time data into a large language

model. An LLM would not intrinsically

know about most up-to-date data.

>> Okay. So it's like an open API spec but

optimized for AI.

>> Exactly. Standard APIs are messy for AI.

You have to write good prompts and code

to parse the model output to explicitly

execute some API requests. MCP on the

other hand is self-describing.

>> How is it self-describing?

>> The MCP server tells the LLM,

hey, I have a tool to check snow

conditions and explains

how to use it in plain English. Here is

a list of tools of the MCP Avalanche

server. Each written with a description

and a JSON schema defining tools input.

>> Got it. Uh but usually I see people

running uh these MCP servers locally on

their laptops. Uh why put this in the

cloud?

>> Uh great question. Um locally is fine

for personal offline tools like reading

from your own file system.

But an avalanche warning service wants

to provide this endpoint directly so

users don't need to install the MCP

somewhere but just can connect to a

public URL

>> and why use cloud run for your MCP

server in the cloud

>> for avalanch warning service MCP server

projects cloud run is a perfect match.

Think about it. The traffic is spiky as

a lot of people checked the Avalanche

report

on a day when it snows and they got

prepared for the next day's outdoor

adventure. But almost nobody is quing

this endpoint at 3:00 a.m. in the

summer.

>> And you don't want to pay for a server

that's sitting idle all night. Right.

>> Exactly. Cloudr run scales to zero. So

if no one is asking about the

avalanches, almost nothing is getting

charged. But if a blizzard hits or

champagne powder falls, traffic will

spike suddenly. Cloudr run will scale up

automatically.

>> I love that champagne powder. Uh okay,

so that sounds efficient with the

scaling. Now, how does the AI actually

get the right avalanche data?

>> Sure. Here is the Avalanche MCP server

code by the Austrian Avalanche warning

service. We expose two tools. One

which is called get region ID. You give

it a mountain name and it gives you back

this particular ID.

And a second tool you get the bulletine

where you can give it this particular ID

plus a specific date and optionally a

language and it gives you back the

danger rating and other related data in

a structured way because they are

clearly described in MCP. The large

language model figures out the logic on

its own and it's chaining those two

tools together.

>> Okay, I I think I understand how that

works. How would you deploy this MCP

server to Cloud Run?

>> That is simple. We don't need to touch

any server or clusters. I just run run a

single command to deploy this code as a

cloud run service. That command takes my

code

builds a container out of it and

provides me back with an URL and handles

all the scaling rules we talked about.

>> Very good. Uh, let's take a tea or

coffee break while it's running.

>> I will pack my backpack to get ready for

later the good snow.

And now it's back. Here is the URL of my

newly deployed MCP server. I can give

this URL to Gemini CLI or any AI agent.

Someone out there built and want to rely

on the Avalanche data.

>> Very good. Now, let's recap. What are

the main takeaways here, Kristoff?

>> I have two. MCP is useful for connecting

AI apps and agents to real time data

like fetching avalanche warning data.

Second, Cloudr run is a great place to

run your MCP servers because it handles

all the MCP requests in a serverless way

and autoscales up and down

automatically.

>> Great takeaways and thank you for

joining me today Kristoff.

>> Thanks Martin for having me

>> and thank you everyone for watching. If

you have any questions for Kristoff or

me, ask in the comments and do let me

know what you thought of today's

episode.

I read every single comment. I can't

wait to see what you build.

[music]

[music]