voidjet empty legs

Server Details

Search empty-leg private jet offers; prepare inquiries and alerts the user confirms by email.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 100.0% over 22 days
Last Tested: 2026-10-31 00:04
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.2/5.0

Scored 2026-10-20 12:30 across 6 tools

Disambiguation4/5

Each tool has a distinct purpose: search, get-by-ref, alert creation, inquiry, charter quote, and unmet-need reporting. The two 'request_*' tools (charter_quote and inquiry) and create_flight_alert share a similar email/link flow and could be momentarily confusable, but descriptions clearly separate charter (paid partner) from empty-leg inquiry and from alerts.

Naming Consistency5/5

All six tools follow a clean verb_noun snake_case pattern: create_flight_alert, get_empty_leg, report_unmet_need, request_charter_quote, request_inquiry, search_empty_legs. No deviations or mixed conventions.

Tool Count5/5

Six tools map neatly onto the domain's distinct actions (search, detail, alert, inquire, charter, feedback). Nothing feels padded or missing at the count level.

Completeness4/5

The surface covers the core empty-leg lifecycle: discovery (search_empty_legs), inspection (get_empty_leg), and action (alerts, inquiries, charter, unmet needs). Minor gaps exist around managing/cancelling alerts or a direct booking confirmation path, but agents can work around them via the inquiry flow.

Available Tools

6 tools

create_flight_alertSet up a flight alertA

Idempotent

Inspect

Sets up an email alert for new empty legs on a route or from a place, for when the user asks to be notified and gives their email. voidjet emails a confirmation link; the alert becomes active only after the user clicks it (double opt-in, valid 7 days). Needs origin or destination; dates, passengers and budget are optional.

Name	Required	Description	Default
`email`	Yes	The user's email address.
`locale`	No		en
`origin`	No	Departure city, IATA/ICAO code, country, US state, region or area.
`date_to`	No
`date_from`	No
`passengers`	No
`destination`	No	Arrival city, IATA/ICAO code, country, US state, region or area.
`max_price_eur`	No
`aircraft_class`	No	Only these aircraft classes. Offers without a known aircraft type are excluded.

Output Schema

Name	Required	Description
`status`	Yes
`message`	Yes

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), so the description's value is in the workflow detail it adds: voidjet sends a confirmation link and the alert is only active after the user clicks it, with a 7-day opt-in window. That double opt-in requirement is meaningful behavior an agent must convey to the user and is not captured by annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences with the purpose first, then the confirmation workflow, then the parameter constraints. Every sentence carries new information and nothing is repeated from the title or schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

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 no explanation, and the description covers the trigger, the opt-in lifecycle and the key parameter constraint. The gaps (locale and aircraft_class semantics, e.g. that offers with unknown aircraft types are excluded) are minor but real for a 9-parameter tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 44%, so the description must compensate, and it does partially: it adds the cross-field constraint 'needs origin or destination' that the schema cannot express (only email is required) and labels dates, passengers and budget as optional. It leaves locale and aircraft_class unmentioned, which is why it is not a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Sets up an email alert for new empty legs') plus the scope (a route or from a place), which cleanly separates it from the read-oriented siblings search_empty_legs and get_empty_leg. An agent can identify the operation without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit trigger: 'for when the user asks to be notified and gives their email,' which tells the agent when this tool applies. It does not name the alternative tools (e.g. search_empty_legs) or state when not to use it, so it stops short of full routing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_empty_legGet one empty legA

Read-onlyIdempotent

Inspect

Current details of one offer by the ref returned by search_empty_legs. available=false means the offer is no longer listed.

Name	Required	Description	Default
`ref`	Yes	ref exactly as returned by search_empty_legs.
`locale`	No		en

Output Schema

Name	Required	Description
`notes`	No
`flight`	Yes
`data_as_of`	Yes

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuinely useful context beyond them: available=false signals the offer is no longer listed, which tells the agent how to interpret a stale result. It does not mention error behavior for an invalid or expired ref.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the core purpose followed by the one behavioral caveat. Nothing is wasted and there is no redundancy with the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-value detail is not required, and the description supplies the key status-flag semantics for available. The only gap is the undocumented locale parameter, which leaves a small blind spot for a two-parameter tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 50%: ref is documented in the schema (and reinforced in the description), but locale has no description anywhere, only an en/de enum. The description thus adds no new parameter meaning and leaves the language selector's effect unexplained. Baseline of 3 is appropriate given the partial coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (get) and resource (one empty-leg offer) and identifies the exact identifier source: the ref returned by search_empty_legs. This cleanly separates it from search_empty_legs, which finds offers, and from the other siblings, which are all creation/request flows.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description effectively states the prerequisite workflow: you get a ref from search_empty_legs, then call this tool to refresh that offer's details. It does not explicitly say when not to use it or what to do if the ref is stale, but the context is clear enough to route correctly.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

