find_destination
Discover travel destinations when the user does NOT know where to go. This is a destination EXPLORATION tool. WHEN TO USE THIS TOOL (CRITICAL): - The user does NOT specify a destination: "Where should I go?", "Best deals from NYC" - The user wants inspiration based on criteria: "Beach destination...
This record as markdown: /tools/com-gojinko-mcp-jinko/find-destination.md
What find_destination does on Jinko MCP
AI agents call find_destination to retrieve information from Jinko MCP without modifying anything. It is typically the context-gathering step in research, monitoring, and reporting workflows, before the agent takes action elsewhere.
| Parameter | Type | Required | Description |
|---|---|---|---|
locale | string | — | User's BCP 47 locale inferred from the conversation (e.g. "fr-FR", "en-US", "ja-JP"). Used for formatting dates, numbers, and selecting currency. Infer from the |
origins | array | Yes | REQUIRED. Array of origin IATA codes (3-letter uppercase), representing either airports or cities where the trip starts. The LLM MUST detect and include all rel |
sort_by | string | — | Sorting preference for search results. Options: "lowest" (cheapest first, default) or "recommendation" (best overall balance of price, duration, and stops). |
currency | string | — | ISO 4217 currency code for displaying prices (e.g. "EUR", "USD", "GBP"). Infer from the user's country or locale. If the user mentions a specific currency, use |
max_price | number | — | Maximum total price per passenger, the currency is user default currency. Filters out results exceeding the limit. Example: 500 = limit of $500/€500/£500 per pe |
stay_days | integer | — | Exact number of days to stay at the destination. Used with a departure date to automatically compute the return date. Example: 7 = one-week trip; 3 = weekend ge |
trip_type | string | Yes | REQUIRED. Type of trip: "oneway" for single-leg flights, or "roundtrip" for return flights. |
cabin_class | string | — | Preferred cabin class. Options: "economy", "premium_economy", "business", or "first". Filters results accordingly. |
direct_only | boolean | — | When true, only returns nonstop (direct) flights. Useful for avoiding layovers or minimizing total travel time. |
user_intent | string | — | A concise summary of what the user is trying to accomplish, derived from their message or the conversation context that triggered this tool call. This is used t |
destinations | array | — | OPTIONAL. Array of destination IATA codes (3-letter uppercase), representing either airports or cities. When a city code is provided, the LLM MUST expand it to |
return_dates | array | — | List of specific return dates for round-trip searches (YYYY-MM-DD). Must be after the corresponding departure dates. Supports multiple options (OR logic). Examp |
Parameters from the server's own tool schema.
Why find_destination is rated Low
This tool retrieves and queries travel destination information to help users explore options. It performs no side effects, does not modify data, does not execute external operations with variable outcomes, does not delete data, and does not process payments. It is purely informational/exploratory in nature, fitting squarely within the Read category.
From the tool's definition Tool name 'find_destination' and description states it is a 'destination EXPLORATION tool' that helps users 'Discover travel destinations' and 'compare multiple destination options' based on criteria like budget, weather, and origin city.
Risk signalsHigh parameter count (22 properties)
Attacks that exploit this kind of access
The rule that runs find_destination safely
PolicyLayer is an MCP gateway: it sits between your AI agents and Jinko MCP, and checks every tool call against a rule you set before the call runs. Nothing changes on the server itself. For find_destination, this is the rule to start with:
find_destination is read-only, so it stays allowed. Everything else on the server is denied unless you say otherwise.
The button opens the PolicyLayer dashboard: create your workspace, connect Jinko MCP, apply this rule, and every find_destination call is checked against it from then on.
Questions about find_destination
Discover travel destinations when the user does NOT know where to go. This is a destination EXPLORATION tool. WHEN TO USE THIS TOOL (CRITICAL): - The user does NOT specify a destination: "Where should I go?", "Best deals from NYC" - The user wants inspiration based on criteria: "Beach destinations", "Somewhere warm", "Cheap flights from SF" - The user wants to compare multiple destination options from their origin - The user previously asked for destination recommendations and wants pricing for those options WHEN NOT TO USE THIS TOOL — USE flight_calendar INSTEAD: - The user specifies BOTH an origin AND a destination → use flight_calendar - Examples that should use flight_calendar, NOT this tool: • "Flights from Paris to Barcelona" → flight_calendar • "Find me a flight from JFK to CDG" → flight_calendar • "Cheapest flight from LA to Miami in June" → flight_calendar • "Paris to BCN for a weekend in April" → flight_calendar • "What are the cheapest dates to go to NYC from Paris?" → flight_calendar - If the user names a specific city/airport as destination, that means they KNOW where to go → flight_calendar IMPORTANT - DATES: All dates in query parameters (departure_dates, departure_date_ranges, return_dates, return_date_ranges) MUST be in the future. Never use past dates. Please fill as much as possible search parameters based on user intent to get best results. IMPORTANT - RE-CALL THIS TOOL when the user: - Asks for a different type of destination (beach, city trip, ski, etc.) - Asks for different dates while still exploring - The user is already in fullscreen mode in the widget CORE FUNCTIONALITY: - REQUIRED: User's origin location (LLM identifies ALL nearby airports) - OPTIONAL: Destination filtering by specific airports/cities OR omit for global discovery mode - Destination Discovery Mode: When destinations is omitted/empty, searches ALL destinations globally - Flexible dates and stay durations for exploring options - Filter by budget, direct flights preference, and locale - By default, please search roundtrip flights unless user specifies one-way AIRPORT IDENTIFICATION - CRITICAL: LLM MUST identify and recommend ALL relevant airports for user's origin location: - "New York": ["JFK", "LGA", "EWR"] - "London": ["LHR", "LGW", "STN", "LTN", "LCY"] - "Paris": ["CDG", "ORY"] - "Tokyo": ["NRT", "HND"] - "Chicago": ["ORD", "MDW"] - "Los Angeles": ["LAX"] - "San Francisco": ["SFO"] DESTINATION FILTERING - INTELLIGENT INTERPRETATION: Destinations can be specified using IATA airport codes OR city codes (3 letters). You can mix both types: - Airport codes: ["JFK", "LAX", "LHR"] - searches specific airports - City codes: ["NYC", "LON", "PAR"] - searches all airports in those cities DESTINATION LIST - CRITICAL: When users mention criteria that imply a type of destination, the LLM MUST generate the appropriate list: - "Sunny places in winter": ["MIA","MCO","SAN","PHX","HNL","CUN","PUJ","PTY","LIM","GIG"] - "Somewhere in Asia": ["NRT","HND","ICN","PVG","PEK","HKG","SIN","BKK","KUL","MNL"] - "Beach destinations": ["MIA","SAN","HNL","CUN","PUJ","SJU","NAS","MBJ"] - "European capitals": ["LHR","CDG","FRA","MAD","FCO","AMS","BRU","VIE","PRG","CPH"] If no filtering is specified ("anywhere", "surprise me"), leave destinations empty for global discovery. TYPICAL USE CASES: 1. "Where should I travel from NYC next month?" → origins: ["JFK","LGA","EWR"], destinations: [] 2. "I want to go somewhere warm from Chicago for a week in December" → origins: ["ORD","MDW"], destinations: [warm destinations] 3. "Best weekend getaways from Boston?" → origins: ["BOS"], destinations: [] 4. "Beach vacation from Seattle in summer under $600" → origins: ["SEA"], destinations: [beach destinations] IMPORTANT: Always provide ALL airports for origins to maximize search results. Cost: 1 credit per call. It is categorised as a Read tool in the Jinko MCP MCP Server, which means it retrieves data without modifying state.
find_destination accepts 12 parameters: locale, origins, sort_by, currency, max_price, stay_days, trip_type, cabin_class, direct_only, user_intent, destinations, return_dates. Required: origins, trip_type. The full parameter table on this page comes from the server's own tool schema.
Register the Jinko MCP server in PolicyLayer and add a rule for find_destination: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches Jinko MCP. Nothing to install.
find_destination is a Read tool with low risk. Read-only tools are generally safe to allow by default.
Yes. Add a rate_limit block to the find_destination rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.
Set action: deny in the PolicyLayer policy for find_destination. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.
find_destination is provided by the Jinko MCP server (https://mcp.gojinko.com). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.
More on Jinko, and thousands of servers like it.
This server
Across the catalogue