Pictures of a resort for vision-capable agents: approved winter photography, and 'topography' circuit renders — satellite/hillshade art of the ACTUAL runs, so an agent can show its user the terrain. Direct image URLs on skimetric.eu (thumb ~640w for cards, mid ~1280w for heroes, url = original). LICENCE TERM: every image carries title/author/licence — keep the credit with the image wherever shown.
| Name | Required | Description | Default |
|---|---|---|---|
| resort | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses direct image URLs on skimetric.eu, thumbnail and hero width variants, and a licensing/credit requirement. These behavioral details go well beyond the readOnlyHint and destructiveHint annotations and materially affect how results should be used.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences with the main purpose front-loaded, followed by URL details and license terms. Every sentence carries distinct information needed to call and use the tool correctly, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only media tool with no output schema, the description provides the return form (direct URLs), sizing guidance, and legal handling. Nothing essential to invoking it or presenting results is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only refers to 'a resort' without specifying the expected identifier format, naming convention, or accepted values. The description does not compensate for the schema's lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool returns pictures for vision-capable agents, specifically approved winter photography and topography circuit renders. It identifies the resource precisely, though it lacks an explicit verb like 'retrieve' and only implicitly distinguishes itself from siblings such as webcams.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when an agent needs to show resort imagery or terrain ('so an agent can show its user the terrain'). It does not mention alternatives or when not to use this tool, leaving routing decisions to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct domain aspect: planning, booking, snow conditions, resort info, and costs. Even closely related tools like booking_options vs open_booking vs choose_path are clearly separated by their roles in the trip lifecycle. No two tools appear to do the same thing.
Names mostly use a noun or verb_noun style in lowercase, but there is a mix of forms (e.g., 'find_resorts' vs 'conditions' vs 'where_to_ski'). The pattern is still predictable and readable, with only minor stylistic deviations.
16 tools is slightly above the ideal sweet spot, but the domain is broad (ski trip planning, conditions, booking, media, costs) and each tool clearly earns its place. It feels well-scoped without being bloated.
Covers the full trip lifecycle: research (plan_trip, trip_status, tell_skym), selection (choose_path), booking (booking_options, open_booking), live conditions (conditions, daily_snow, snow_forecast, webcams, where_to_ski), resort details (find_resorts, resort_media, getting_there), and costs (trip_costs). No obvious dead ends or missing operations.