windy-webcams-mcp-server

search_webcams

Read-only

Find webcams by location, category, country, region, city, or nearby coordinates. Get webcam feeds, images, and player URLs.

Instructions

Search for webcams with various filters (location, category, etc.)

Input Schema

TableJSON Schema

Name	Required	Description
`bbox`	No	Bounding box coordinates (format: "north_lat,east_lon,south_lat,west_lon")
`lang`	No	Language code (default: "en")
`limit`	No	Number of results to return (1-50, default: 10)
`cities`	No	City geo code or comma-separated list of city geo codes.
`nearby`	No	Coordinates and radius for nearby search (format: "latitude,longitude,radiusKm", radius max 250)
`offset`	No	Result offset for pagination (default: 0)
`include`	No	Comma-separated list of extra data to include (default: "images,location"). One or more of: categories, images, location, player, urls.
`regions`	No	Region geo code or comma-separated list of region geo codes, max 10. Codes come from get_regions.
`sortKey`	No	Field to sort results by
`countries`	No	Country geo code or comma-separated list of country geo codes (e.g., "US,DE,FR"), max 10. Codes come from get_countries.
`webcamIds`	No	Webcam ID or comma-separated list of webcam IDs to fetch directly (max 50). If set, all other filters are ignored — use this for batch webcam lookups.
`categories`	No	Category ID or comma-separated list of category IDs, max 10. One of: airport, beach, building, city, coast, forest, indoor, lake, landscape, meteo, mountain, observatory, port, river, sportArea, square, traffic, village.
`continents`	No	Continent geo code or comma-separated list of continent geo codes (e.g., "NA,EU,AS"), max 2. Codes come from get_continents.
`sortDirection`	No	Sort direction (used with sortKey)
`categoryOperation`	No	Operator used to combine multiple "categories" (requires categories to be set, default: "and")

Output Schema

TableJSON Schema

Name	Required	Description	Default
`data`	No
`cached`	No
`success`	Yes
`summary`	Yes
`api_info`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Sep 20, 2026

TDQS

C2.6/5.0

Behavior2/5

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

The annotations already provide readOnlyHint and openWorldHint, and the description adds no behavioral context beyond a generic 'Search' phrase. It does not mention how filters combine, that webcamIds ignores other filters, or any other runtime behavior, leaving the description to carry little weight.

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 a single efficient sentence with no filler or redundancy. It is concise but under-specified; the 'etc.' is vague, yet for a schema-heavy tool this brevity is not penalized heavily.

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

Completeness2/5

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

For a complex 15-parameter, all-optional search tool with an output schema, this one-line description is insufficient. It lacks high-level usage context, routing to specialized siblings, behavior when filters interact, and references to supporting tools like get_regions, get_countries, and get_categories.

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%, so the schema already documents all 15 parameters and their details. The description names 'location, category' but adds no meaning beyond the schema, so the baseline score of 3 is appropriate.

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

Purpose3/5

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

The description names a specific verb ('Search') and resource ('webcams') and mentions filters. However, it is vague about what makes this search distinct from siblings like get_webcams_by_location, get_webcams_by_category, and get_nearby_webcams, and does not clarify that it is a flexible multi-filter search.

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

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus sibling tools, no mention of specialized alternatives, and no indication that webcamIds bypasses all other filters. The agent must infer usage entirely from the parameter schema and sibling names.

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

Deploy Server