report_unmet_needReport an unmet needAInspect

Records a need voidjet cannot serve, for when the user wants voidjet to know about it: e.g. no offer on the route, a return flight, pets, instant booking. Takes 1-5 categories and optional route, dates, passengers and budget; no personal data. Helps voidjet decide what to add.

Name	Required	Description	Default
`origin`	No
`date_to`	No
`date_from`	No
`categories`	Yes
`passengers`	No
`destination`	No
`aircraft_class`	No
`max_budget_eur`	No

Output Schema

Name	Required	Description
`message`	Yes
`recorded`	Yes

TDQS

A3.9/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare a non-read-only, non-destructive, non-idempotent write, and the description is consistent with that ('records', 'helps voidjet decide what to add'). It adds genuinely new behavioral context beyond the annotations: the 'no personal data' privacy guarantee and the 1-5 category cap. Does not describe durability or visibility of the submission, which is why it is not a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action, then constraints, then benefit — efficient for the amount of ground covered. Minor redundancy: 'for when the user wants voidjet to know about it' and 'Helps voidjet decide what to add' restate the same rationale.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return details need not be explained, and the description covers purpose, trigger, input shape, and privacy. The only real gap is the unmentioned aircraft_class parameter and any indication of what happens after the report is filed (only loosely implied by 'Helps voidjet decide what to add').

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across 8 parameters, so the description must carry the load. It names categories (1-5), route, dates, passengers and budget, but omits aircraft_class entirely and gives no format or range hints for the fields it does name. Partial compensation against a zero-coverage schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Records a need voidjet cannot serve') with concrete examples of qualifying situations (no offer on route, return flight, pets, instant booking). This separates it from the retrieval/quote siblings like search_empty_legs or request_charter_quote, though it never names any sibling explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a clear triggering condition ('for when the user wants voidjet to know about it') plus enumerated scenarios that map to the enum categories. It does not state when NOT to use it or point to an alternative such as request_inquiry or create_flight_alert, so the agent must infer the boundary.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

request_charter_quoteRequest a charter quote (partner Villiers)A

Idempotent

Inspect

Requests confirmed charter prices from partner Villiers for the route of a charter_alternative, for when the user has seen its price range, asked for confirmed prices and given their email. NOT an empty leg: a regular charter and a paid partner offer. voidjet emails the user a link; Villiers receives the request only after the user sends the form on voidjet.io within 48 hours, then emails confirmed options directly. name, phone and message are optional and come from the user.

Name	Required	Description	Default
`name`	No
`email`	Yes	The user's email address.
`phone`	No
`locale`	No		en
`origin`	Yes	origin_code from charter_alternative.
`message`	No
`flexible`	No
`passengers`	Yes
`destination`	Yes	destination_code from charter_alternative.
`departure_date`	Yes

Output Schema

Name	Required	Description
`status`	Yes
`message`	Yes
`expires_at`	Yes

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=false, openWorldHint=true and idempotentHint=true, but the description adds substantial side-effect context: a two-step flow where voidjet emails the user a link, Villiers only receives the request after the user submits the form within 48 hours, and confirmed options arrive by email. That is meaningful disclosure beyond the annotations. It stops short of covering failure modes or what the tool returns on submission, so a 4 rather than a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and preconditions are front-loaded and no sentence is filler; the flow explanation earns its place. However, several clauses are packed into run-on sentences, making the middle section denser than it needs to be.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

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 described, and the description fully covers the asynchronous request flow and its timing constraint. The remaining gap is semantic coverage for the undocumented parameters (locale, flexible, passengers, departure_date) on a 10-parameter tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 30% across 10 parameters. The description clarifies that name, phone and message are optional and come from the user, and ties origin/destination to the charter_alternative route, but leaves locale, flexible, passengers and departure_date unexplained in both schema and description. Partial compensation only.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Requests confirmed charter prices from partner Villiers for the route of a charter_alternative') and explicitly distinguishes itself from the empty-leg siblings with 'NOT an empty leg: a regular charter and a paid partner offer.' An agent can identify the operation and its scope without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit precondition set (user has seen the price range, asked for confirmed prices, and supplied their email) and an explicit exclusion (not an empty leg, which routes the agent toward get_empty_leg/search_empty_legs). Both when-to-use and when-not-to-use are stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

request_inquiryPrepare an inquiryA

Idempotent

Inspect

Prepares an inquiry for one offer, for when the user has asked to inquire and given their email. voidjet emails the user a link; nothing is forwarded to the provider until the user opens it and sends the pre-filled form on voidjet.io within 48 hours. name, phone and message are optional, come from the user and only pre-fill the form. Prices are indicative.

Name	Required	Description	Default
`ref`	Yes	ref exactly as returned by search_empty_legs.
`name`	No
`email`	Yes	The user's email address.
`phone`	No
`locale`	No		en
`message`	No
`flexible`	No
`passengers`	Yes

Output Schema

Name	Required	Description
`status`	Yes
`message`	Yes
`expires_at`	Yes

TDQS

A4.1/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the annotations by disclosing the full async workflow: voidjet emails a link, nothing reaches the provider until the user opens it within 48 hours, and prices are indicative. The annotations cover safety/idempotency, and the description layers on the real behavioral mechanics an agent needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the purpose and workflow, and every sentence adds distinct information. It is dense and slightly run-on, but there is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values need not be explained, and the description fully captures the inquiry workflow and the nature of the optional fields. The remaining gap is the undocumented required/behavioral parameters (ref, passengers, flexible).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 25%, so the description must carry weight. It clarifies that name, phone and message are optional, user-sourced, and only pre-fill the form — useful meaning — but leaves ref, passengers, locale and flexible unaddressed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Prepares an inquiry for one offer') and scopes it to a single offer. It reads clearly against siblings like request_charter_quote and create_flight_alert, though it doesn't explicitly name any of them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a concrete precondition for use: 'for when the user has asked to inquire and given their email.' This is a clear triggering condition, but it names no alternatives or when-not cases against the sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_empty_legsSearch empty legsA

Read-onlyIdempotent

Inspect

Finds current empty-leg flights by origin and/or destination (city, IATA/ICAO code, country, US state, region or area such as Greek Islands), dates, passengers, budget and aircraft class. Returns up to 20 offers with route, date, aircraft, seats, indicative price, a voidjet link and a pre-filled inquiry link; provider names are not included. When more offers match, refine summarises all matches (frequent destinations, date span, prices). With no match, charter_alternative may contain a regular charter via partner Villiers: NOT an empty leg, and a paid partner offer.

Name	Required	Description	Default
`sort`	No		date
`limit`	No
`locale`	No		en
`offset`	No
`origin`	No	Departure city or IATA/ICAO code (e.g. Nice, NCE), or a country, US state, region or area (e.g. Greece, Florida, Caribbean, Greek Islands).
`date_to`	No	Latest departure date, at most 120 days after date_from.
`date_from`	No	Earliest departure date (YYYY-MM-DD), default today.
`passengers`	No
`destination`	No	Arrival city, IATA/ICAO code, country, US state, region or area.
`max_price_eur`	No	Maximum price in EUR for the whole aircraft.
`aircraft_class`	No	Only these aircraft classes. Offers without a known aircraft type are excluded.

Output Schema

Name	Required	Description
`limit`	Yes
`notes`	No
`total`	Yes	Number of matching offers in total.
`offset`	Yes
`refine`	No	Only when more offers match than returned: frequent destinations, date span and price range of all matches, to suggest how to narrow.
`results`	Yes
`data_as_of`	Yes
`resolved_to`	No
`resolved_from`	No
`charter_alternative`	No	Only when no empty leg matches: a regular charter via a partner. NOT an empty leg; a paid partner offer.

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds genuinely useful disclosure beyond that – provider names are withheld, up to 20 offers cap, and the no-match fallback is explicitly flagged as NOT an empty leg and a paid partner offer via Villiers. That last point is important behavioural context for the caller.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the purpose, then the return shape, then the two outcome branches – a sensible order with no filler sentences. It is dense (one long paragraph with semicolon-chained clauses) but every clause carries information about results or fallbacks rather than restating the name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 11-parameter, optional-only search tool with an output schema, the definition covers purpose, return composition, result cap and the no-match path, which is what an agent most needs. It does not explain how limit/offset interact with the stated 20-offer cap or what locale changes, leaving a small gap in paging behaviour.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 55% schema coverage and 11 parameters, the description compensates by naming the searchable dimensions (origin/destination geography forms, dates, passengers, budget/cap price, aircraft class) and clarifying that aircraft_class filtering excludes offers with unknown type. It adds little on sort, limit, offset and locale, which govern paging and result ordering.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (finds/searches) and resource (current empty-leg flights) plus the full set of search dimensions (origin/destination including city, IATA/ICAO, country, state, region, area, dates, passengers, budget, aircraft class). It routes the agent clearly versus sibling get_empty_leg by describing list/refine semantics and names the no-match fallback (charter_alternative) so the agent knows this is not a charter-quote tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear usage context: use it to search current empty legs with flexible geography, and explains the two outcome branches – refine summarises when more matches exist, charter_alternative appears when nothing matches. It never explicitly says when NOT to use it versus get_empty_leg or request_charter_quote, so selection between siblings is still partly inferred.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

