GeoArm Taxi — Tbilisi ⇄ Yerevan rides

Request a booking

create_booking

Sends a booking request for a ride between Tbilisi and Yerevan (a seat, or a whole vehicle) for the passenger. A booking is a request: it is NOT confirmed until a GeoArm Taxi dispatcher contacts the passenger to confirm it. Use the values from get_prices_and_schedule (point, time, car, currency), the passenger's real name and phone, and get the passenger's yes to the price first. Payment is in cash to the driver. Returns the booking number, what was booked, the total, and a status_token for get_booking_status.

Input Schema

Name	Required	Description	Default
`car`	Yes	`sprinter` = a seat on the scheduled minibus (the default choice)
`dir`	Yes	`tbs-evn` = Tbilisi → Yerevan, `evn-tbs` = Yerevan → Tbilisi
`lat`	No
`lng`	No
`pax`	Yes	Passengers; at most `types[car].max`
`date`	Yes	YYYY-MM-DD, today or later (Tbilisi date), at most a year ahead
`lang`	No	The language we should use with the passenger (an unknown value is treated as `en`)	en
`name`	Yes	The passenger's name
`time`	Yes	One of `schedule[dir]` from /api/config, or `other` for a time outside the timetable (whole vehicle; the dispatcher sets the price)
`agent`	No	If an AI agent makes the booking: its name (e.g. `ChatGPT`, `Claude`). Shown to the dispatcher. When you leave it out, your MCP client's name is used.
`notes`	No	Flight number, luggage, a child seat request and the like (longer text is cut to 1000 characters)
`phone`	Yes	The passenger's phone in international format, e.g. +995 5xx xx xx xx
`point`	Yes	A departure point id from `points[dir]` in /api/config, or `@addr` for pick-up from an address (extra fee, confirmed by the dispatcher)
`whole`	No	`true` = the whole vehicle for this party at a timetable time: the total is `types[car].whole[currency]` from /api/config (not per passenger). Only when that price exists for the chosen currency; `pax` still says how many travel
`address`	No	Required with `point: "@addr"` unless `lat`/`lng` are given
`currency`	Yes	One of `currencies` from /api/config; the price is taken from the server

Output Schema

Name	Required	Description
`number`	No	The booking number
`status`	No
`booking`	No	What was booked, as the server understood it
`message`	No	A sentence for the passenger, in `lang`
`feedback`	No	Optional, after you finish: where you may tell us in a few lines how this went (POST, see /api/agent-feedback). Never include the passenger's personal data.
`telegram`	No	A link the passenger can open to get the confirmation in Telegram
`confirmed`	No	Always false here: a dispatcher confirms later
`status_url`	No
`status_token`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 9, 2026

addedOutput schema / properties / feedback

Added value: +{
+  "description": "Optional, after you finish: where you may tell us in a few lines how this went (POST, see /api/agent-feedback). Never include the passenger's personal data.",
+  "format": "uri",
+  "type": "string"
+}

Changed2 schema fields changedOct 7, 2026

addedInput schema / properties / whole

Added value: +{
+  "default": false,
+  "description": "`true` = the whole vehicle for this party at a timetable time: the total is `types[car].whole[currency]` from /api/config (not per passenger). Only when that price exists for the chosen currency; `pax` still says how many travel",
+  "type": "boolean"
+}

addedOutput schema / properties / booking / properties / whole

Added value: +{
+  "description": "True when the whole vehicle was booked",
+  "type": "boolean"
+}

First observedOct 6, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Adds real context beyond the annotations: the booking is only a request, unconfirmed until a dispatcher contacts the passenger, and payment is cash to the driver. The annotations already declare non-readonly, non-destructive, non-idempotent, open-world behavior. What is not disclosed is the duplicate-submission consequence of idempotentHint=false (calling twice likely creates two bookings).

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?

Front-loads the action and the key caveat (a request, NOT confirmed), then prerequisites, payment, and return payload in short clauses. No wasted sentences despite the density of information.

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 16-parameter mutation with 9 required fields, the description supplies the sourcing rules, the confirmation caveat, the payment model, and the hand-off token. An output schema exists, so the brief return-value listing is a bonus rather than a necessity.

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 coverage is 88%, so the schema already documents nearly every field; the description adds cross-reference meaning by telling the agent that point, time, car and currency come from get_prices_and_schedule values. It does not add format or validation detail beyond that, which is acceptable given the coverage baseline of 3.

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 ('Sends a booking request for a ride between Tbilisi and Yerevan') plus the scope variants (a seat, or a whole vehicle). The sibling names get_booking_status and get_prices_and_schedule are used functionally, so an agent can tell this tool apart without opening any 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 explicit preconditions: source point/time/car/currency from get_prices_and_schedule, use the passenger's real name and phone, and obtain the passenger's yes to the price first. It also names the downstream sibling (get_booking_status via status_token), covering both when to call and what follows.

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

All GeoArm Taxi — Tbilisi ⇄ Yerevan rides 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?