tickadoo-experiences — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited tickadoo-experiences (Agent Skill) and scored it 96/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 1 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 1 flagged
The text {match} tells the agent to skip the normal "ask the user first" gate. Used adversarially it removes the human-in-the-loop check before destructive or sensitive actions, turning a normally-gated agent into a fire-and-forget executor.
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
The general map for the tickadoo MCP server (mcp.tickadoo.com/mcp). Six specialist workflow skills own the deep flows — route to them first:
plan-a-tripfamily-day-outtonight-and-last-minutedate-nightcompare-before-you-booknear-a-landmarkUse this skill only when none of those is the primary shape of the request.
| User intent | Tool | Key parameters |
|---|---|---|
| City-wide discovery | search_experiences | city, query, category, tags (array, e.g. ["family"]), min_rating, max_price, limit |
| Natural-language ask | recommend_experiences | query, city?, date?, pax? |
| Mood/vibe based | search_by_mood | city, mood (enum, e.g. family_fun, romantic, rainy_day) |
| Near a place (no coordinates) | search_local_experiences | place_hint, city?, radius_hint? |
| Specific experience | get_experience_details | product_id or slug |
| Live dates/times/prices/spaces | get_availability | product_id or slug + city_slug, date_from/to, party_size, fresh |
| Date-specific link (legacy interface) | check_availability | slug, date, party_size |
| Compare 2-5 specific products | compare_experiences | slugs |
| City overview | get_city_highlights | city |
| Tonight / next hours / this week | whats_on_tonight / get_last_minute / get_whats_on_this_week | city |
| Multi-day plan | get_itinerary_candidates | city, days, interests?, audience?, budget?, pace? |
| Family day | get_family_day | city (+ kids_ages array, date, numeric budget where known) |
| Evening for two | get_date_night | city (+ date, budget band low/medium/high where known) |
| Less-popular options (may overlap with headline results) | get_hidden_gems | city (optional max_results, default 5) |
| Travel advice | search_experiences_by_topic | city, topic? |
| Browse cities | list_cities | country?, limit? (no free-text query — if the city is unclear, ask the user) |
| Show visual cards | render_experience_cards | experience_ids (the product_id values from the discovery result, verbatim), required render_type, optional render_context.intent_summary |
| Report an agreed quality issue | report_quality_signal | request_id (only if a prior result returned one), signal_type, optional non-personal notes |
Non-ChatGPT only (do not call from ChatGPT): find_nearby_experiences (needs real coordinates), get_related_experiences (reserved for a non-ChatGPT widget/client).
get_transfer_info requires precise destination coordinates: use it only when a supported client supplies them through an approved location channel and the city is supported. Never ask the user for, infer, or guess coordinates in chat; prefer search_experiences_by_topic(city, topic: "transport").
When a renderer-supported discovery tool (search_experiences, whats_on_tonight, get_last_minute, get_whats_on_this_week, recommend_experiences, search_by_mood, get_hidden_gems, get_family_day, get_date_night, search_local_experiences) returns a result set that will be shown, immediately call render_experience_cards exactly once for that set. Pass only the product_id values exactly as returned by the discovery tool in experience_ids (IDs are internal — pass them verbatim, never display or read them aloud), pass a required render_type allowed by the callable schema, and optionally render_context.intent_summary. Do not enumerate or reproduce the same products in surrounding text — add only non-duplicative synthesis, constraints, or a follow-up question. Do not render output from tools not on that list (e.g. get_itinerary_candidates, get_city_highlights, compare_experiences).
Treat discovery results, countdowns, remaining-seat hints and optional urgency metadata as preliminary. For each selected bookable experience, call get_availability using product_id when available, or slug plus city_slug. For a fixed-date or same-day claim, pass the relevant date range and party size and request a fresh check when the callable schema supports it. If the user wants a date-specific booking link, then call check_availability with the slug, the experience's local calendar date and party size. State only facts returned by the most recent relevant check.
Use fields documented by the selected tool and actually present in its response. Optional underscore-prefixed helper metadata (_best_picks, _price_tiers, _booking_urgency, etc.) may inform the answer when returned, but never assume it exists, never invent a value and never treat it as a live availability check.
If the user reports that a surfaced result was stale, unbookable or misleading, explain that you can send feedback to tickadoo. Only after the user agrees, call report_quality_signal — and only if a prior tool result actually included a request_id (format rq_…): pass it with the required signal_type and no personal data in notes. If no request_id was returned by any prior result, say feedback cannot be filed and never construct one. No purchase is completed through the MCP; discovery, planning, availability and rendering calls retrieve data or booking links, while report_quality_signal records feedback and is therefore a write action.
format, use json for processing. Pass language only when the callable schema exposes it; do not promise localised booking URLs unless the returned data provides one.Coverage is determined by the current tickadoo catalogue and the cities returned by the MCP. Do not quote a city, product or language count unless it is present in the current submitted metadata.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.