Skip to main content
Glama
Sign In

EclipseMission

by com.eclipsemission
OverviewDiscussionsAdmin

Where one traveller can go, from their airport and passport

plan_trip
Read-onlyIdempotent

The destinations that fit one traveller, in the order of the site's ranking, each with its lodging figure, totality and sky, the entry regime of their passport, and the fares we have read from their airport to it. The fares and the stay are given side by side, never summed: they are different searches, read on different days. A place with no fare read from that airport is kept, with a note: that is a gap in our readings, not a claim that no flight exists.

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": "plan_trip"
  }
}

Input Schema

NameRequiredDescriptionDefault
originNoIATA code of the departure airport, e.g. MAD.
countryNoKeep one country, by English name or ISO code, whatever the case: Egypt, Gibraltar, Morocco, Saudi Arabia, Spain, Tunisia.
passportNoISO code of the traveller's passport: each place then carries that passport's entry regime.
min_totality_secondsNoKeep places with at least this much totality, in seconds.
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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, so the bar is lower. The description still adds valuable non-obvious traits: fares and stays are never summed because they come from different searches read on different days, and places with no fare are retained with a note rather than dropped.

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?

It is front-loaded with the result composition, followed by two short, useful behavioral notes. Some phrasing is ornate ('totality and sky', 'we have read'), but the roughly three-sentence length is appropriate and no sentence is pure filler.

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 and only safety-oriented annotations, the description does solid work covering the returned fields, ranking order, non-summing of fare and stay, and handling of missing fares. It does not address pagination, defaults, or what happens when optional filters like origin are omitted, leaving some gaps for a six-parameter aggregation tool.

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 parameter meaning is already well documented, including the IATA pattern, passport enum, and four-night price semantics. The description reinforces the passport and airport roles but adds no syntax, defaults, or filtering nuances beyond the schema, so the baseline 3 applies.

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 resource and result set: destinations that fit a traveller, each with lodging, totality/sky, passport entry regime, and fares from their airport. That aggregation scope implicitly separates it from get_flights, get_destination, and list_destinations, though no sibling is named explicitly.

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 only implied by describing what the tool returns; there is no explicit when-to-use, when-not-to-use, or named alternative such as compare_destinations. An agent can infer that this is the combined trip-planning view, but must reason about it.

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