PyScrappy

Overview Schema Source Related Servers Discussions Admin

Get Weather

get_weather

Fetch current weather conditions for a named place, returning temperature, humidity, wind speed, and condition as structured JSON. Resolves city names and provides real-time readings.

Instructions

Fetch the current weather conditions for a named place and return a dict with keys: temperature (number, degrees Celsius), humidity (number, percent), wind_speed (number, wind speed), condition (str, e.g. "Clear", "Rain"), and location (str, the resolved place name).

Makes a live network call to an external weather provider on each invocation, so results reflect real-time conditions and require internet access. If the location cannot be resolved or the provider returns no match, the tool returns an empty result (or an error field) rather than raising.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`location`	Yes	String naming the place to look up; a city name, optionally with a region or country to disambiguate. Example: "Tokyo, Japan". No default; this parameter is required.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`data`	No
`count`	No
`errors`	No
`scraper`	No
`source_urls`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedJul 31, 2026

changedInput schema / properties / location / description

Previous value: -"Place name, e.g. \"London\" or \"Tokyo, Japan\"."New value: +"String naming the place to look up; a city name, optionally with a region or country to disambiguate. Example: \"Tokyo, Japan\". No default; this parameter is required."

Changed16 schema fields changedv1.3.3Jul 31, 2026

addedInput schema / additionalProperties
```
Added value: +false
```

addedInput schema / properties / location / description

Added value: +"Place name, e.g. \"London\" or \"Tokyo, Japan\"."

removedInput schema / properties / location / title
```
Removed value: -"Location"
```
removedInput schema / title
```
Removed value: -"get_weatherArguments"
```

removedOutput schema / $defs

Removed value: -{
-  "ToolError": {
-    "description": "A non-fatal problem encountered while scraping.",
-    "properties": {
-      "message": {
-        "title": "Message",
-        "type": "string"
-      },
-      "url": {
-        "title": "Url",
-        "type": "string"
-      }
-    },
-    "required": [
-      "url",
-      "message"
-    ],
-    "title": "ToolError",
-    "type": "object"
-  }
-}

removedOutput schema / properties / count / title
```
Removed value: -"Count"
```
removedOutput schema / properties / data / title
```
Removed value: -"Data"
```
removedOutput schema / properties / errors / items / $ref
```
Removed value: -"#/$defs/ToolError"
```

addedOutput schema / properties / errors / items / description

Added value: +"A non-fatal problem encountered while scraping."

addedOutput schema / properties / errors / items / properties

Added value: +{
+  "message": {
+    "type": "string"
+  },
+  "url": {
+    "type": "string"
+  }
+}

addedOutput schema / properties / errors / items / required
```
Added value: +[
+  "url",
+  "message"
+]
```
addedOutput schema / properties / errors / items / type
```
Added value: +"object"
```
removedOutput schema / properties / errors / title
```
Removed value: -"Errors"
```
removedOutput schema / properties / scraper / title
```
Removed value: -"Scraper"
```
removedOutput schema / properties / source_urls / title
```
Removed value: -"Source Urls"
```
removedOutput schema / title
```
Removed value: -"ScrapeToolResult"
```

AddedJul 26, 2026

TDQS

A4/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it does well by stating that each call makes a live network request, depends on an external provider, needs internet access, and returns an empty/error result rather than raising. It could also mention latency or rate limits, but the core runtime behavior is transparent.

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?

The description is compact and front-loaded: first sentence states the action and return contract, second sentence covers runtime behavior and error handling. Every sentence earns its place, with no repetition of the title or filler.

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

Completeness4/5

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

For a single-parameter tool with an output schema, the description is nearly complete: it covers invocation, return format, live-network behavior, internet dependency, and failure handling. The only notable gap is explicit guidance on when to prefer this over sibling tools, which is already captured under usage guidelines.

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 description coverage is 100%, and the parameter description already explains the expected string format, optional region/country disambiguation, and that it is required. The tool description adds only general context about 'named place' and the resolved place name in the response, so it does not significantly extend the schema's meaning.

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 uses a specific verb and resource ('Fetch the current weather conditions for a named place') and goes further to enumerate the exact return keys and their types. This clearly distinguishes it from the sibling search and scraper tools, even without an explicit comparison.

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?

The description makes the core use case clear: retrieve current weather for a named location. However, it provides no explicit guidance about when to choose this tool over siblings or when not to use it, leaving tool-selection routing mostly to inference.

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