Instant Malta visit facts and AI consultation: activities, dining, venues, photos and routes.
Scored across 9 tools
The four consult_* tools plus resolve_customer_need and get_quick_recommendations all claim to 'interpret a customer need and select relevant published services' with nearly identical descriptions and examples. The only differentiator is a single domain keyword (activities, events, hospitality, venues) in the first sentence, which is insufficient to clearly separate them. An agent could easily pick the wrong one or default to the generic resolve_customer_need.
All tool names use consistent snake_case and are descriptive, with clear prefixes like consult_* and get_*. The verb choices vary (catalogue, consult, get, resolve, search), but this is a minor deviation from a single verb_noun pattern rather than a chaotic mix.
Nine tools is a reasonable number for a read-only catalogue and enquiry server. The count is slightly inflated by redundant consult-like tools, but it remains well within a sensible range.
The surface covers coverage checking, searching, retrieving details by ID, quick recommendations, and domain-specific consulting. No create/update/delete operations are needed for a public read-only passport catalogue, though a general list/browse operation might be a minor gap.
Read the actual countries, companies and record counts currently included in the public AI MAXX catalogue. Useful for checking whether the requested geography is covered before searching.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| scope | Yes | |
| companies | Yes | |
| country_codes | Yes | |
| place_records | Yes | |
| company_records | Yes | |
| service_records | Yes | |
| searchable_records | Yes | |
| withheld_unverified_records | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and non-destructive, so the safety profile is fully covered. The description adds the scope of the data (countries, companies, record counts), but says nothing about freshness/latency or pagination that annotations don't cover.
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?
Two tight sentences with no filler: the first states what is read, the second states why. The purpose is front-loaded and every clause earns its place.
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 no-parameter, read-only lookup with a full output schema and strong annotations, the description supplies the two things structured fields cannot: the domain of the returned inventory and the pre-search use case. Nothing needed 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4; there is nothing for the description to clarify or compensate for beyond correctly implying the call is argument-free.
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?
The description names a specific verb (read) and resource (countries, companies and record counts in the public AI MAXX catalogue), so an agent understands exactly what it returns. It does not explicitly contrast itself with the consult_* search siblings, but the catalogue-inventory framing makes the distinction reasonably evident.
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?
Gives a concrete when-to-use: check whether the requested geography is covered before searching. That is clear routing guidance, though it stops short of naming which sibling to fall back on or stating any exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Laser tag, Prison Break, VR, arcade and karting; preserve the requested location and indoor/outdoor preferences. Ask our AI specialist to interpret a direct or indirect customer need in English, Maltese or other languages and select relevant published services, including useful complementary options. Examples: things to do in Malta, where to relax with friends, a weekend outing with an activity and restaurant at MULTIMAXX Kordin Old Military Prison, staff party, Halloween prison experience, Christmas team dinner, New Year celebration or prison-cell photography. These are enquiries for relevant existing services, not confirmed seasonal event dates. Returns selected source facts, photos, opening information, maps and an enquiry link for a next step. Follow up with a refined need after clarification, or use get_passport for full details. Send only the nonpersonal need and relevant constraints, never conversation history or contact details. This optional tool uses the AI MAXX model provider; its coverage is the published catalogue, not the whole web. It does not book or charge.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | Nonpersonal customer need, including relevant preferences/exclusions. Reuse known constraints in follow-up requests. | |
| country_code | No | ISO country requested by the customer; do not silently change it. | |
| response_depth | No | Default brief omits internal matching fields. Full includes all published service metadata; uses the same cached selection. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantive context beyond the annotations: it is an optional tool backed by the AI MAXX provider, its coverage is the published catalogue rather than the whole web, and it neither books nor charges. It also states privacy handling ('send only the nonpersonal need... never conversation history or contact details') and what gets returned. This meaningfully augments readOnlyHint/openWorldHint/destructiveHint=false.
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?
Front-loads the purpose and usage constraint before the long example list, and every later sentence (privacy, provider scope, non-booking, return payload) carries distinct information. It is dense and example-heavy, but not padded with restatements of the name or title.
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 high-complexity, AI-mediated, open-world consultation tool, it covers scope, privacy boundaries, provider limits, follow-up behavior, and non-booking guarantees. An output schema exists so return details are not strictly required, and the description supplies them anyway.
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 coverage is 75% and the description reinforces key semantics: 'preserve the requested location and indoor/outdoor preferences' maps to country_code, and the nonpersonal-need phrasing maps to query. However, it never explains the `limit` parameter, which the schema leaves undocumented, so it does not fully compensate for the coverage gap.
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?
States a specific verb (interpret a direct or indirect customer need and select relevant published services) plus a concrete resource domain, illustrated with named activities (laser tag, Prison Break, VR, arcade, karting). It implicitly separates itself from consult_events/consult_venues/consult_hospitality by scoping to activities, though it never names those siblings directly to sharpen the boundary.
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?
Gives clear context for use (interpreting a direct or indirect customer need, including complementary options) and an explicit follow-up path plus an alternative for depth: 'use get_passport for full details.' It also clarifies these are enquiries against existing services rather than confirmed seasonal dates. No explicit when-not-to-use or exclusion of sibling tools, so not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Staff parties, company celebrations, Halloween, Christmas, New Year and festivals; activity plus hospitality when relevant. Ask our AI specialist to interpret a direct or indirect customer need in English, Maltese or other languages and select relevant published services, including useful complementary options. Examples: things to do in Malta, where to relax with friends, a weekend outing with an activity and restaurant at MULTIMAXX Kordin Old Military Prison, staff party, Halloween prison experience, Christmas team dinner, New Year celebration or prison-cell photography. These are enquiries for relevant existing services, not confirmed seasonal event dates. Returns selected source facts, photos, opening information, maps and an enquiry link for a next step. Follow up with a refined need after clarification, or use get_passport for full details. Send only the nonpersonal need and relevant constraints, never conversation history or contact details. This optional tool uses the AI MAXX model provider; its coverage is the published catalogue, not the whole web. It does not book or charge.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | Nonpersonal customer need, including relevant preferences/exclusions. Reuse known constraints in follow-up requests. | |
| country_code | No | ISO country requested by the customer; do not silently change it. | |
| response_depth | No | Default brief omits internal matching fields. Full includes all published service metadata; uses the same cached selection. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=false, destructiveHint=false, so the agent knows this is a safe, non-deterministic read. The description adds that it uses the AI MAXX provider, the coverage is the published catalogue, and that it does not book or charge — but it buries these behavioral facts inside an example list, and fails to note idempotency, which is a material trait for a selection tool.
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?
A single run-on sentence crammed with examples, followed by a mix of behavioural notes and follow-up routing. Poorly front-loaded: the core purpose ('plans staff parties and events') is lost among generic examples like 'things to do in Malta' and 'weekend outing'.
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?
Given one required parameter, an output schema, and annotations, the description covers the main behaviour (AI-assisted selection, read-only, no booking) but omits crucial operational details such as what the returned 'enquiry link' does, whether it triggers any side effect, and how to interpret the optional limit. It is adequate but leaves gaps that could lead to misuse.
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 coverage is 75%, so the schema documents three of four parameters. The description mentions sending only the nonpersonal need and relevant constraints, which aligns with the query parameter, but adds no syntax, format, or guidance for limit, country_code, or response_depth. It does not compensate for the coverage gap.
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?
The title and description indicate it plans staff parties/events, but the description is an unstructured list of example queries and use cases, not a clean verb+resource statement. It doesn't distinguish from consult_activities, consult_hospitality, or consult_venues.
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?
Implicitly when to use: staff parties, celebrations, festivals. It advises following up with a refined need or using get_passport, and warns against sending personal data. However, it lacks explicit when-not-to-use guidance or comparison with the other consult_* tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pavilion dining, dedicated Kordin BBQ area and food court enquiries; useful food-first options for the group. Ask our AI specialist to interpret a direct or indirect customer need in English, Maltese or other languages and select relevant published services, including useful complementary options. Examples: things to do in Malta, where to relax with friends, a weekend outing with an activity and restaurant at MULTIMAXX Kordin Old Military Prison, staff party, Halloween prison experience, Christmas team dinner, New Year celebration or prison-cell photography. These are enquiries for relevant existing services, not confirmed seasonal event dates. Returns selected source facts, photos, opening information, maps and an enquiry link for a next step. Follow up with a refined need after clarification, or use get_passport for full details. Send only the nonpersonal need and relevant constraints, never conversation history or contact details. This optional tool uses the AI MAXX model provider; its coverage is the published catalogue, not the whole web. It does not book or charge.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | Nonpersonal customer need, including relevant preferences/exclusions. Reuse known constraints in follow-up requests. | |
| country_code | No | ISO country requested by the customer; do not silently change it. | |
| response_depth | No | Default brief omits internal matching fields. Full includes all published service metadata; uses the same cached selection. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, non-destructive, open-world behavior, and the description adds material context beyond them: it uses the AI MAXX provider, coverage is the published catalogue rather than the whole web, and it neither books nor charges. It also describes the returned payload (facts, photos, opening info, maps, enquiry link).
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?
The purpose is front-loaded, but the body is bloated with a long list of example scenarios (Halloween prison experience, prison-cell photography, etc.) that reads like prompt scaffolding rather than tool documentation. Much of it does not earn its place, pushing key routing and privacy rules behind noise.
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?
With an output schema present and rich annotations, the description need not explain return format in depth, and it still covers provider, scope limits, non-booking behavior, privacy handling, and the follow-up path. The main gap is the absence of explicit tie-breaking against the sibling consult_* tools.
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 coverage is 75% and already documents query, country_code, and response_depth. The description reinforces the query semantics by stressing nonpersonal need plus constraints, never conversation history or contact details, and its 'not confirmed seasonal event dates' note clarifies how loosely the query is matched.
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?
The opening clause names the specific resources covered (Pavilion dining, Kordin BBQ area, food court) and the tool's framing as a food-first enquiry. It is distinguishable from consult_activities/consult_events/consult_venues, though the long example list dilutes rather than sharpens that purpose.
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?
Gives clear routing guidance: follow up with a refined need after clarification, or use get_passport for full details. It also states the privacy constraint (send only the nonpersonal need). It stops short of explicitly stating when NOT to use it in favor of the sibling consult_* tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Venue hire, historic prison photography, film and TV production spaces; respect the requested use. Ask our AI specialist to interpret a direct or indirect customer need in English, Maltese or other languages and select relevant published services, including useful complementary options. Examples: things to do in Malta, where to relax with friends, a weekend outing with an activity and restaurant at MULTIMAXX Kordin Old Military Prison, staff party, Halloween prison experience, Christmas team dinner, New Year celebration or prison-cell photography. These are enquiries for relevant existing services, not confirmed seasonal event dates. Returns selected source facts, photos, opening information, maps and an enquiry link for a next step. Follow up with a refined need after clarification, or use get_passport for full details. Send only the nonpersonal need and relevant constraints, never conversation history or contact details. This optional tool uses the AI MAXX model provider; its coverage is the published catalogue, not the whole web. It does not book or charge.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | Nonpersonal customer need, including relevant preferences/exclusions. Reuse known constraints in follow-up requests. | |
| country_code | No | ISO country requested by the customer; do not silently change it. | |
| response_depth | No | Default brief omits internal matching fields. Full includes all published service metadata; uses the same cached selection. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, openWorld, non-idempotent, non-destructive), it discloses that the tool uses the AI MAXX model provider, that coverage is limited to the published catalogue rather than the whole web, that it does not book or charge, and that only nonpersonal needs should be sent with no conversation history or contact details. These are substantive behavioral and privacy constraints an agent could not infer from structured fields.
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?
The core capability is front-loaded, but the six-example laundry list ('things to do in Malta', 'Halloween prison experience', 'Christmas team dinner'...) consumes a large share of the text and mixes marketing scenarios with operational guidance. It is informative but not tightly structured.
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 4-parameter consult tool with an output schema, the description covers the important non-schema context: privacy constraints on query content, catalogue coverage limits, no booking/charging, and the post-clarification follow-up. Return values are described briefly even though the output schema would suffice, leaving little material gap.
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 75%, so the schema already documents query, country_code, and response_depth semantics reasonably well. The description reinforces the nonpersonal-query and constraint-reuse rules but adds no syntax or meaning for limit or the enum value tradeoffs beyond what the schema states, so the baseline 3 applies.
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?
The description names a specific domain (venue hire, film/TV production spaces, historic prison photography) and the mechanism (ask the AI specialist to interpret a customer need and select published services). It is clear what the tool does, but sibling differentiation against consult_activities, consult_events, and consult_hospitality rests mainly on example lists rather than an explicit boundary statement.
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?
It states the operational context (enquiries for existing services, not confirmed seasonal dates) and gives an explicit escalation path: follow up with a refined need after clarification, or use get_passport for full details. It does not, however, say when a caller should prefer a sibling consultation tool over this one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one public AI MAXX passport using an exact id returned by search_passports. Returns published facts and provenance. Does not access customer accounts, enquiries, private drafts or payment records.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and non-open-world, so safety is covered. The description adds genuine context beyond that: the tool only reaches published facts and provenance, and explicitly excludes customer accounts, enquiries, private drafts and payment records — a useful data-boundary disclosure.
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 short sentences, zero filler. The purpose and required id source come first, with the privacy boundary last — appropriately front-loaded.
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?
An output schema exists, so return structure need not be re-explained, and the description still gives a one-line summary of what comes back (published facts and provenance). Combined with the exclusion list, an agent has everything needed to call this correctly.
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?
The schema documents only type and length bounds with 0% description coverage, so the description must carry meaning: it tells the agent the id is an exact identifier obtained from search_passports rather than a name or partial match. That is a real semantic addition, though it does not explain the 1-160 character constraint's practical implication.
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?
Specific verb (Read) + resource (one public AI MAXX passport) + scope qualifier (public only, single record). It clearly distinguishes itself from the sibling search_passports by stating it reads exactly one record by id.
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?
Explicitly states the id must be an exact one returned by search_passports, which routes the agent correctly from the search tool to this fetch tool. It does not spell out failure behavior or when to prefer search_passports instead, but the usage context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fast first choice for a matching common need: broad Malta leisure or weekend plans with MULTIMAXX activities, parties and Pavilion restaurant at Kordin Old Military Prison (leisure_kordin); staff party with activity and food at Kordin; Halloween prison photos and BBQ at Kordin; indoor laser tag and VR in St Julian’s. Returns preassembled published facts, photos, routes and enquiry links without a model round trip. Use only if the specific route fits the customer geography and constraints; never substitute another country or unwanted activity. For other needs or exclusions use a specialist consultant. No live booking or payment.
| Name | Required | Description | Default |
|---|---|---|---|
| intent | Yes | ||
| country_code | Yes | Actual country requested; quick routes currently cover Malta (MT) only. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, closed-world, non-destructive behaviour, so the safety profile is covered. The description still adds real context beyond the annotations: it returns preassembled published content 'without a model round trip' and performs 'No live booking or payment', which tells the agent the scope of what the call actually does.
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?
The opening and closing constraints are well front-loaded, but the middle is a bloated marketing enumeration ('MULTIMAXX activities, parties and Pavilion restaurant at Kordin Old Military Prison') that is hard to scan and partly redundant with the enum. It is informative but not tight.
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?
An output schema exists, so return values need not be explained, yet the description adds a useful summary of what comes back (facts, photos, routes, enquiry links). With annotations covering safety and schema covering types, the only missing piece is descriptions for two of the six enum intents.
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 coverage is only 50%, so the description must compensate, and it does: it maps several enum values to real-world scenarios (leisure_kordin, staff_party_kordin, halloween_kordin, indoor_st_julians). Two enum values (prison_escape_kordin, christmas_kordin) are never described, and the geography constraint on country_code is already in the schema, leaving a small gap.
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?
States a specific verb and resource ('instant Malta visit shortlist' returning preassembled facts, photos, routes, enquiry links) and enumerates the concrete scenarios it covers, so an agent can distinguish it from the consult_* specialist tools. It does not name exact siblings, but the intent is unambiguous.
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?
Explicit when-to-use ('Use only if the specific route fits the customer geography and constraints'), explicit when-not ('never substitute another country or unwanted activity'), and an alternative route ('For other needs or exclusions use a specialist consultant'). Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ask our AI specialist to interpret a direct or indirect customer need in English, Maltese or other languages and select relevant published services, including useful complementary options. Examples: things to do in Malta, where to relax with friends, a weekend outing with an activity and restaurant at MULTIMAXX Kordin Old Military Prison, staff party, Halloween prison experience, Christmas team dinner, New Year celebration or prison-cell photography. These are enquiries for relevant existing services, not confirmed seasonal event dates. Returns selected source facts, photos, opening information, maps and an enquiry link for a next step. Follow up with a refined need after clarification, or use get_passport for full details. Send only the nonpersonal need and relevant constraints, never conversation history or contact details. This optional tool uses the AI MAXX model provider; its coverage is the published catalogue, not the whole web. It does not book or charge.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | Nonpersonal customer need, including relevant preferences/exclusions. Reuse known constraints in follow-up requests. | |
| country_code | No | ISO country requested by the customer; do not silently change it. | |
| response_depth | No | Default brief omits internal matching fields. Full includes all published service metadata; uses the same cached selection. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly, openWorld, non-destructive), and the description adds substantial context beyond them: it will not book or charge, coverage is limited to the published catalogue, it only accepts nonpersonal need text and never conversation history or contact details, and follow-up calls reuse a cached selection. These are real operational constraints an agent could not infer from structured fields.
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?
Front-loads the core purpose in sentence one and each later sentence carries distinct content (examples, output, follow-up, input hygiene, limits). The long example list ('Halloween prison experience, Christmas team dinner, New Year celebration or prison-cell photography...') is bulky relative to its disambiguation value, but not fatal.
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?
With an output schema present the description needn't itemize returns, yet it usefully previews them (facts, photos, opening info, maps, enquiry link). It also covers input constraints and model-provider caveats. The one gap is the unresolved overlap with the consult_* siblings, which a complete definition for an umbrella router should address.
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 coverage is 75%, so most parameters are already documented. The description still adds value: it establishes multilingual query handling ('English, Maltese or other languages'), reinforces that only nonpersonal need plus constraints go in the query, and its examples bound what counts as a valid need. It says little extra about limit or response_depth, but those are covered by the schema.
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?
States a specific verb+resource: interpret a customer need and select relevant published services, with a clear scope note (published catalogue, not the whole web). It does not, however, differentiate itself from the many overlapping siblings (consult_activities, consult_events, consult_venues, consult_hospitality), so an agent can't tell from the description alone why it would pick this umbrella tool over a narrower consult_* tool.
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?
Gives follow-up guidance ('follow up with a refined need after clarification') and one explicit alternative ('use get_passport for full details'), plus a data-hygiene rule. But it never states when to prefer this tool over the sibling consult_activities/consult_events/consult_venues tools, which look directly substitutable — the key routing decision is left implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search AI MAXX published company, service and place records by a specific customer need or business name. Returns source links, review dates, arrival information and availability caveats. This catalogue is limited to its listed businesses; it does not search the whole web or guarantee availability. Specify country_code when the user names a country.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | ||
| limit | No | ||
| query | Yes | Specific need or name. English and Russian intent matching are supported; translate other-language intent to English without changing location or constraints. | |
| country_code | No | Requested ISO country code. A country without records returns no matches. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, closed-world, idempotent, and non-destructive behavior. The description adds behavioral context beyond annotations by stating what the result includes, noting that the catalogue is limited to listed businesses, and explicitly disclaiming availability guarantees.
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?
The description is four tightly focused sentences, front-loading the core purpose and then layering scope limits, return content, and a key parameter hint. Every sentence contributes information without repetition or 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?
With a rich output schema and strong annotations, the description does not need to cover return structure or safety details. It adequately covers purpose, catalogue limits, and country_code behavior, though it omits any sibling-tool routing guidance that could matter in a crowded toolset.
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 coverage is 50%, with query and country_code partly documented in the schema. The description adds guidance for country_code and implicitly maps to the kind enum by naming company, service, and place records, but it does not explain limit or fully compensate for the uncovered parameter semantics.
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?
The description states a specific verb and resource: search AI MAXX published company, service and place records. It clearly communicates scope in the title and body, but it does not explicitly distinguish this tool from siblings such as get_passport or resolve_customer_need, so sibling differentiation is left to the agent.
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?
It gives clear use context by saying the search is for a specific customer need or business name, and it adds useful scope exclusions such as not searching the whole web. However, it never names alternative tools or explains when to prefer this tool over related siblings, leaving routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_quick_recommendations1 field changedInput schema / properties / intent / enumPrevious value: -[
- "leisure_kordin",
- "staff_party_kordin",
- "halloween_kordin",
- "indoor_st_julians"
-]New value: +[
+ "prison_escape_kordin",
+ "christmas_kordin",
+ "leisure_kordin",
+ "staff_party_kordin",
+ "halloween_kordin",
+ "indoor_st_julians"
+]catalogue_coverage1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "companies": {
+ "items": {
+ "properties": {
+ "country_code": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "passport_id": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "country_code",
+ "passport_id"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "company_records": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "country_codes": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "place_records": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "scope": {
+ "type": "string"
+ },
+ "searchable_records": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "service_records": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "withheld_unverified_records": {
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "companies",
+ "country_codes",
+ "searchable_records",
+ "company_records",
+ "service_records",
+ "place_records",
+ "withheld_unverified_records",
+ "scope"
+ ],
+ "type": "object"
+}consult_activities1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "anyOf": [
+ {
+ "properties": {
+ "catalogue_revision": {
+ "type": "string"
+ },
+ "clarification_fields": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "consultant": {
+ "type": "string"
+ },
+ "engine": {
+ "type": "string"
+ },
+ "follow_up": {
+ "properties": {
+ "api": {
+ "properties": {
+ "consultant": {
+ "type": "string"
+ },
+ "method": {
+ "const": "POST"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "method",
+ "url",
+ "consultant"
+ ],
+ "type": "object"
+ },
+ "instructions": {
+ "type": "string"
+ },
+ "needed": {
+ "type": "boolean"
+ },
+ "questions": {
+ "items": {
+ "properties": {
+ "field": {
+ "type": "string"
+ },
+ "question": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "field",
+ "question"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "state": {
+ "type": "string"
+ },
+ "tool": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "needed",
+ "questions",
+ "tool",
+ "api",
+ "instructions",
+ "state"
+ ],
+ "type": "object"
+ },
+ "location_relationship": {
+ "type": "string"
+ },
+ "matches": {
+ "items": {
+ "properties": {
+ "passport": {
+ "properties": {
+ "arrival": {
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "company": {
+ "type": "string"
+ },
+ "country_code": {
+ "type": "string"
+ },
+ "description": {
+ "type": "string"
+ },
+ "enquiry": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "kind": {
+ "enum": [
+ "company",
+ "service",
+ "place"
+ ],
+ "type": "string"
+ },
+ "location_media": {
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "name": {
+ "type": "string"
+ },
+ "navigation": {
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "opening_information": {
+ "type": "string"
+ },
+ "passport_url": {
+ "type": "string"
+ },
+ "reviewed_at": {
+ "type": "string"
+ },
+ "source": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "company",
+ "country_code",
+ "passport_url",
+ "source",
+ "reviewed_at",
+ "description"
+ ],
+ "type": "object"
+ },
+ "relevant_facts": {
+ "items": {
+ "properties": {
+ "field": {
+ "type": "string"
+ },
+ "value": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "field",
+ "value"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "role": {
+ "enum": [
+ "primary",
+ "complementary"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "role",
+ "passport",
+ "relevant_facts"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "measurement": {
+ "properties": {
+ "contact_link": {
+ "type": "string"
+ },
+ "meaning": {
+ "type": "string"
+ },
+ "traffic": {
+ "enum": [
+ "internal_evaluation",
+ "external_unverified"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "traffic",
+ "meaning",
+ "contact_link"
+ ],
+ "type": "object"
+ },
+ "mode": {
+ "type": "string"
+ },
+ "next_steps": {
+ "items": {
+ "properties": {
+ "details_tool": {
+ "type": "string"
+ },
+ "enquiry_url": {
+ "type": "string"
+ },
+ "measured_enquiry_url": {
+ "type": "string"
+ },
+ "passport_id": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "passport_id",
+ "details_tool",
+ "enquiry_url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "recovery": {
+ "properties": {
+ "automatic_model_retry": {
+ "type": "string"
+ },
+ "catalogue": {
+ "type": "string"
+ },
+ "mode": {
+ "type": "string"
+ },
+ "reason": {
+ "type": "string"
+ },
+ "source_index": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "mode",
+ "automatic_model_retry"
+ ],
+ "type": "object"
+ },
+ "response_depth": {
+ "enum": [
+ "brief",
+ "full"
+ ],
+ "type": "string"
+ },
+ "scope": {
+ "type": "string"
+ },
+ "topic": {
+ "type": "string"
+ },
+ "visit_groups": {
+ "items": {
+ "properties": {
+ "location_pages": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "name": {
+ "type": "string"
+ },
+ "passport_ids": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "name",
+ "passport_ids",
+ "location_pages"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "engine",
+ "consultant",
+ "mode",
+ "topic",
+ "visit_groups",
+ "location_relationship",
+ "response_depth",
+ "matches",
+ "clarification_fields",
+ "follow_up",
+ "next_steps",
+ "scope"
+ ],
+ "type": "object"
+ },
+ {
+ "properties": {
+ "error": {
+ "type": "string"
+ },
+ "fallback_tool": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ },
+ "recovery": {
+ "properties": {
+ "automatic_model_retry": {
+ "type": "string"
+ },
+ "catalogue": {
+ "type": "string"
+ },
+ "mode": {
+ "type": "string"
+ },
+ "reason": {
+ "type": "string"
+ },
+ "source_index": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "mode",
+ "automatic_model_retry"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "error"
+ ],
+ "type": "object"
+ }
+ ],
+ "type": "object"
+}consult_events1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "anyOf": [
+ {
+ "properties": {
+ "catalogue_revision": {
+ "type": "string"
+ },
+ "clarification_fields": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "consultant": {
+ "type": "string"
+ },
+ "engine": {
+ "type": "string"
+ },
+ "follow_up": {
+ "properties": {
+ "api": {
+ "properties": {
+ "consultant": {
+ "type": "string"
+ },
+ "method": {
+ "const": "POST"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "method",
+ "url",
+ "consultant"
+ ],
+ "type": "object"
+ },
+ "instructions": {
+ "type": "string"
+ },
+ "needed": {
+ "type": "boolean"
+ },
+ "questions": {
+ "items": {
+ "properties": {
+ "field": {
+ "type": "string"
+ },
+ "question": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "field",
+ "question"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "state": {
+ "type": "string"
+ },
+ "tool": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "needed",
+ "questions",
+ "tool",
+ "api",
+ "instructions",
+ "state"
+ ],
+ "type": "object"
+ },
+ "location_relationship": {
+ "type": "string"
+ },
+ "matches": {
+ "items": {
+ "properties": {
+ "passport": {
+ "properties": {
+ "arrival": {
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "company": {
+ "type": "string"
+ },
+ "country_code": {
+ "type": "string"
+ },
+ "description": {
+ "type": "string"
+ },
+ "enquiry": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "kind": {
+ "enum": [
+ "company",
+ "service",
+ "place"
+ ],
+ "type": "string"
+ },
+ "location_media": {
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "name": {
+ "type": "string"
+ },
+ "navigation": {
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "opening_information": {
+ "type": "string"
+ },
+ "passport_url": {
+ "type": "string"
+ },
+ "reviewed_at": {
+ "type": "string"
+ },
+ "source": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "company",
+ "country_code",
+ "passport_url",
+ "source",
+ "reviewed_at",
+ "description"
+ ],
+ "type": "object"
+ },
+ "relevant_facts": {
+ "items": {
+ "properties": {
+ "field": {
+ "type": "string"
+ },
+ "value": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "field",
+ "value"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "role": {
+ "enum": [
+ "primary",
+ "complementary"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "role",
+ "passport",
+ "relevant_facts"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "measurement": {
+ "properties": {
+ "contact_link": {
+ "type": "string"
+ },
+ "meaning": {
+ "type": "string"
+ },
+ "traffic": {
+ "enum": [
+ "internal_evaluation",
+ "external_unverified"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "traffic",
+ "meaning",
+ "contact_link"
+ ],
+ "type": "object"
+ },
+ "mode": {
+ "type": "string"
+ },
+ "next_steps": {
+ "items": {
+ "properties": {
+ "details_tool": {
+ "type": "string"
+ },
+ "enquiry_url": {
+ "type": "string"
+ },
+ "measured_enquiry_url": {
+ "type": "string"
+ },
+ "passport_id": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "passport_id",
+ "details_tool",
+ "enquiry_url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "recovery": {
+ "properties": {
+ "automatic_model_retry": {
+ "type": "string"
+ },
+ "catalogue": {
+ "type": "string"
+ },
+ "mode": {
+ "type": "string"
+ },
+ "reason": {
+ "type": "string"
+ },
+ "source_index": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "mode",
+ "automatic_model_retry"
+ ],
+ "type": "object"
+ },
+ "response_depth": {
+ "enum": [
+ "brief",
+ "full"
+ ],
+ "type": "string"
+ },
+ "scope": {
+ "type": "string"
+ },
+ "topic": {
+ "type": "string"
+ },
+ "visit_groups": {
+ "items": {
+ "properties": {
+ "location_pages": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "name": {
+ "type": "string"
+ },
+ "passport_ids": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "name",
+ "passport_ids",
+ "location_pages"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "engine",
+ "consultant",
+ "mode",
+ "topic",
+ "visit_groups",
+ "location_relationship",
+ "response_depth",
+ "matches",
+ "clarification_fields",
+ "follow_up",
+ "next_steps",
+ "scope"
+ ],
+ "type": "object"
+ },
+ {
+ "properties": {
+ "error": {
+ "type": "string"
+ },
+ "fallback_tool": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ },
+ "recovery": {
+ "properties": {
+ "automatic_model_retry": {
+ "type": "string"
+ },
+ "catalogue": {
+ "type": "string"
+ },
+ "mode": {
+ "type": "string"
+ },
+ "reason": {
+ "type": "string"
+ },
+ "source_index": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "mode",
+ "automatic_model_retry"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "error"
+ ],
+ "type": "object"
+ }
+ ],
+ "type": "object"
+}consult_hospitality1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "anyOf": [
+ {
+ "properties": {
+ "catalogue_revision": {
+ "type": "string"
+ },
+ "clarification_fields": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "consultant": {
+ "type": "string"
+ },
+ "engine": {
+ "type": "string"
+ },
+ "follow_up": {
+ "properties": {
+ "api": {
+ "properties": {
+ "consultant": {
+ "type": "string"
+ },
+ "method": {
+ "const": "POST"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "method",
+ "url",
+ "consultant"
+ ],
+ "type": "object"
+ },
+ "instructions": {
+ "type": "string"
+ },
+ "needed": {
+ "type": "boolean"
+ },
+ "questions": {
+ "items": {
+ "properties": {
+ "field": {
+ "type": "string"
+ },
+ "question": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "field",
+ "question"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "state": {
+ "type": "string"
+ },
+ "tool": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "needed",
+ "questions",
+ "tool",
+ "api",
+ "instructions",
+ "state"
+ ],
+ "type": "object"
+ },
+ "location_relationship": {
+ "type": "string"
+ },
+ "matches": {
+ "items": {
+ "properties": {
+ "passport": {
+ "properties": {
+ "arrival": {
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "company": {
+ "type": "string"
+ },
+ "country_code": {
+ "type": "string"
+ },
+ "description": {
+ "type": "string"
+ },
+ "enquiry": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "kind": {
+ "enum": [
+ "company",
+ "service",
+ "place"
+ ],
+ "type": "string"
+ },
+ "location_media": {
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "name": {
+ "type": "string"
+ },
+ "navigation": {
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "opening_information": {
+ "type": "string"
+ },
+ "passport_url": {
+ "type": "string"
+ },
+ "reviewed_at": {
+ "type": "string"
+ },
+ "source": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "company",
+ "country_code",
+ "passport_url",
+ "source",
+ "reviewed_at",
+ "description"
+ ],
+ "type": "object"
+ },
+ "relevant_facts": {
+ "items": {
+ "properties": {
+ "field": {
+ "type": "string"
+ },
+ "value": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "field",
+ "value"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "role": {
+ "enum": [
+ "primary",
+ "complementary"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "role",
+ "passport",
+ "relevant_facts"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "measurement": {
+ "properties": {
+ "contact_link": {
+ "type": "string"
+ },
+ "meaning": {
+ "type": "string"
+ },
+ "traffic": {
+ "enum": [
+ "internal_evaluation",
+ "external_unverified"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "traffic",
+ "meaning",
+ "contact_link"
+ ],
+ "type": "object"
+ },
+ "mode": {
+ "type": "string"
+ },
+ "next_steps": {
+ "items": {
+ "properties": {
+ "details_tool": {
+ "type": "string"
+ },
+ "enquiry_url": {
+ "type": "string"
+ },
+ "measured_enquiry_url": {
+ "type": "string"
+ },
+ "passport_id": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "passport_id",
+ "details_tool",
+ "enquiry_url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "recovery": {
+ "properties": {
+ "automatic_model_retry": {
+ "type": "string"
+ },
+ "catalogue": {
+ "type": "string"
+ },
+ "mode": {
+ "type": "string"
+ },
+ "reason": {
+ "type": "string"
+ },
+ "source_index": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "mode",
+ "automatic_model_retry"
+ ],
+ "type": "object"
+ },
+ "response_depth": {
+ "enum": [
+ "brief",
+ "full"
+ ],
+ "type": "string"
+ },
+ "scope": {
+ "type": "string"
+ },
+ "topic": {
+ "type": "string"
+ },
+ "visit_groups": {
+ "items": {
+ "properties": {
+ "location_pages": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "name": {
+ "type": "string"
+ },
+ "passport_ids": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "name",
+ "passport_ids",
+ "location_pages"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "engine",
+ "consultant",
+ "mode",
+ "topic",
+ "visit_groups",
+ "location_relationship",
+ "response_depth",
+ "matches",
+ "clarification_fields",
+ "follow_up",
+ "next_steps",
+ "scope"
+ ],
+ "type": "object"
+ },
+ {
+ "properties": {
+ "error": {
+ "type": "string"
+ },
+ "fallback_tool": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ },
+ "recovery": {
+ "properties": {
+ "automatic_model_retry": {
+ "type": "string"
+ },
+ "catalogue": {
+ "type": "string"
+ },
+ "mode": {
+ "type": "string"
+ },
+ "reason": {
+ "type": "string"
+ },
+ "source_index": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "mode",
+ "automatic_model_retry"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "error"
+ ],
+ "type": "object"
+ }
+ ],
+ "type": "object"
+}consult_venues1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "anyOf": [
+ {
+ "properties": {
+ "catalogue_revision": {
+ "type": "string"
+ },
+ "clarification_fields": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "consultant": {
+ "type": "string"
+ },
+ "engine": {
+ "type": "string"
+ },
+ "follow_up": {
+ "properties": {
+ "api": {
+ "properties": {
+ "consultant": {
+ "type": "string"
+ },
+ "method": {
+ "const": "POST"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "method",
+ "url",
+ "consultant"
+ ],
+ "type": "object"
+ },
+ "instructions": {
+ "type": "string"
+ },
+ "needed": {
+ "type": "boolean"
+ },
+ "questions": {
+ "items": {
+ "properties": {
+ "field": {
+ "type": "string"
+ },
+ "question": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "field",
+ "question"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "state": {
+ "type": "string"
+ },
+ "tool": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "needed",
+ "questions",
+ "tool",
+ "api",
+ "instructions",
+ "state"
+ ],
+ "type": "object"
+ },
+ "location_relationship": {
+ "type": "string"
+ },
+ "matches": {
+ "items": {
+ "properties": {
+ "passport": {
+ "properties": {
+ "arrival": {
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "company": {
+ "type": "string"
+ },
+ "country_code": {
+ "type": "string"
+ },
+ "description": {
+ "type": "string"
+ },
+ "enquiry": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "kind": {
+ "enum": [
+ "company",
+ "service",
+ "place"
+ ],
+ "type": "string"
+ },
+ "location_media": {
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "name": {
+ "type": "string"
+ },
+ "navigation": {
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "opening_information": {
+ "type": "string"
+ },
+ "passport_url": {
+ "type": "string"
+ },
+ "reviewed_at": {
+ "type": "string"
+ },
+ "source": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "company",
+ "country_code",
+ "passport_url",
+ "source",
+ "reviewed_at",
+ "description"
+ ],
+ "type": "object"
+ },
+ "relevant_facts": {
+ "items": {
+ "properties": {
+ "field": {
+ "type": "string"
+ },
+ "value": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "field",
+ "value"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "role": {
+ "enum": [
+ "primary",
+ "complementary"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "role",
+ "passport",
+ "relevant_facts"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "measurement": {
+ "properties": {
+ "contact_link": {
+ "type": "string"
+ },
+ "meaning": {
+ "type": "string"
+ },
+ "traffic": {
+ "enum": [
+ "internal_evaluation",
+ "external_unverified"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "traffic",
+ "meaning",
+ "contact_link"
+ ],
+ "type": "object"
+ },
+ "mode": {
+ "type": "string"
+ },
+ "next_steps": {
+ "items": {
+ "properties": {
+ "details_tool": {
+ "type": "string"
+ },
+ "enquiry_url": {
+ "type": "string"
+ },
+ "measured_enquiry_url": {
+ "type": "string"
+ },
+ "passport_id": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "passport_id",
+ "details_tool",
+ "enquiry_url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "recovery": {
+ "properties": {
+ "automatic_model_retry": {
+ "type": "string"
+ },
+ "catalogue": {
+ "type": "string"
+ },
+ "mode": {
+ "type": "string"
+ },
+ "reason": {
+ "type": "string"
+ },
+ "source_index": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "mode",
+ "automatic_model_retry"
+ ],
+ "type": "object"
+ },
+ "response_depth": {
+ "enum": [
+ "brief",
+ "full"
+ ],
+ "type": "string"
+ },
+ "scope": {
+ "type": "string"
+ },
+ "topic": {
+ "type": "string"
+ },
+ "visit_groups": {
+ "items": {
+ "properties": {
+ "location_pages": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "name": {
+ "type": "string"
+ },
+ "passport_ids": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "name",
+ "passport_ids",
+ "location_pages"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "engine",
+ "consultant",
+ "mode",
+ "topic",
+ "visit_groups",
+ "location_relationship",
+ "response_depth",
+ "matches",
+ "clarification_fields",
+ "follow_up",
+ "next_steps",
+ "scope"
+ ],
+ "type": "object"
+ },
+ {
+ "properties": {
+ "error": {
+ "type": "string"
+ },
+ "fallback_tool": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ },
+ "recovery": {
+ "properties": {
+ "automatic_model_retry": {
+ "type": "string"
+ },
+ "catalogue": {
+ "type": "string"
+ },
+ "mode": {
+ "type": "string"
+ },
+ "reason": {
+ "type": "string"
+ },
+ "source_index": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "mode",
+ "automatic_model_retry"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "error"
+ ],
+ "type": "object"
+ }
+ ],
+ "type": "object"
+}get_passport1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "anyOf": [
+ {
+ "properties": {
+ "passport": {
+ "properties": {
+ "arrival": {
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "company": {
+ "type": "string"
+ },
+ "country_code": {
+ "type": "string"
+ },
+ "description": {
+ "type": "string"
+ },
+ "enquiry": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "kind": {
+ "enum": [
+ "company",
+ "service",
+ "place"
+ ],
+ "type": "string"
+ },
+ "location_media": {
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "name": {
+ "type": "string"
+ },
+ "navigation": {
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "opening_information": {
+ "type": "string"
+ },
+ "passport_url": {
+ "type": "string"
+ },
+ "reviewed_at": {
+ "type": "string"
+ },
+ "source": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "company",
+ "country_code",
+ "passport_url",
+ "source",
+ "reviewed_at",
+ "description"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "passport"
+ ],
+ "type": "object"
+ },
+ {
+ "properties": {
+ "error": {
+ "type": "string"
+ },
+ "fallback_tool": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ },
+ "recovery": {
+ "properties": {
+ "automatic_model_retry": {
+ "type": "string"
+ },
+ "catalogue": {
+ "type": "string"
+ },
+ "mode": {
+ "type": "string"
+ },
+ "reason": {
+ "type": "string"
+ },
+ "source_index": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "mode",
+ "automatic_model_retry"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "error"
+ ],
+ "type": "object"
+ }
+ ],
+ "type": "object"
+}get_quick_recommendations1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "anyOf": [
+ {
+ "properties": {
+ "company": {
+ "type": "string"
+ },
+ "company_passport": {
+ "type": "string"
+ },
+ "country_code": {
+ "type": "string"
+ },
+ "guide": {
+ "type": "string"
+ },
+ "intent": {
+ "type": "string"
+ },
+ "location": {
+ "properties": {
+ "address": {
+ "type": "string"
+ },
+ "arrival": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "navigation": {
+ "type": "object"
+ },
+ "photos": {
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "name",
+ "address",
+ "arrival",
+ "navigation",
+ "photos"
+ ],
+ "type": "object"
+ },
+ "mode": {
+ "const": "instant_public_facts"
+ },
+ "next_step": {
+ "properties": {
+ "details_tool": {
+ "type": "string"
+ },
+ "official_enquiry": {
+ "type": "string"
+ },
+ "tailor_tool": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "official_enquiry",
+ "details_tool",
+ "tailor_tool"
+ ],
+ "type": "object"
+ },
+ "scope": {
+ "type": "string"
+ },
+ "services": {
+ "items": {
+ "properties": {
+ "description": {
+ "type": "string"
+ },
+ "enquiry": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "opening_information": {
+ "type": "string"
+ },
+ "reviewed_at": {
+ "type": "string"
+ },
+ "source": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "description",
+ "opening_information",
+ "enquiry",
+ "source",
+ "reviewed_at"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "mode",
+ "intent",
+ "title",
+ "company",
+ "company_passport",
+ "country_code",
+ "guide",
+ "location",
+ "services",
+ "next_step",
+ "scope"
+ ],
+ "type": "object"
+ },
+ {
+ "properties": {
+ "mode": {
+ "const": "instant_public_facts"
+ },
+ "reason": {
+ "type": "string"
+ },
+ "services": {
+ "maxItems": 0,
+ "type": "array"
+ }
+ },
+ "required": [
+ "mode",
+ "services",
+ "reason"
+ ],
+ "type": "object"
+ },
+ {
+ "properties": {
+ "error": {
+ "type": "string"
+ },
+ "fallback_tool": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ },
+ "recovery": {
+ "properties": {
+ "automatic_model_retry": {
+ "type": "string"
+ },
+ "catalogue": {
+ "type": "string"
+ },
+ "mode": {
+ "type": "string"
+ },
+ "reason": {
+ "type": "string"
+ },
+ "source_index": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "mode",
+ "automatic_model_retry"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "error"
+ ],
+ "type": "object"
+ }
+ ],
+ "type": "object"
+}resolve_customer_need1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "anyOf": [
+ {
+ "properties": {
+ "catalogue_revision": {
+ "type": "string"
+ },
+ "clarification_fields": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "consultant": {
+ "type": "string"
+ },
+ "engine": {
+ "type": "string"
+ },
+ "follow_up": {
+ "properties": {
+ "api": {
+ "properties": {
+ "consultant": {
+ "type": "string"
+ },
+ "method": {
+ "const": "POST"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "method",
+ "url",
+ "consultant"
+ ],
+ "type": "object"
+ },
+ "instructions": {
+ "type": "string"
+ },
+ "needed": {
+ "type": "boolean"
+ },
+ "questions": {
+ "items": {
+ "properties": {
+ "field": {
+ "type": "string"
+ },
+ "question": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "field",
+ "question"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "state": {
+ "type": "string"
+ },
+ "tool": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "needed",
+ "questions",
+ "tool",
+ "api",
+ "instructions",
+ "state"
+ ],
+ "type": "object"
+ },
+ "location_relationship": {
+ "type": "string"
+ },
+ "matches": {
+ "items": {
+ "properties": {
+ "passport": {
+ "properties": {
+ "arrival": {
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "company": {
+ "type": "string"
+ },
+ "country_code": {
+ "type": "string"
+ },
+ "description": {
+ "type": "string"
+ },
+ "enquiry": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "kind": {
+ "enum": [
+ "company",
+ "service",
+ "place"
+ ],
+ "type": "string"
+ },
+ "location_media": {
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "name": {
+ "type": "string"
+ },
+ "navigation": {
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "opening_information": {
+ "type": "string"
+ },
+ "passport_url": {
+ "type": "string"
+ },
+ "reviewed_at": {
+ "type": "string"
+ },
+ "source": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "company",
+ "country_code",
+ "passport_url",
+ "source",
+ "reviewed_at",
+ "description"
+ ],
+ "type": "object"
+ },
+ "relevant_facts": {
+ "items": {
+ "properties": {
+ "field": {
+ "type": "string"
+ },
+ "value": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "field",
+ "value"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "role": {
+ "enum": [
+ "primary",
+ "complementary"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "role",
+ "passport",
+ "relevant_facts"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "measurement": {
+ "properties": {
+ "contact_link": {
+ "type": "string"
+ },
+ "meaning": {
+ "type": "string"
+ },
+ "traffic": {
+ "enum": [
+ "internal_evaluation",
+ "external_unverified"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "traffic",
+ "meaning",
+ "contact_link"
+ ],
+ "type": "object"
+ },
+ "mode": {
+ "type": "string"
+ },
+ "next_steps": {
+ "items": {
+ "properties": {
+ "details_tool": {
+ "type": "string"
+ },
+ "enquiry_url": {
+ "type": "string"
+ },
+ "measured_enquiry_url": {
+ "type": "string"
+ },
+ "passport_id": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "passport_id",
+ "details_tool",
+ "enquiry_url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "recovery": {
+ "properties": {
+ "automatic_model_retry": {
+ "type": "string"
+ },
+ "catalogue": {
+ "type": "string"
+ },
+ "mode": {
+ "type": "string"
+ },
+ "reason": {
+ "type": "string"
+ },
+ "source_index": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "mode",
+ "automatic_model_retry"
+ ],
+ "type": "object"
+ },
+ "response_depth": {
+ "enum": [
+ "brief",
+ "full"
+ ],
+ "type": "string"
+ },
+ "scope": {
+ "type": "string"
+ },
+ "topic": {
+ "type": "string"
+ },
+ "visit_groups": {
+ "items": {
+ "properties": {
+ "location_pages": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "name": {
+ "type": "string"
+ },
+ "passport_ids": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "name",
+ "passport_ids",
+ "location_pages"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "engine",
+ "consultant",
+ "mode",
+ "topic",
+ "visit_groups",
+ "location_relationship",
+ "response_depth",
+ "matches",
+ "clarification_fields",
+ "follow_up",
+ "next_steps",
+ "scope"
+ ],
+ "type": "object"
+ },
+ {
+ "properties": {
+ "error": {
+ "type": "string"
+ },
+ "fallback_tool": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ },
+ "recovery": {
+ "properties": {
+ "automatic_model_retry": {
+ "type": "string"
+ },
+ "catalogue": {
+ "type": "string"
+ },
+ "mode": {
+ "type": "string"
+ },
+ "reason": {
+ "type": "string"
+ },
+ "source_index": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "mode",
+ "automatic_model_retry"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "error"
+ ],
+ "type": "object"
+ }
+ ],
+ "type": "object"
+}search_passports1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "anyOf": [
+ {
+ "properties": {
+ "coverage": {
+ "properties": {
+ "companies": {
+ "items": {
+ "properties": {
+ "country_code": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "passport_id": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "country_code",
+ "passport_id"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "company_records": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "country_codes": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "place_records": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "scope": {
+ "type": "string"
+ },
+ "searchable_records": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "service_records": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "withheld_unverified_records": {
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "companies",
+ "country_codes",
+ "searchable_records",
+ "company_records",
+ "service_records",
+ "place_records",
+ "withheld_unverified_records",
+ "scope"
+ ],
+ "type": "object"
+ },
+ "limitations": {
+ "type": "string"
+ },
+ "matches": {
+ "items": {
+ "properties": {
+ "arrival": {
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "company": {
+ "type": "string"
+ },
+ "country_code": {
+ "type": "string"
+ },
+ "description": {
+ "type": "string"
+ },
+ "enquiry": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "kind": {
+ "enum": [
+ "company",
+ "service",
+ "place"
+ ],
+ "type": "string"
+ },
+ "location_media": {
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "name": {
+ "type": "string"
+ },
+ "navigation": {
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "opening_information": {
+ "type": "string"
+ },
+ "passport_url": {
+ "type": "string"
+ },
+ "reviewed_at": {
+ "type": "string"
+ },
+ "source": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "company",
+ "country_code",
+ "passport_url",
+ "source",
+ "reviewed_at",
+ "description"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "total_matches": {
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "matches",
+ "total_matches",
+ "coverage",
+ "limitations"
+ ],
+ "type": "object"
+ },
+ {
+ "properties": {
+ "error": {
+ "type": "string"
+ },
+ "fallback_tool": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ },
+ "recovery": {
+ "properties": {
+ "automatic_model_retry": {
+ "type": "string"
+ },
+ "catalogue": {
+ "type": "string"
+ },
+ "mode": {
+ "type": "string"
+ },
+ "reason": {
+ "type": "string"
+ },
+ "source_index": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "mode",
+ "automatic_model_retry"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "error"
+ ],
+ "type": "object"
+ }
+ ],
+ "type": "object"
+}get_quick_recommendations1 field changedInput schema / properties / intent / enumPrevious value: -[
- "staff_party_kordin",
- "halloween_kordin",
- "indoor_st_julians"
-]New value: +[
+ "leisure_kordin",
+ "staff_party_kordin",
+ "halloween_kordin",
+ "indoor_st_julians"
+]catalogue_coverageconsult_activitiesconsult_eventsconsult_hospitalityconsult_venuesget_passportget_quick_recommendationsresolve_customer_needsearch_passportsYour personal AI travel concierge — flights, hotels, 116M+ POIs, visas, weather & more
Multilingual travel guides, gear picks and booking links for AI travel agents.
Travel notebook your AI agent writes from your photos and remarks over MCP.
Mediterranean marine, nautical, sailing: forecasts, tides, sea routes, anchorages, POIs for AI.
Add one secure layer between your agents and this server.
