Skip to main content
Glama
Sign In

EclipseMission

by com.eclipsemission
OverviewDiscussionsAdmin

Every figure for one destination

get_destination
Read-onlyIdempotent

Everything EclipseMission holds on one place, each figure with its source and reading day: the eclipse (duration, and contact times where our oracle has them), lodging (eclipse week, week after, the two eclipse nights, solo traveller and hostels where measured, with the ten prices behind each mean), sky, heat, entry regime by passport, the cost of the observation itself, access and the airfares read to its airport.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "destination": "<destination>"
    },
    "name": "get_destination"
  }
}

Input Schema

NameRequiredDescriptionDefault
passportNoISO code of the traveller's passport: returns that passport's entry regime in full. Without it, one short line per passport we cover.
destinationYesThe destination key, as list_destinations returns it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/closed-world/no-destructive, so safety is covered. The description adds genuinely new behavior-relevant context: every figure carries its source and reading day, lodging means are backed by ten prices, and contact times only exist 'where our oracle has them' — that conditional availability is real disclosure you would not otherwise know.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence, front-loaded with the scope, but it is a long comma-chained clause with stacked parentheticals (lodging subcategories, 'ten prices behind each mean', oracle caveat). Dense but hard to scan; some of the enumeration could be trimmed without losing routing value.

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?

With no output schema, the description does the work of explaining what comes back — per-figure sourcing, reading day, and the breadth of categories covered. Combined with read-only annotations, an agent has enough to call it correctly; only explicit usage routing and a return-shape hint (e.g. structure/flatness) are missing.

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 coverage is 100% and both params are enum-constrained with descriptions, so the description is not required to carry semantics. It corroborates the passport dimension ('entry regime by passport') and the destination scope but adds no format or default detail beyond the schema — baseline 3.

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?

States a specific resource ('everything EclipseMission holds on one place') and enumerates the categories returned, which separates it from list_destinations (enumeration) and compare_destinations (multi-place comparison). It lacks a crisp leading verb like 'Retrieve', but the resource and scope are unambiguous.

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?

Implied usage only: it is the detail-fetch for a single destination key, and the schema notes the key comes from list_destinations. No explicit 'use this when...' or exclusion against compare_destinations/plan_trip, so an agent must infer the routing.

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