2 tool updatesOct 20, 2026

Changedcreate_flight_alert2 fields changed

changedInput schema / properties / destination / description

Previous value: -"Arrival city or IATA/ICAO code."New value: +"Arrival city, IATA/ICAO code, country, US state, region or area."

changedInput schema / properties / origin / description

Previous value: -"Departure city or IATA/ICAO code."New value: +"Departure city, IATA/ICAO code, country, US state, region or area."

Changedsearch_empty_legs2 fields changed

changedInput schema / properties / destination / description

Previous value: -"Arrival city or IATA/ICAO code."New value: +"Arrival city, IATA/ICAO code, country, US state, region or area."

changedInput schema / properties / origin / description

Previous value: -"Departure city or IATA/ICAO code, e.g. Nice or NCE."New value: +"Departure city or IATA/ICAO code (e.g. Nice, NCE), or a country, US state, region or area (e.g. Greece, Florida, Caribbean, Greek Islands)."

2 tool updatesOct 20, 2026

Changedcreate_flight_alert1 field changed

addedInput schema / properties / aircraft_class

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "enum": [
+          "vlj",
+          "light",
+          "midsize",
+          "super_midsize",
+          "heavy",
+          "ultra",
+          "turboprop",
+          "airliner_vip"
+        ],
+        "type": "string"
+      },
+      "maxItems": 8,
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Only these aircraft classes. Offers without a known aircraft type are excluded.",
+  "title": "Aircraft Class"
+}

Changedsearch_empty_legs1 field changed

addedInput schema / properties / aircraft_class

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "enum": [
+          "vlj",
+          "light",
+          "midsize",
+          "super_midsize",
+          "heavy",
+          "ultra",
+          "turboprop",
+          "airliner_vip"
+        ],
+        "type": "string"
+      },
+      "maxItems": 8,
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Only these aircraft classes. Offers without a known aircraft type are excluded.",
+  "title": "Aircraft Class"
+}

1 tool updateOct 11, 2026

Changedsearch_empty_legs3 fields changed

changedOutput schema / $defs / CharterAlternative / properties / disclosure / default

Previous value: -"Partner offer by Villiers; voidjet receives a commission if a booking results."New value: +"Paid partner offer by Villiers; voidjet receives a commission if a booking results."

changedOutput schema / $defs / CharterAlternative / properties / notice / default

Previous value: -"NOT AN EMPTY LEG. voidjet found no empty leg for this search. This is a regular private charter of the whole aircraft by voidjet partner Villiers, priced as a full charter and usually far above empty-leg prices. Say clearly to the user that this is not an empty leg before showing it. The ranges are indicative estimates from Villiers, not offers; for confirmed prices the user opens url and requests a quote on villiers.ai."New value: +"NOT AN EMPTY LEG. voidjet found no empty leg for this search. This is a regular private charter of the whole aircraft by voidjet partner Villiers, priced as a full charter and usually far above empty-leg prices. The ranges are indicative estimates from Villiers, not offers; confirmed prices are available on request on villiers.ai via url."

changedOutput schema / properties / charter_alternative / description

Previous value: -"Only when no empty leg matches: a regular charter via a partner. NOT an empty leg; tell the user so."New value: +"Only when no empty leg matches: a regular charter via a partner. NOT an empty leg; a paid partner offer."

1 tool updateOct 11, 2026

Changedsearch_empty_legs1 field changed

changedOutput schema / $defs / CharterAlternative / properties / disclosure / default

Previous value: -"Partner offer by Villiers; voidjet receives a commission if a booking results. Keep this marking when showing the offer."New value: +"Partner offer by Villiers; voidjet receives a commission if a booking results."

3 tool updatesOct 10, 2026
- Addedcreate_flight_alert
- Addedrequest_charter_quote
- Addedrequest_inquiry

1 tool updateOct 10, 2026

