Skip to main content
Glama

Current Observations

current_observations
Read-onlyIdempotent

Latest real-time surface weather observations from Environment Canada stations near a point (swob-realtime). Returns station name, observation time, air temp, dewpoint, humidity, wind, pressure, snow depth. Example: latitude 43.65, longitude -79.38 for Toronto. Keyless, official ECCC data.

Input Schema

NameRequiredDescriptionDefault
limitNoMax observations to return (default 5, max 20).
latitudeYesLatitude in decimal degrees, e.g. 43.65 (Toronto).
longitudeYesLongitude in decimal degrees, e.g. -79.38 (Toronto).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / examples
      Added value: +[
      +  {
      +    "latitude": 43.65,
      +    "longitude": -79.38
      +  },
      +  {
      +    "latitude": 49.28,
      +    "limit": 10,
      +    "longitude": -123.11
      +  }
      +]
  2. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true. Description adds context: data is 'keyless, official ECCC data' and 'real-time', which are useful beyond annotations. No contradictions.

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

Conciseness5/5

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

Two sentences plus a list of fields. Front-loaded with main purpose and key details. No wasted words.

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?

Tool is simple with 3 parameters and no output schema. Description covers what is returned, data source, and real-time nature. Sufficient for a read-only data retrieval tool.

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

Parameters3/5

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

Schema has 100% coverage with descriptions for all parameters. Description adds example values (latitude 43.65, longitude -79.38) but does not provide deeper meaning beyond the schema. Baseline 3 is appropriate.

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?

Description clearly states 'Latest real-time surface weather observations from Environment Canada stations near a point', specifying verb (returns), resource (surface weather observations), and data source. It lists returned fields, distinguishing it from siblings like active_alerts or climate_daily.

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

Usage Guidelines3/5

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

Usage is implied through examples (latitude/longitude for Toronto) and 'near a point', but no explicit when-to-use or when-not-to-use guidance is given. No alternatives are mentioned.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.