Weather-Prediction MCP Server + Agent Bricks Agent

Architecture

User question ("Should I bring an umbrella to Austin this weekend?")
        │
        ▼
Databricks Agent Bricks agent (system prompt below)
        │  calls tools over MCP (streamable-HTTP)
        ▼
weather_mcp_server.py  (FastMCP, deployed as its own Databricks App)
        │  thin @mcp.tool functions, no raw HTTP calls
        ▼
weather_broker.py  (adapter — all HTTP + parsing lives here)
        │
        ▼
Open-Meteo API (geocoding + forecast, no API key required)

Two Databricks Apps in total: the MCP server (mcp_server/) is the only one required for a passing grade; a dashboard (stretch goal) was not built for this submission.

Related MCP server: weather-mcp

Weather API + auth method

Open-Meteo (api.open-meteo.com + geocoding-api.open-meteo.com) — chosen per the assignment's recommendation to start with zero credentials, so the whole pipeline could be built and tested before dealing with secrets at all. No API key, no signup, no Databricks secret scope needed. If a stretch goal adds NWS alerts or a key-based provider later, weather_broker.py is the only file that would need a _secret()-style helper added (WorkspaceClient().secrets.get_secret(...), same pattern as Day 1/2's Lakebase/Massive secrets) — the MCP tool functions wouldn't change.

Tools exposed

All three live in mcp_server/weather_mcp_server.py; all HTTP calls and response parsing are pushed into mcp_server/weather_broker.py — no raw requests calls inside any @mcp.tool function. Location strings are geocoded automatically (city name, "City, State", etc. — no coordinates needed). Every tool returns {"error": "<message>"} on failure (bad location, API outage) instead of raising, so the agent gets a clean signal instead of a stack trace.

Setup steps

1. Deploy the MCP server as a Databricks App:

   • Push this repo (or just the mcp_server/ folder) to your GitHub repo

   • In Databricks: Repos → clone/pull this repo into your workspace

   • Apps → Create App → point it at mcp_server/ (uses app.yaml + requirements.txt in that folder)

   • Deploy, confirm it's running, note the App URL

2. Register the MCP server as an external MCP tool (Agent Bricks):

   • In your Databricks workspace, open Agent Bricks

   • Under external tools/MCP servers, add a new external MCP pointing at your deployed weather MCP server's URL (streamable-HTTP endpoint)

   • Confirm the three tools (get_current_weather, get_forecast, predict_umbrella_needed) show up in the tool list

3. Build the Agent Bricks agent:

   • Create a new agent, attach the weather MCP server as an external tool

   • Paste in the system prompt below

   • Test with the sample questions in the next section

Agent system prompt

You are a weather assistant. You have access to three tools on the weather
MCP server:

1. get_current_weather(location) — current conditions
2. get_forecast(location, days) — multi-day forecast
3. predict_umbrella_needed(location, date) — a recommendation on whether to
   bring an umbrella, derived from precipitation chance

Rules:
- Always call a tool to get weather data. Never guess, estimate, or make up
  temperatures, forecasts, or conditions from your own knowledge — weather
  changes constantly and your training data is not current.
- For "will it rain" / "should I bring an umbrella" / "should I pack a
  jacket" type questions, prefer predict_umbrella_needed over reasoning
  about raw forecast numbers yourself — it already applies a clear
  threshold and will explain its reasoning.
- If a question mentions a relative date ("tomorrow", "this weekend"),
  convert it to a specific YYYY-MM-DD date before calling
  predict_umbrella_needed or get_forecast.
- If a tool call returns {"error": ...}, don't retry blindly and don't
  invent an answer — tell the user plainly what went wrong (e.g. "I
  couldn't find that location" or "the weather service is unavailable
  right now") and ask them to clarify or try again.
- If a location is ambiguous (e.g. a city name that exists in multiple
  states/countries), ask the user to clarify rather than guessing which one
  they meant.
- Keep answers concise and conversational — lead with the direct answer,
  then the supporting numbers.

Demonstration

(paste 3+ screenshots or transcripts of the agent answering different natural-language weather questions here for submission — e.g.:)

1. "What's the weather like in Chicago right now?"

2. "Give me a 5-day forecast for Austin, TX."

3. "Should I bring an umbrella to Seattle this weekend?"

Known limitations / what I'd improve

• No severe-weather alerts tool yet (NWS /alerts/active would be a natural second data source to layer in, US-only).

• No dashboard app showing recent agent queries (stretch goal, not built for this submission).

• predict_umbrella_needed only reasons about precipitation chance — a richer version could factor in wind speed (umbrellas are useless in high wind) or temperature (snow vs. rain gear).