weather-mcp-agent

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.

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 Tool Purpose get_current_weather(location) Current temp, conditions, humidity, wind get_forecast(location, days=3) Multi-day forecast: high/low, precip chance, conditions predict_umbrella_needed(location, date) Derived recommendation (not a passthrough) — thresholds precipitation chance into "yes / maybe / no" with a one-sentence explanation

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 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 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 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. Deployment status MCP server: deployed as a Databricks App and running — https://weather-mcp-server-7474644487245197.aws.databricksapps.com/mcp Local verification: the server module was installed and imported in a clean environment (not just syntax-checked), and mcp.list_tools() confirmed all three required tools register correctly: get_current_weather, get_forecast, predict_umbrella_needed. Agent Bricks registration: attempted via AI Gateway → Create MCP Service, pointing at the deployed server's /mcp URL with a Bearer token (personal access token). The connection itself was created successfully (workspace.default.weather-mcp_connection), but the subsequent tool-discovery step failed with an empty/unlabeled error ({}) and no further detail was surfaced in the UI or browser console. I was not able to complete the agent wiring in time for submission — see "Known limitations" below. Demonstration

Not completed for this submission — the Agent Bricks tool-discovery step did not succeed (see "Deployment status" above), so there is no live agent transcript to include. The MCP server itself is deployed and its tools are verified working at the code/protocol level (see verification note above); what's unverified is specifically the Agent Bricks → MCP-service handshake.

Known limitations / what I'd improve The Agent Bricks "Create MCP Service" tool-discovery step did not complete successfully against the deployed server — the connection was created, but tool discovery returned an empty error with no diagnostic detail in the UI. Given more time I'd check the app's own request logs during a discovery attempt (to see whether the request even reached the server) and try the OAuth M2M auth path instead of a Bearer/PAT token, since Databricks Apps are OAuth-protected by default. 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).