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

TableJSON 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)
`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

TableJSON 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`
`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.

First observedOct 6, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already declare non-read-only, non-idempotent, open-world behavior, but the description adds crucial semantics: a booking is a request and is NOT confirmed until a dispatcher contacts the passenger, and payment is cash to the driver. It does not discuss duplicate-submission or cancellation behavior, so a 4 rather than 5.

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?

Four dense sentences, each carrying distinct information: capability, request-not-confirmation status, input sourcing, payment, and return payload. Front-loaded with the core action and scoping.

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 15-parameter mutation with an output schema and strong annotations, the description covers the confirmation workflow, the input sourcing rule, payment mode, and the follow-up tool. Nothing material is missing for correct invocation.

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 already 87%, so the baseline is 3; the description adds interpretive value by tying point, time, car and currency to /api/config values via get_prices_and_schedule, and stressing a real name and phone. It doesn't add meaning for lat/lng, agent, notes or lang beyond the schema.

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 (sends a booking request) and resource (a ride between Tbilisi and Yerevan, seat or whole vehicle), plus the scope variants. An agent can immediately distinguish it from get_prices_and_schedule and get_booking_status.

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 routes the agent: take point/time/car/currency from get_prices_and_schedule, obtain the passenger's consent to the price first, and use get_booking_status with the returned status_token. It names prerequisites and the follow-up tool.

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?