Stockholm Archipelago Trail

check_day_trip

Read-only

Same data as day_trip but renders NO card. Use this when you need to check or compare day trips across dates, departure hubs or stages before recommending one, or for follow-up questions where no new card is wanted. Same arguments and response as day_trip (section, date, hub, targetKm, direction, towards). Do not use for the final recommendation shown to the user (use day_trip) — call day_trip once for the trip you recommend.

Input Schema

Name	Required	Description
`hub`	No	Optional preferred departure hub slug from check_day_trip/day_trip responses, e.g. 'stromkajen'. Omit to let the planner pick the best.
`date`	No	Travel date, YYYYMMDD (Europe/Stockholm), e.g. 20260905. Defaults to today.
`lang`	No	Language of the user's message: 'sv' when the user writes in Swedish, otherwise 'en'. Always pass it — labels, dates and the card are rendered in this language.
`section`	Yes	Section reference: satId, slug or uid, e.g. 'uto'.
`towards`	No	Optional named place on the island (beach, viewpoint, café) to steer the walk towards, as shown by search/fetch — e.g. 'Stora Sandvik'.
`targetKm`	No	Desired walking distance in km, 1–60, e.g. 9. Pass when the user asks for a shorter or longer walk than the full stage (e.g. "about 9 km"). Omit for the full stage.
`direction`	No	Optional compass direction to steer a shorter walk towards: one of N, NE, E, SE, S, SW, W, NW — e.g. 'NE' to walk towards the north-east part of the island.

Output Schema

Name	Required	Description
`hub`	No	Departure ferry hub.
`date`	No	YYYYMMDD.
`kind`	Yes	"day-trip" \| "no-day-trip".
`walk`	No	Present when targetKm was passed: the actual walk that was built.
`title`	No
`reason`	No	Why no trip/walk could be built.
`return`	No	Ferry island → hub.
`section`	No
`outbound`	No	Ferry hub → island. Times "HH:MM" (Europe/Stockholm).
`permalink`	No
`islandWalk`	No
`boatsPerDay`	No
`feasibility`	No	"comfortable" \| "tight".
`variantNote`	No	Present when a requested targetKm walk could not be built: the full stage is shown instead. Tell the user this.
`nextDateWithTrip`	No	Only with kind "no-day-trip": the next date (YYYYMMDD) within the timetable that does have a day trip, when one was found.
`suggestedFollowUps`	No	Up to three short next steps, in English (e.g. "Make the walk shorter"). Offer these to the user as quick follow-up options at the end of your reply.
`timeOnIslandMinutes`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 7, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered; the description adds the non-annotation-relevant trait that this variant suppresses card rendering while returning identical data. It does not discuss caching, cost, or latency differences versus day_trip, which would be the remaining useful detail.

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 no-card differentiator and the when-not-to-use warning are both front-loaded within three sentences, with zero filler. The parenthetical argument list is mildly redundant against the schema and could be dropped.

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 an output schema present and full parameter coverage, the description needs only to explain the card/no-card distinction and routing, which it does. The one soft spot is the incomplete argument enumeration, which could mislead an agent into thinking lang is unsupported here.

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 the schema already documents all seven parameters and the description earns baseline credit only. The enumeration "(section, date, hub, targetKm, direction, towards)" restates argument names without adding meaning, and it omits the lang parameter that the shared signature actually carries.

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?

"Same data as day_trip but renders NO card" states the resource (day trip data) and the specific differentiator (no card render) in the first clause, and names the sibling it mirrors. An agent can distinguish it from day_trip and multi_day without opening either schema.

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?

Explicit when-to-use (checking/comparing across dates, hubs or stages; follow-up questions with no new card) and explicit when-not-to-use ("Do not use for the final recommendation shown to the user (use day_trip)"), plus the corrective procedure ("call day_trip once for the trip you recommend"). Nothing is left to inference.

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

All Stockholm Archipelago Trail tools Inspect

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

Need Help?