Stockholm Archipelago Trail

show_section_map

Read-only

Show an interactive map of one trail section (stage) of the Stockholm Archipelago Trail, with the hiking route and ferry piers. Use this when the user wants to SEE a section on a map. Takes the same identifiers as fetch (sat:section:…, slug or uid). Pass targetKm (and optionally date) to draw a shorter or longer walk instead of the full stage. Do not use for comparing several stages side by side (use search/fetch). This tool renders an interactive map card itself — NEVER build your own map, chart, image or file from geojsonUrl or the coordinates; just call the tool and let the card show. IMPORTANT: every call to this tool renders a card in the conversation. Call it at most ONCE per answer, for the single option you recommend. Never use it to compare or probe alternatives. The card already shows ferry times, piers and walking times — do not restate them in your reply; add only advice, caveats and next steps.

Input Schema

Name	Required	Description
`date`	No	Travel date, YYYYMMDD (Europe/Stockholm), e.g. 20260905. Only used with targetKm — the walk starts at the pier that day's ferry lands at. 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 ("sat:section:2fxg6"), 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
`bbox`	Yes	[west, south, east, north]
`pois`	No	Points of interest on the stage (category-coloured markers).
`slug`	Yes
`walk`	No	Present when targetKm was passed: the actual walk that was built.
`piers`	Yes
`route`	No	Present with targetKm: the built walk as a GeoJSON LineString ([lon, lat]). The widget draws this instead of geojsonUrl.
`satId`	Yes
`title`	Yes
`permalink`	Yes
`distanceKm`	No
`geojsonUrl`	Yes
`variantNote`	No	Present when a requested targetKm walk could not be built: the full stage is shown instead. Tell the user this.
`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.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 7, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Beyond the readOnly/openWorld annotations, it discloses key behavior: the tool renders a card in the conversation, the card already contains ferry times and walking times, and the agent must not construct its own map from geojsonUrl. These are genuinely useful side-effect disclosures. It does not describe pagination or error behavior, but those are largely irrelevant for a render-a-card tool.

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 and well organized, but there is some redundancy: 'Do not use for comparing several stages' is restated as 'Never use it to compare or probe alternatives', and the map-card directive is repeated. Trimming one of these would tighten it without losing meaning.

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?

Given an output schema exists, the description needn't document return values, and it covers the critical operational rules (single call, don't rebuild the map, don't restate card contents). Nothing an agent needs to invoke it correctly is 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% with rich per-parameter descriptions (date, lang, targetKm, direction, towards), so the schema carries the semantic load. The description adds only that section identifiers mirror fetch and that targetKm/date adjust walk length, which is largely already in the schema.

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 ('Show an interactive map of one trail section (stage)') and names the exact content rendered (hiking route, ferry piers). It also explicitly distinguishes itself from siblings by ruling out side-by-side stage comparison in favor of search/fetch.

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 explicit when-to-use ('when the user wants to SEE a section on a map'), when-not-to-use ('Do not use for comparing several stages side by side'), and names the alternatives (search/fetch). It further constrains invocation to at most once per answer for the single recommended option.

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?