Sunshine Atlas
Server Details
Where is it sunny? Monthly sunshine scores, temps, rain and sea temp for 3,833 destinations.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.3/5 across 3 of 3 tools scored.
Each tool has a clear, distinct purpose: comparing destinations, finding sunny spots, or retrieving detailed climate data. No overlap.
All tool names follow a consistent verb_noun pattern with underscores: compare_destinations, find_sunny_destinations, get_destination_climate.
With 3 tools, the set is small but well-scoped for a focused domain. Each tool serves a core query type without redundancy.
The tools cover the main use cases: comparing multiple destinations, querying by criteria, and getting full climate data. No obvious gaps for the intended purpose.
Available Tools
3 toolscompare_destinationsCompare destinationsAInspect
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) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: returns Sunshine Score, temperatures, rain, sea temp, verdict. It also notes constraints (2-5 destinations) but doesn't discuss permissions or side effects, which is acceptable 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, front-loaded with purpose, no fluff. Efficient and well structured.
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?
Despite no output schema, the description fully explains return values. With only 2 params and no annotations, it covers all necessary context for agent invocation.
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%, so description adds little beyond schema. It repeats month optionality and destination formats, but schema already describes them similarly. No significant new meaning.
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 clearly states the tool performs 'Side-by-side sunshine/climate comparison of 2–5 destinations', contrasting with siblings that likely find sunny destinations or get single destination climate. It uses specific verbs and resources.
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?
The description implies usage for comparing multiple destinations, with examples like 'Algarve or Crete in October?'. However, it does not explicitly say when not to use or mention alternatives, though sibling names provide context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_sunny_destinationsFind sunny destinationsAInspect
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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It mentions long-term climate normals and citable URLs, but does not discuss data freshness, limitations, or edge cases. Adequate but not thorough.
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, no filler, front-loaded with purpose and then details. Every word earns its place.
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?
Covers purpose, ranking, filters, and output feature (citable URL). Without an output schema, a bit more detail on returned fields (e.g., sunshine score, temperature) would be helpful, but overall complete.
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 has 100% coverage, yet description adds valuable context like the 0–100 Sunshine Score, traveler definition of Europe, and specific threshold for swimmable sea (≥21°C). Greatly enhances 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 it finds sunny destinations ranked by Sunshine Score for a given month, with filters. This is distinct from sibling tools compare_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?
Explicitly frames the tool as answering 'where is it sunny in <month>?' and lists available filters, providing clear usage context. However, it does not explicitly state when not to use it or compare with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_destination_climateDestination climate & best time to visitAInspect
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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries full burden. It discloses the output contents (Sunshine Score, temperatures, etc.) and input formats, but does not mention rate limits, authentication, or error handling.
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?
The description is a single, well-structured paragraph that front-loads the purpose and then provides details and input formats without wasting words.
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?
The description fully explains the return values (monthly data, Sunshine Score, etc.) and accepted inputs, making it complete for a tool with no output schema.
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 description coverage is 100% and the param description already covers the input formats. The tool description adds no new information about the parameter beyond what the schema provides.
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 clearly states it provides a full climate card for one destination with specific metrics (Sunshine Score, temperatures, etc.), distinguishing it from sibling tools like compare_destinations and find_sunny_destinations.
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?
The description explains what the tool does and the accepted input formats, but does not explicitly state when to use this tool versus the siblings or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!