Skip to main content
Glama

reassign

by app.reassign

Get weather

get_weather
Read-only

Get the weather forecast for a day, for scheduling around it. Use ONLY for outdoor or weather-sensitive plans (exercise, commute, travel, anything outside) or when the user explicitly asks about the weather — indoor plans don't need it. get_schedule and show_day already include a one-line weather headline for the day, so prefer that for a quick glance and reach for this only when an outdoor plan needs the hourly detail (e.g. the exact dry/daylight window). Defaults to today and the user's city; pass date (ISO YYYY-MM-DD) for another day, or location (a city/place name) to ask about somewhere else. Returns a compact day overview (condition, temp range, rain window, daylight) plus a part-of-day breakdown — not an hourly dump.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateNoThe day to forecast, ISO "YYYY-MM-DD". Defaults to today. Open-Meteo covers ~16 days ahead; far-future/far-past days have no hourly data.
locationNoA city/place name to forecast instead of the user's own city, e.g. "London" or "Tahoe". Omit to use their saved (or timezone-guessed) city.

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations provide readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds meaningful behavioral context: the ~16 day forecast horizon, the return shape (compact day overview plus part-of-day breakdown, explicitly NOT an hourly dump), and the default behavior (today, user's city). These add real value beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is reasonably sized for the functionality covered and front-loads the core purpose. It packs substantial guidance (usage, alternatives, defaults, return shape) into a compact form. Slightly dense in the middle section but every sentence earns its place—nothing redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only query tool with two optional parameters, full schema coverage, and clear annotations, this description is complete. It covers what the tool does, when to use it, what it returns, defaults, parameter specifics, and limitations (16-day horizon). No material gaps for an agent to make wrong decisions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds value by explaining defaults (today, user's city), the date pattern with the 16-day forecast limitation, and the location semantics (overrides saved city). It clarifies parameter behavior beyond the raw schema, though much is already documented well in the schema itself.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states this is a weather forecast tool for a specific day, with a strong verb+resource structure ('Get the weather forecast for a day'). It distinguishes itself from siblings by explicitly noting that get_schedule and show_day already include a one-line weather headline, making the specific purpose (hourly/part-of-day detail for outdoor planning) clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit when-to-use ('outdoor or weather-sensitive plans', 'when user explicitly asks about weather') and when-not-to-use guidance ('indoor plans don't need it'). Names specific alternatives (get_schedule, show_day) and explains when to prefer those instead, plus guidance on the date/location parameters.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All reassign toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.5/5.0
Disambiguation5/5

Each tool targets a distinct operation: reading (get_schedule, find_event, get_energy, get_weather, show_day), scheduling (schedule, confirm_schedule), event editing (write_events, delete_events), backlog management (manage_backlog), category management (manage_categories), reflection (review_day), undo, and feedback. The boundary between schedule and write_events is explicitly clear (exact times vs. conflict-free search), and get_schedule vs. show_day are differentiated by text vs. visual presentation. The only minor ambiguity is that manage_backlog includes a 'schedule' op, but that's internal to the tool.

Naming Consistency4/5

All but two tools follow verb_noun snake_case: confirm_schedule, delete_events, find_event, get_energy, get_schedule, get_weather, manage_backlog, manage_categories, review_day, send_feedback, show_day, write_events. The exceptions are 'schedule' and 'undo', which are bare verbs and thus slightly break the consistent pattern.

Tool Count5/5

14 tools is well-scoped for a comprehensive scheduling assistant: read surfaces, write surfaces, assisted scheduling, backlog/category management, reflection, undo, weather/energy, and feedback. Each tool covers a distinct capability, and none feels redundant. Only the extra weather and energy getters could arguably be merged with get_schedule, but they serve specific use cases.

Completeness5/5

The tool surface covers the full lifecycle: create (schedule, write_events), read (get_schedule, find_event), update (write_events, manage_backlog, manage_categories), delete (delete_events, review_day discard), plus undo and confirmation flows. There are no obvious dead ends or missing CRUD operations for the scheduling domain. Weather and energy are bonuses that support informed scheduling decisions.

Resources