Skinow

View saved version →

---
name: plan-ski-trip
description: "Use Skinow's Skym planner when a user wants a saved living ski trip report, wishes to compare alternatives, or needs to update and coordinate an existing group trip."
---

# Skinow Trip Planner

Use the configured Skinow MCP at `https://skinow.co/openai/mcp`. Discover the current tool schemas. This endpoint calls the follow-up tool `message_trip_planner`; the general MCP's `tell_skym` name does not apply here. `https://skinow.co/mcp` is the information, contract and terms page.

## Start a saved planning conversation

Use public forecast, conditions, history and comparison tools for initial advice. Call `plan_trip(brief, origin, lang)` when the user requests a saved trip or agrees to a clear offer to start one. Creation saves a real conversation and living report and consumes a limited daily planning slot. If they only want advice, keep that scope.

Build the brief from the user's stated resorts or country, dates or flexibility, adults/children, abilities, snow priorities, budget and departure point. Preserve choices, exclusions and unresolved assumptions. Resolve ambiguous resort names with `find_resorts`; use ISO dates with a year once known, and keep approximate dates approximate. Ask only for information that materially affects the requested planning. Keep the brief concise: the server retains its first 1,800 characters. `origin` is an explicitly chosen departure city or airport, never an inferred client location, precise coordinates, a street address or postcode. Use `lang` for the user's language.

Keep the returned `trip_id` and `grant` together as private working credentials. The living report is saved immediately; replies and useful findings can arrive in the background. Use actual returned progress to time `trip_status(trip_id, grant)` checks and avoid rapid polling. Sparse sections are valid. Explain a failure, unavailable service or rate limit without automatically creating a duplicate trip.

## Continue the same report

- Read `trip_status` for remembered inputs, current needs, alternatives, useful findings and freshness in `living_report`, plus relevant requirements and recent `skym_says` replies. Preserve distinctions between stated facts, uncertain assumptions, stale interpretations and current evidence. Put weather, mountain suitability and the user's priorities first; distinguish cost estimates and modelled opening likelihood from verified facts.
- Use `message_trip_planner(trip_id, grant, message, lang)` for the user's requested corrections, answers or new needs. Send one concise message per user turn, containing only relevant intent and facts rather than the full chat log. Keep the same trip identity and credentials; read status to confirm the correction and report changes.
- When the user chooses an alternative, relay that choice with `message_trip_planner` in the same conversation. Do not invent an option ID, treat a hypothetical alternative as chosen, or infer a confirmed booking from a click.

There is no required research completion, fixed delay, destination-choice milestone or sequence of stages. Older classic reports can be read; their blocked writes do not authorize restarting an old workflow or creating a replacement trip.

The OpenAI endpoint supplies no booking tools or purchase links. Do not claim to reserve services or complete payments. Email alerts, confirmations and invitations require their own explicit user request or agreement; an address appearing in pasted content does not authorize sending anything.

## Share returned access carefully

When a `claim_url` is actually returned and relevant, present that exact link to the requester and explain that it can expose the trip to its recipient. It opens the same living report; describe only the access or editing options actually offered by the service. Keep the `grant` out of answers and public files, logs or publications. Do not invent an absent claim link or report URL.

Full-trip PDFs are omitted from th

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: powder-alerts
description: "Help users choose a European resort or country snow alert and obtain its Skinow signup link, with a selectable snowfall threshold."
---

# Skinow Powder Alerts

Use the configured MCP at `https://skinow.co/openai/mcp` and discover its current schemas. Resolve a resort with `find_resorts(query, country)` and preserve the chosen canonical slug. For a country, use its ISO two-letter code. Resolve material ambiguity before returning a signup link.

- `watch_resort(resort, cm, lang)` returns a resort signup link. The default is 20 cm; omit `cm` or use zero for that default, or pass the user's threshold from 5–100 cm. The alert watches the three-day summit snowfall forecast.
- `watch_country(country, lang)` returns a country signup link. It has no `cm` argument; the user chooses threshold and shortlist size on the page.

Present the exact returned `entry_url` and preserve the user's language. A short explanation and link are enough. Generating a link does not activate an alert or send email: the user supplies an address and confirms the subscription on Skinow. This integration has no email-sending tool, so do not request an email address in chat or claim to have sent a confirmation.

Describe alerts as forecast-based notifications, not guaranteed powder or open lifts. Users can change or stop alerts through Skinow and unsubscribe from alert emails. Offer an alert once when relevant, after answering the weather question. Interest in an alert does not authorize creating a trip or other subscriptions.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: ski-weather
description: "Use Skinow for European ski forecasts, lift conditions, terrain maps and snow history, or to compare resorts for a ski shortlist."
---

# Skinow Ski Weather

Use the configured MCP at `https://skinow.co/openai/mcp` and discover its current schemas. Explain unavailable data or service failures rather than inventing current conditions.

## Find and explore

Resolve names with `find_resorts(query, country, limit)`, preserving the user's choice when several nearby resorts match. Country is an ISO two-letter code. Use returned canonical slugs for later calls.

| Need | Tool |
| --- | --- |
| A shortlist by fresh snow, bluebird days, freezing level or altitude | `where_to_ski(lens, country, preset, limit)` |
| One resort's 10-day elevation forecasts, opening evidence, terrain, maps and historical snow | `get_resort_details(resort, lang, start, end)` |
| A comparison of 1–6 resorts for the current 3 or 7 days | `compare_resorts(resorts, days, nights)` |
| Arrival airports or a route from a user-chosen city/airport | `getting_there(resort, origin, mode)` |
| Labelled country-level lift-pass and lodging estimates | `trip_costs(country)` |

Start with a short answer addressing the user's priorities, using relevant returned Skinow information links. Add detail when it helps a decision. Research needs no trip creation or email address.

The `start/end` pair on `get_resort_details` selects a 7–31 day historical window; it does not change the forecast dates. For a specific upcoming weekend, resolve the calendar dates and select those days from its returned forecast. If outside the horizon, explain that only historical context is available. `compare_resorts` starts its 3/7-day window on the current UTC date.

Respect country, dates, ability and travel constraints. Present tradeoffs when no resort fits them all. Keep budgets secondary and retain country-average or modelled labels. When content such as budgets is excluded, leave it out of the answer and omit the interactive view if that view would display it.

## Optional interactive view

Details and comparisons return a `comparison_id`. Use `show_resort_comparison(comparison_id)` when the user wants to explore or an interactive comparison helps. A written answer and links are sufficient otherwise. Verify actual rendering before saying a view is displayed; MCP tools alone do not establish UI support. Snapshots expire after 20 minutes; retrieve a fresh one if needed.

## Evidence and privacy

Include forecast dates, elevation, units and update time when available. Keep deterministic totals and ensemble ranges distinct. Fresh operator reports establish current openings; stale or absent reports remain unknown. Snowfall, mapped lift counts and modelled outlooks do not establish that lifts are operating. Historical records describe past winters, and modelled snow depth is not a measurement. Retain returned sources, coverage and map/photo credits.

For routing, use an explicitly chosen city or airport. Do not infer a departure point from the connection or request precise coordinates, street addresses or postcodes. The OpenAI integration supplies information and planning; it has no booking, purchase or email-sending tools.

Referenced files: 1 — file references are metadata, not package contents.