Skip to main content
Glama
Sign In

EclipseMission

by com.eclipsemission
OverviewDiscussionsAdmin

Where to see the 2027 eclipse, cheapest first

list_destinations
Read-onlyIdempotent

Every place EclipseMission has measured for the total solar eclipse of 2 August 2027, in the order of the site's ranking: the places every reader can go to, ranked by lodging price per person, cheapest first, then Mecca, priced but unranked (entry restricted to Muslims). For each: totality duration (our validated oracle), lodging for two adults over four nights, 31 July to 4 August 2027 (mean of the ten cheapest rooms, dated), the Eclipse Premium (that price over the same search a week later), cloud as a range of two reanalyses, heat, public-transport access, the nearest airport and our one-word verdict. Filters narrow the list; they never reorder it.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_destinations"
  }
}

Input Schema

NameRequiredDescriptionDefault
countryNoKeep one country, by English name or ISO code, whatever the case: Egypt, Gibraltar, Morocco, Saudi Arabia, Spain, Tunisia.
min_totality_secondsNoKeep places with at least this much totality, in seconds (the longest on our list is about 381).
open_to_all_visitorsNotrue leaves out places whose entry is restricted (Mecca, closed to non-Muslims).
max_price_per_person_eurNoKeep places whose four-night stay costs at most this per person, in EUR (the price for two, halved).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior5/5

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

Annotations already cover safety, idempotency, and closed-world behavior, but the description adds substantial context beyond them. It discloses the ranking order, the Mecca exception, the exact returned fields, the price methodology, the Eclipse Premium calculation, and the fact that filters never reorder results.

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 definition is front-loaded with scope and ordering, and every clause carries substantive information. It is dense and built as one very long sentence with many parentheticals, so it could be easier to scan, but it is not padded.

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

Completeness5/5

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

There is no output schema, so the description must explain what comes back, and it does: totality duration, lodging price, Eclipse Premium, cloud range, heat, transport access, nearest airport, and verdict. For a read-only list tool, this is complete enough for an agent to understand the result set and ordering.

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 coverage is 100%, so the parameters are already documented. The description still adds meaningful semantics: filters narrow but do not reorder, open_to_all excludes restricted-entry places such as Mecca, and price is framed as lodging per person over four nights for two adults.

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?

The description states a specific verb and resource: it lists every place EclipseMission has measured for the 2027 eclipse, with ordering rules. It is clear what the tool returns, but it does not explicitly distinguish itself from siblings such as list_eclipse_sites or compare_destinations.

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 implied: this is the list-all tool, and filters narrow the list without reordering it. However, the description gives no explicit when-to-use guidance versus get_destination, compare_destinations, list_eclipse_sites, or plan_trip.

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

All EclipseMission toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources