Extralingo

create_booking

Submit an unpaid booking for a bookings_live school (same path as the website Book now flow). The school still confirms availability; Extralingo emails the student; down payment is due within 5 days of school confirmation via Extralingo only. Never tell the user they are confirmed or paid. Requires OAuth bookings scope (Bearer token). Optional idempotency_key replays the same payload within 24 hours.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`phone`	No	Student phone number (required).
`contact`	No	Optional first_name, last_name, phone. Email always comes from the verified account; contact.email must match or be omitted.
`trip_id`	No	Optional trip_id from save_trip linking this booking to a draft.
`currency`	No	ISO 4217 currency for prices in this call. Usually EUR.	EUR
`school_id`	No	Craft CMS school entry id from search_language_schools hits (field school_id). Not the CRM UUID.
`phoneCountry`	No	ISO 3166-1 alpha-2 country for the phone (e.g. NL).
`configuration`	No	Same shape as the Extralingo school-page configurator: startDate (YYYY-MM-DD), students[] with courseId, weeks, optional accommodationGroupId, mealType, extras.
`termsAccepted`	No	Must be true when not using OAuth (OAuth grants record acceptance).
`idempotencyKey`	No	Optional alias of idempotency_key.
`studentDetails`	No	Per-student details aligned with configuration.students (names, dates of birth, etc.).
`idempotency_key`	No	Optional. Same key + same payload within 24 hours replays the original response; conflicting payload returns validation_failed.
`privacyAccepted`	No	Must be true when not using OAuth.
`specialRequests`	No	Free-text notes for the school.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`booking`	No
`success`	Yes
`studentMessage`	No
`agent_must_tell_the_user`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed21 schema fields changedOct 3, 2026

removedInput schema / properties / auth_token
```
Removed value: -{
-  "type": "string"
-}
```
addedInput schema / properties / configuration / additionalProperties
```
Added value: +true
```

addedInput schema / properties / configuration / description

Added value: +"Same shape as the Extralingo school-page configurator: startDate (YYYY-MM-DD), students[] with courseId, weeks, optional accommodationGroupId, mealType, extras."

addedInput schema / properties / configuration / properties

Added value: +{
+  "accommodationGroupId": {
+    "description": "Accommodation group id from list_accommodations (optional).",
+    "type": "string"
+  },
+  "mealType": {
+    "description": "Meal plan key when accommodation is selected.",
+    "type": "string"
+  },
+  "startDate": {
+    "description": "Course start calendar date (YYYY-MM-DD). Typically a Monday from list_starting_dates.",
+    "examples": [
+      "2026-09-07"
+    ],
+    "type": "string"
+  },
+  "students": {
+    "description": "One object per traveller. courseId comes from list_courses.",
+    "items": {
+      "additionalProperties": true,
+      "properties": {
+        "courseId": {
+          "description": "Course product id from list_courses for this school.",
+          "type": "string"
+        },
+        "weeks": {
+          "description": "Course duration in weeks.",
+          "minimum": 1,
+          "type": "integer"
+        }
+      },
+      "type": "object"
+    },
+    "type": "array"
+  }
+}

addedInput schema / properties / contact / additionalProperties
```
Added value: +true
```

changedInput schema / properties / contact / description

Previous value: -"Optional first_name, last_name, phone. Email always comes from the verified account. A different contact.email is rejected."New value: +"Optional first_name, last_name, phone. Email always comes from the verified account; contact.email must match or be omitted."

addedInput schema / properties / currency / description

Added value: +"ISO 4217 currency for prices in this call. Usually EUR."

addedInput schema / properties / currency / examples
```
Added value: +[
+  "EUR"
+]
```

changedInput schema / properties / idempotencyKey / description

Previous value: -"Optional. Alias of idempotency_key."New value: +"Optional alias of idempotency_key."

changedInput schema / properties / idempotency_key / description

Previous value: -"Optional. Same key + same payload within 24 hours replays the original response. A different payload with the same key fails."New value: +"Optional. Same key + same payload within 24 hours replays the original response; conflicting payload returns validation_failed."

addedInput schema / properties / phone / description
```
Added value: +"Student phone number (required)."
```

changedInput schema / properties / phoneCountry / description

Previous value: -"ISO2, e.g. NL"New value: +"ISO 3166-1 alpha-2 country for the phone (e.g. NL)."

changedInput schema / properties / privacyAccepted / description

Previous value: -"Only needed for legacy auth_token sessions. OAuth grants already include privacy acceptance."New value: +"Must be true when not using OAuth."

addedInput schema / properties / school_id / description

Added value: +"Craft CMS school entry id from search_language_schools hits (field school_id). Not the CRM UUID."

addedInput schema / properties / school_id / examples
```
Added value: +[
+  12345
+]
```
addedInput schema / properties / specialRequests / description
```
Added value: +"Free-text notes for the school."
```

addedInput schema / properties / studentDetails / description

Added value: +"Per-student details aligned with configuration.students (names, dates of birth, etc.)."

addedInput schema / properties / studentDetails / items

Added value: +{
+  "additionalProperties": true,
+  "type": "object"
+}

changedInput schema / properties / termsAccepted / description

Previous value: -"Only needed for legacy auth_token sessions. OAuth grants already include terms acceptance."New value: +"Must be true when not using OAuth (OAuth grants record acceptance)."

addedInput schema / properties / trip_id / description

Added value: +"Optional trip_id from save_trip linking this booking to a draft."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "agent_must_tell_the_user": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "booking": {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    "studentMessage": {
+      "type": "string"
+    },
+    "success": {
+      "const": true
+    }
+  },
+  "required": [
+    "success"
+  ],
+  "type": "object"
+}

Changed3 schema fields changedOct 3, 2026

changedInput schema / properties / idempotencyKey / description

Previous value: -"Required. Reuse only to retry the same payload."New value: +"Optional. Alias of idempotency_key."

addedInput schema / properties / idempotency_key

Added value: +{
+  "description": "Optional. Same key + same payload within 24 hours replays the original response. A different payload with the same key fails.",
+  "type": "string"
+}

removedInput schema / required

Removed value: -[
-  "idempotencyKey"
-]

First observedOct 3, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the annotations: it discloses that the booking is unpaid, that the school must still confirm availability, the email/down-payment follow-up with a 5-day window, the OAuth scope requirement, and a critical guardrail ('Never tell the user they are confirmed or paid'). It also explains the idempotency-key replay window, which is meaningful behavior not captured by the flat idempotentHint flag.

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?

Dense but front-loaded: the action and path lead, followed by workflow, constraints, and auth in priority order. Every sentence carries operational weight, though the run-on delivery of several constraints costs a point.

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?

For a complex, nested, 13-parameter mutation with an output schema, the description covers the workflow, auth requirement, idempotency semantics, and user-facing guardrails. Nothing essential for correct invocation is missing.

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 100%, so the baseline is 3, but the description adds real semantic value by explaining the idempotency_key replay/conflict behavior and framing configuration as matching the school-page configurator, helping the agent assemble the nested payload.

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?

Names a specific verb ('Submit an unpaid booking') plus resource and narrows scope to bookings_live schools, distinguishing it from siblings like save_trip, request_quote, and email_trip. An agent knows immediately this is the booking-submission endpoint rather than a draft or quote path.

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?

States the operative context ('bookings_live school', 'same path as the website Book now flow') and required auth scope, which routes the agent correctly. It stops short of explicitly naming when NOT to use it or which sibling to prefer for non-live schools or quote-first flows.

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

All Extralingo tools Inspect

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?