Skip to main content
Glama

Villiers Charter

get_confirmation_status

Read-onlyIdempotent

Check the outcome of a previous request_jet_confirmation call — has Villiers sent confirmed options yet, and where does the trip stand now (still being sourced / options sent / booked / closed with no booking). Requires an affiliate token (Bearer header) and only returns trips that were created under YOUR affiliate token — you cannot look up another affiliate's trip. Poll this instead of expecting a webhook.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
trip_idYesThe trip_id returned by request_jet_confirmation (REQUIRED)

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
statusNoVilliers' internal status string, for reference
messageNoHuman-readable summary to relay to the user
outcomeNoCoarse bucket: in_progress | options_sent | booked | closed_no_booking
trip_idNo
client_referenceNoThe reference you supplied at request time, if any

TDQS

A4.7/5.0
Behavior5/5

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

Beyond annotations (readOnlyHint, idempotentHint), the description adds critical behavioral details: requires Bearer header, scoped to own affiliate token, and intended for polling. No contradictions with 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?

Two sentences, no redundant words, front-loaded with purpose. Every sentence adds value.

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

Completeness5/5

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

Given the simple tool (one param, read-only, with output schema), the description covers all needed context: purpose, usage, auth, scope, and polling recommendation.

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?

Only one parameter with 100% schema coverage; schema description already explains it's the trip_id from request_jet_confirmation. Description adds no further semantic value, so baseline 3 is appropriate.

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?

Clearly states it checks the outcome of a previous request_jet_confirmation call, specifying what it checks (confirmed options, trip status) and distinguishing itself from sibling tools like get_jet_estimate or request_jet_confirmation.

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?

Explicitly tells when to use (polling instead of webhook), prerequisites (requires affiliate token), and limitations (only returns trips under your token, cannot look up others).

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.5/5.0
Disambiguation5/5

Each tool serves a distinct, clearly defined purpose: estimates, confirmed pricing requests, status checks, and empty-leg searches. There is no overlap or ambiguity between tool functions.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (get_, request_, search_), making it easy to predict tool behavior from the name alone.

Tool Count5/5

Four tools precisely cover the core capabilities needed for a private jet charter assistant: estimation, confirmation, status tracking, and empty-leg deals. No tool feels redundant or missing.

Completeness4/5

The set covers the primary workflow (estimate → request confirmation → check status) and adds empty-leg search. However, the actual booking is handled externally via email, and there is no tool to modify or cancel requests.

Resources