Skip to main content
Glama
Sign In

Doorfarer

by com.doorfarer
OverviewDiscussionsAdmin

Find group trips

find_group_trips
Read-onlyIdempotent

Finds trips for a group whose people leave from different towns to meet in one place on the same dates: each person's own door-to-door trip (the train, bus or car to their best airport, and the flight), one line per town, with the group's total, the longest journey and the dates that work for everyone. E.g. "Four of us want a week in Lisbon in May: two from New Haven, one each from Ithaca and Burlington." Put each town once in homes with how many people leave from it. For "where should we meet?" pass a region, countries or "anywhere" as destinations with anywhere true. For one home town, use find_trips. A month without a year means the next one coming. With no dates from the group this tool runs no search and returns the question to ask; once they name a time, or say any time suits them (flexible true), it searches. A month is enough to search: don't ask for exact dates. If a search finds nothing, say so and offer a wider window or single-town searches; never quote prices from other sources.

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": {
      "homes": "<homes>",
      "destinations": "<destinations>"
    },
    "name": "find_group_trips"
  }
}

Input Schema

NameRequiredDescriptionDefault
modeNoHow people get to the airport: public, train, bus, car or any. Leave out unless the user says: then any in the US, public elsewhere.
homesYesEach town people leave from, with how many: [{"town": "New Haven, CT", "travellers": 2}, {"town": "Ithaca, NY"}]. Towns, not airports; the same town twice is one line.
one_wayNoTrue if everyone flies one way only.
anywhereNoTrue to find the best places to meet in the countries or regions named.
currencyNoISO code (USD, GBP, EUR). Default: the first town's currency.
flexibleNoTrue only when the group said any time suits them: the next 3 months are searched. Otherwise pass the dates they named.
priorityNoBest for the group: budget (the lowest total), time (the fewest hours) or balanced. Default balanced.
same_dayNoTrue if everyone must leave and return on the very same days; by default within a day.
depart_toNoThe window to leave in: last day.
nights_maxNoTrip length in nights: longest. Default 14.
nights_minNoTrip length in nights: shortest. Default 2.
depart_fromNoThe window to leave in: first day. Leave out with depart_to for the next 3 months.
destinationsYesWhere to meet: airport codes (LIS), cities, country codes (PT), a region, a continent (Europe) or "anywhere".
max_ground_hoursNoThe most hours from the front door to the departure airport, one way. Default 8.5: farther airports are left out and named in the answer. Set it only when the user says how far they would travel to the airport, or to include the far ones the answer names.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / flexible
      Added value: +{
+  "default": false,
+  "description": "True only when the group said any time suits them: the next 3 months are searched. Otherwise pass the dates they named.",
+  "title": "Flexible",
+  "type": "boolean"
+}
  2. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare read-only, idempotent, open-world, non-destructive, so the safety burden is low; the description nonetheless adds real behavioral context the annotations cannot: it runs no search and returns a clarifying question when dates are absent, it names omitted far airports in the answer, and it must never quote prices from other sources. It even sketches the return content (totals, longest journey, mutually workable dates) despite there being no output schema.

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?

Front-loaded with purpose and a worked example, and nearly every sentence carries an actionable rule rather than filler. It is long and packed into a single run-on block, which makes the later rules (no-results handling, price-quoting prohibition) harder to scan than they should be.

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?

For a 14-parameter tool with no output schema, the description covers purpose, input mapping, default behaviors (next occurrence of a month, month is enough to search), degraded paths (no dates, empty results), and the shape of what comes back. Nothing an agent needs in order to call it correctly or explain results appears to be missing.

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 baseline is 3; the description earns above that by translating user phrasing into parameter choices (region/country/"anywhere" plus anywhere for a meeting-place hunt, flexible only when the group says any time suits) and by instructing that each town appears once in homes with its traveller count. It does not explain departure-window or nights semantics beyond what the schema already documents.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Finds trips for a group whose people leave from different towns to meet in one place on the same dates") and spells out the output shape: one line per town, group total, longest journey, common dates. It explicitly distinguishes itself from the sibling find_trips ("For one home town, use find_trips"), so an agent can route between them without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete when-to-use routing: pass a region/country/"anywhere" plus anywhere=true for "where should we meet?"; use find_trips for a single home town. It also covers edge conditions—month without a year means the next one, no dates means no search and return the question to ask, flexible=true when any time suits, a month is enough so don't ask for exact dates—and prescribes behavior when a search returns nothing.

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

All Doorfarer 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