MCP Weather & Transit Advisor

get_current_weather

Fetch real-time weather for a named city or town to check current conditions before planning travel or outdoor activities.

Instructions

Get real-time weather for a city or town by name.

Args: place: A city or town name, e.g. "Tokyo".

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "place": "<place>"
    },
    "name": "get_current_weather"
  }
}

Input Schema

Name	Required	Description	Default
`place`	Yes

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 10, 2026

TDQS

A3.5/5.0

Behavior3/5

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

With no annotations supplied, the description carries the burden, and it does disclose one meaningful trait: the data is "real-time" rather than cached or historical. Beyond that it says nothing about units, ambiguous place-name handling, or failure behavior, leaving the tool's operational profile thin for an unannotated definition.

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 purpose sentence is front-loaded and free of waste, and the single parameter note is kept short. The inline "Args:" block is slightly heavier than necessary for one field but is not padded.

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

Completeness3/5

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

For a one-parameter read tool with an output schema (so return values need not be explained), the definition covers the essentials of what it does and what the parameter means. It omits unit/locale semantics and disambiguation behavior, which an agent would still need to guess at.

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 description coverage is 0% – the schema exposes only a bare "place" string titled "Place" – so the description's Args block does real work by specifying it accepts a city or town name and giving a concrete example ("Tokyo"). It loses a point only because it does not address ambiguity (e.g., multiple Tokyos) or accepted formats.

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

Purpose4/5

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

"Get real-time weather for a city or town by name" states a specific verb (get), resource (weather), and scope (real-time, by place name), which is enough for an agent to distinguish it from siblings like get_commute_advice or get_stop_departures. It stops short of naming any sibling as an alternative, so it lands at 4 rather than 5.

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 only implied by the phrase "for a city or town by name" – an agent can infer this is the tool for current conditions in a named locality, but there is no explicit when-to-use/when-not-to-use statement and no routing to geocode_location for ambiguous or coordinate-based input.

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

Deploy Server