Changedsearch_empty_legs3 fields changed

addedOutput schema / $defs / RefineOption

Added value: +{
+  "properties": {
+    "city": {
+      "title": "City",
+      "type": "string"
+    },
+    "count": {
+      "title": "Count",
+      "type": "integer"
+    }
+  },
+  "required": [
+    "city",
+    "count"
+  ],
+  "title": "RefineOption",
+  "type": "object"
+}

addedOutput schema / $defs / Refinement

Added value: +{
+  "description": "Eingrenzungshilfe, wenn mehr passt als geliefert wird (10.10.2026, Robin):\nDer Assistent soll nicht pauschal \"grenzen Sie ein\" sagen, sondern konkret\nfragen koennen - \"Nizza (12), Genf (8) oder lieber ab Freitag?\".",
+  "properties": {
+    "destinations": {
+      "default": [],
+      "description": "Most frequent destinations among all matches.",
+      "items": {
+        "$ref": "#/$defs/RefineOption"
+      },
+      "title": "Destinations",
+      "type": "array"
+    },
+    "earliest_date": {
+      "anyOf": [
+        {
+          "format": "date",
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null,
+      "title": "Earliest Date"
+    },
+    "latest_date": {
+      "anyOf": [
+        {
+          "format": "date",
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null,
+      "title": "Latest Date"
+    },
+    "origins": {
+      "default": [],
+      "description": "Most frequent origins among all matches (when no origin was given).",
+      "items": {
+        "$ref": "#/$defs/RefineOption"
+      },
+      "title": "Origins",
+      "type": "array"
+    },
+    "price_max_eur": {
+      "anyOf": [
+        {
+          "type": "integer"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null,
+      "title": "Price Max Eur"
+    },
+    "price_min_eur": {
+      "anyOf": [
+        {
+          "type": "integer"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null,
+      "title": "Price Min Eur"
+    }
+  },
+  "title": "Refinement",
+  "type": "object"
+}

addedOutput schema / properties / refine

Added value: +{
+  "anyOf": [
+    {
+      "$ref": "#/$defs/Refinement"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Only when more offers match than returned: frequent destinations, date span and price range of all matches, to suggest how to narrow."
+}

3 tool updatesOct 9, 2026
- First observedget_empty_leg
- First observedreport_unmet_need
- First observedsearch_empty_legs

Related MCP Connectors

SkyAccess A
com.skyaccess
Search 5,000+ live empty leg flights, get charter estimates and booking links. Free, no API key.
Travel & Transportation
612
https://mcp.skyaccess.com/mcp
Altivo Jets A
io.github.prateek7779-maker
Live private jet empty legs, charter estimates in 12 countries and quote requests.
Travel & Transportation E-commerce & Retail
91
https://altivojets.com/mcp/
Jetblanc Private-Flight Brief Intake BOAuth
com.jetblanc
Validate and submit authorised Asia private-flight briefs. Human-reviewed sourcing, not booking.
Travel & Transportation
1
https://jetblanc.com/api/mcp
BEACON by Owner Connect A
com.virtualhangar.owners
Ask about a private aircraft: approximate charter costs, trip requests and buyer inquiries.
Travel & Transportation CRM Finance
61
https://owners.virtualhangar.com/mcp/beacon

Related MCP Servers

MCP Job Search
Web Scraping RAG Systems App Automation
adamd9
F
license
Not graded
quality
D
maintenance
Helps users find suitable LinkedIn job opportunities by automatically scraping listings, analyzing compatibility with user profiles using AI, and sending custom match reports via email.
Updated a year ago (2025-08-02 01:42 UTC)
1
-
Job Outreach MCP Server
Email Web Scraping AI & Machine Learning
ajayranwa
F
license
A
quality
D
maintenance
Automates job outreach by finding companies, discovering contacts, generating personalized emails with AI, and tracking campaigns.
Updated 10 months ago (2026-01-04 18:32 UTC)
9
-
olostep-mcp
Web Scraping Browser Automation Search
olostep
A
license
B
quality
D
maintenance
Searching google, individual websites and scraping their content. Fast and cost-effective. ⚡️
Updated 2 days ago (2026-10-28 14:06 UTC)
9
955 npm
25
MIT
OpenSDR
CRM App Automation Autonomous Agents
arif-js
A
license
A
quality
A
maintenance
Find prospects, verify their emails, spot buying signals, draft grounded outreach and stage campaigns, all from a conversation with your AI assistant, using your own API keys.
Updated 11 days ago (2026-10-20 11:36 UTC)
17
0
MIT

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?