Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Sunshine Atlas MCP server Where is it sunny and warm in October?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A remote, read-only Model Context Protocol server that answers "where is it sunny?" with data: monthly 0–100 Sunshine Scores, day/night temperatures, rainfall and sea temperature for 3,833 destinations — every one with its own airport — from long-term climate normals. It serves the same open dataset published at sunshineatlas.com/data (CC BY 4.0, DOI 10.5281/zenodo.21322408).
Live endpoint (no key, no signup):
https://sunshineatlas.com/api/mcpListed in the official MCP registry as
com.sunshineatlas/sunshine-atlas. Docs page: sunshineatlas.com/mcp.
Tool | Answers |
| "Where is it sunny (and warm) in November?" — ranked by that month's Sunshine Score, filterable by continent/country, minimum day temperature, swimmable sea (≥21 °C), population |
| "When is the best time to visit Faro?" — full 12-month climate card for one destination (city, "city, country" or IATA code) |
| "Algarve or Crete in October?" — side-by-side comparison of 2–5 destinations with a one-line verdict |
Every result carries attribution and citable sunshineatlas.com destination URLs.
Related MCP server: Weather MCP Server
Claude Code
claude mcp add --transport http sunshine-atlas https://sunshineatlas.com/api/mcpClaude (custom connector), ChatGPT connectors, or any Streamable-HTTP client — add the URL
https://sunshineatlas.com/api/mcp.
Generic JSON config (Cursor, etc.)
{
"mcpServers": {
"sunshine-atlas": {
"url": "https://sunshineatlas.com/api/mcp"
}
}
}The server is a single stateless Node file (fresh McpServer per request, plain JSON responses,
binds to 127.0.0.1 — put it behind your reverse proxy). It reads one dataset file and hot-reloads
it on mtime change.
npm install
curl -O https://sunshineatlas.com/data/sunshine-atlas-destinations.json
PORT=8787 DATA_FILE=./sunshine-atlas-destinations.json node server.mjsGET /healthz reports status and destination count. server.json is the MCP-registry manifest.
Sunshine Score = 100 × warmth × (0.5 + 0.5 × (0.55 × dryness + 0.45 × sunniness)), computed
from long-term climate normals — methodology.
Sources: temperature, rainfall and sunshine from NASA POWER climatology (2001–2020); places & populations from GeoNames & OurAirports; sea temperatures via Open-Meteo Marine.
Dataset: sunshineatlas.com/data · CSV/JSON · CC BY 4.0 · mirrors on GitHub, Hugging Face, Kaggle.
Code MIT. Data CC BY 4.0 (credit "Sunshine Atlas" + link). Not a forecast — climate normals describe typical conditions, not this week's weather.
Side-by-side sunshine/climate comparison of 2–5 destinations — overall or for one month ("Algarve or Crete in October?"). Returns each place's Sunshine Score, temperatures, rain and sea temperature, plus a one-line verdict of which is sunnier.
| Name | Required | Description | Default |
|---|---|---|---|
| month | No | Optional month to compare in; omit for year-round comparison | |
| destinations | Yes | 2–5 destinations (city, "city, country", or IATA code) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavior. It describes output but doesn't disclose data sources, limitations, or side effects; reasonable for a read-only comparison tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff, front-loaded with purpose and key details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Describes all key outputs (scores, temperatures, rain, verdict) and usage constraints (2-5 destinations), though lacks error handling or data freshness; adequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds value by specifying destination format (city, 'city, country', IATA) and month usage example, enhancing parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'side-by-side sunshine/climate comparison of 2–5 destinations' with examples, distinguishing it from siblings like find_sunny_destinations and get_destination_climate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides specific context for when to use (overall or monthly comparison) with an example, but does not explicitly contrast with alternatives or state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ranked answer to "where is it sunny (and warm) in ?" — destinations sorted by that month's 0–100 Sunshine Score (long-term climate normals). Filter by continent or country, minimum daytime temperature, population, or swimmable sea (≥21°C). Every result has a citable sunshineatlas.com URL.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many results (default 10, max 50) | |
| month | Yes | Month name ("November", "nov") or number 1–12 | |
| where | No | Optional continent ("Europe", "Asia", "North America", …) or country (name or ISO-2 code) to search within. "Europe" uses the traveler definition and includes the Canary Islands. | |
| min_day_high_c | No | Only places at least this warm by day that month, °C | |
| min_population | No | Only places with at least this population (default 0 = include small islands and outposts) | |
| require_swimmable_sea | No | Only coastal places with sea ≥21°C that month |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations; description covers data source (climate normals), scoring (0-100), and citable URL. No destructive behavior mentioned, transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, main purpose front-loaded, no fluff. Efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema but mentions citable URL and sorts. Could specify return format more, but sufficient for a search tool with good parameter descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
100% schema coverage, baseline 3. Description adds value: month format, 'where' explains traveler definition for Europe, min_population default 0 includes small islands, etc.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it finds sunny destinations for a given month, sorted by Sunshine Score, with filters. Distinct from siblings (compare, get climate).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage: when user asks for sunny destinations in a month. No explicit when-not or alternatives, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full climate card for one destination: 0–100 Sunshine Score, day/night °C, rainfall and sea temperature for all 12 months, plus its sunniest month ("best time to visit" for sunshine) and annual sunshine hours. Accepts a city name ("Faro"), "city, country" ("Nice, France") or IATA airport code ("FAO").
| Name | Required | Description | Default |
|---|---|---|---|
| destination | Yes | City name, "city, country", or 3-letter IATA airport code |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It accurately describes the output (climate card with specific metrics) and input flexibility. As a read-only tool, no destructive behavior disclosed, which is fine.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with key data points, no wasted words. Efficiently communicates scope and input variations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter, no output schema, no annotations, the description is adequately complete. It details what the tool returns and acceptable inputs. Minor gaps like error handling are acceptable for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear description for 'destination' parameter. Description adds examples (Faro, Nice, France, FAO) but no additional meaning beyond schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies it provides a full climate card including Sunshine Score, temperatures, rainfall, sea temperature, sunniest month, and annual sunshine hours for one destination. It clearly distinguishes from siblings (compare_destinations, find_sunny_destinations) by focusing on a single destination's detailed data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description states when to use (need climate data for one destination) and acceptable formats (city name, city+country, IATA code). No explicit when-not or alternatives, but sibling tools provide context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0compare_destinationsfind_sunny_destinationsget_destination_climateScored across 3 tools
Each tool serves a clearly distinct purpose: comparison of multiple destinations, ranked search by month, and detailed single-destination climate data. There is no overlap or ambiguity.
All tool names follow a consistent verb_noun pattern: compare_destinations, find_sunny_destinations, get_destination_climate. The verbs are descriptive and the nouns indicate the object of the action.
Three tools is slightly on the low side but appropriate for a focused climate comparison server. The tools cover the core use cases without unnecessary bloat.
The tool set covers comparison, search, and detailed climate data. A minor gap might be a tool to list all available destinations or get metadata, but for the stated purpose it is reasonably complete.
Where is it sunny? Monthly sunshine scores, temps, rain, UV and sea temp for 3,833 destinations.
Weather data, forecast API, climate data, historical weather, alerts, agricultural & travel weather.
Historical climate data, temperatures, precipitation, and normals
Historical weather and climate: 100+ years of station data, normals, extremes, and trends.
