Weather Agent: Two Tools, One Prompt, and a Max Temperature That Is Not Today's

weather-agent is a repository of mine under github.com/yethikrishna. It is built on Mastra, uses Open-Meteo for weather and a Groq-hosted model for the writing. I read src/mastra/tools/index.ts and src/mastra/workflows/index.ts. This post covers those two files.

What the tool does

The weather tool geocodes a location name, then requests current conditions with six fields and maps the numeric weather code to a text label through a table of 28 codes. It is a small, clean tool. One request finds the place, the next one reads the weather.

What the workflow does

The workflow has two steps. fetchWeather gets the data, and planActivities streams an agent that writes a day plan from a fixed prompt with an emoji-structured layout. The agent reads its model from the MODEL environment variable and falls back to llama-3.3-70b-versatile.

Where it goes wrong

In fetchWeather the maximum and minimum temperature are taken from the hourly temperature array, over everything the API returned. That array covers several days, so the high and low are not today's. The rain chance has the same shape: it is the largest hourly probability in the whole array. The workflow's weather-code table is also shorter than the one in the tool, so a code the tool can name may come out as unknown in the workflow.

There are two smaller things. The date is new Date().toISOString(), which is UTC, so near midnight in India the plan can name the wrong day. And the request URL has a stray comma after timezone=auto. I did not test what Open-Meteo does with it, so I will not claim it breaks.

What I would change

My opinion: ask the API for daily max and min and filter hourly values to the target date, instead of reducing the whole array. Share one weather-code table between the tool and the workflow. The prompt is fine for a demo, and the data feeding it is the part I would fix first.