BinaSmart MCP Server

Book a BinaSmart ride

request_ride

Idempotent

Book an Addis Ababa ride at a fixed quoted fare, dispatch a driver, and get a ride ID with live tracking; supports booking for someone else with passenger details.

Instructions

Books a ride in Addis Ababa at the fixed fare from quote_ride. It sends a real driver, so it takes the pickup, drop-off, tier, fare and the rider's Ethiopian phone number as the user confirmed them. A dispatcher assigns a driver; the rider is contacted on the phone given. Returns the ride id and a live tracking link. To book for someone else (e.g. a relative in Addis while you are abroad), pass passenger_name and passenger_phone; rider_name/rider_phone are then the booker and may be a foreign number.

Input Schema

TableJSON Schema

Name	Required	Description
`tier`	Yes	Vehicle tier from quote_ride
`pickup`	Yes	Pickup: a place name in Addis Ababa (e.g. "Edna Mall", "Bole Airport", "Piassa") or "lat,lng" like "9.0108,38.7578". Prefer the pickup_coords from quote_ride.
`dropoff`	Yes	Drop-off: a place name in Addis Ababa (e.g. "Edna Mall", "Bole Airport", "Piassa") or "lat,lng" like "9.0108,38.7578". Prefer the dropoff_coords from quote_ride.
`rider_name`	Yes	Rider's name (or the booker's name when booking for someone else)
`rider_phone`	Yes	Ethiopian mobile: 09XXXXXXXX or +2519XXXXXXXX (any number if booking for someone else)
`passenger_name`	No	Book for someone else: the passenger's name (the driver calls the passenger)
`payment_method`	No	cash (default) or chapa (telebirr/card link)
`passenger_phone`	No	Book for someone else: the passenger's Ethiopian mobile (09… or +2519…)

Output Schema

TableJSON Schema

Name	Required	Description
`note`	No	How to use or present this result
`test`	No	true for a reviewer test booking (no driver is sent)
`tier`	No	Vehicle tier
`driver`	No	Assigned driver, null until one is assigned
`pickup`	No	Pickup place
`status`	No	dispatching, assigned, arriving, arrived, ontrip, completed, cancelled, or test_booking
`dropoff`	No	Drop-off place
`ride_id`	No	Ride id (needed for get_ride_status and cancel_ride)
`fare_etb`	No	Fixed fare in birr
`whatsapp`	No	BinaSmart WhatsApp support
`duplicate`	No	true when the same booking was already made
`next_step`	No	What to tell the user now
`booked_for`	No	Passenger name when booked for someone else
`source_url`	No	bina.et page this result comes from; cite it
`requested_at`	No	When the ride was requested (ISO time)
`tracking_url`	No	Live tracking page
`payment_method`	No	cash, telebirr or chapa
`payment_status`	No	Payment status

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.1.2Oct 18, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": true,
+  "properties": {
+    "booked_for": {
+      "description": "Passenger name when booked for someone else",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "driver": {
+      "anyOf": [
+        {
+          "additionalProperties": true,
+          "properties": {
+            "name": {
+              "description": "Driver name",
+              "type": [
+                "string",
+                "null"
+              ]
+            },
+            "phone": {
+              "description": "Driver phone",
+              "type": [
+                "string",
+                "null"
+              ]
+            },
+            "plate": {
+              "description": "Plate number",
+              "type": [
+                "string",
+                "null"
+              ]
+            },
+            "rating": {
+              "anyOf": [
+                {
+                  "type": [
+                    "number",
+                    "string"
+                  ]
+                },
+                {
+                  "type": "null"
+                }
+              ],
+              "description": "Driver rating"
+            },
+            "vehicle": {
+              "description": "Vehicle"
+            }
+          },
+          "type": "object"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "Assigned driver, null until one is assigned"
+    },
+    "dropoff": {
+      "description": "Drop-off place",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "duplicate": {
+      "description": "true when the same booking was already made",
+      "type": [
+        "boolean",
+        "null"
+      ]
+    },
+    "fare_etb": {
+      "anyOf": [
+        {
+          "type": [
+            "number",
+            "string"
+          ]
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "Fixed fare in birr"
+    },
+    "next_step": {
+      "description": "What to tell the user now",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "note": {
+      "description": "How to use or present this result",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "payment_method": {
+      "description": "cash, telebirr or chapa",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "payment_status": {
+      "description": "Payment status",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "pickup": {
+      "description": "Pickup place",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "requested_at": {
+      "description": "When the ride was requested (ISO time)",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "ride_id": {
+      "description": "Ride id (needed for get_ride_status and cancel_ride)",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "source_url": {
+      "description": "bina.et page this result comes from; cite it",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "status": {
+      "description": "dispatching, assigned, arriving, arrived, ontrip, completed, cancelled, or test_booking",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "test": {
+      "description": "true for a reviewer test booking (no driver is sent)",
+      "type": [
+        "boolean",
+        "null"
+      ]
+    },
+    "tier": {
+      "description": "Vehicle tier",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "tracking_url": {
+      "description": "Live tracking page",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "whatsapp": {
+      "description": "BinaSmart WhatsApp support",
+      "type": [
+        "string",
+        "null"
+      ]
+    }
+  },
+  "type": "object"
+}

First observedv0.1.0Oct 18, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=false), and the description adds real value on top: a real driver is dispatched, a human dispatcher assigns the driver, the rider is phoned, and it returns a ride id plus live tracking link. It misses the one thing the idempotentHint most warrants — whether a retried call re-books or returns the same ride — and says nothing about cancellation windows or payment timing.

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?

Three sentences, front-loaded with the action and destination, then side effects and return values, then the alternate-booker case. The middle sentence ("It sends a real driver, so it takes ... as the user confirmed them") is compressed to the point of being slightly hard to parse, but no sentence is 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?

Output schema exists, yet the description still usefully names the return payload, and the 8-parameter mutation surface is well covered including the optional passenger and payment paths. What's still absent is preconditions: account/registration needs and whether a payment authorization happens at booking time for chapa.

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 100%, so the per-field semantics are already documented and the baseline is 3. The description does contribute the cross-field meaning of passenger_name/passenger_phone flipping rider_name/rider_phone into booker fields with a possibly foreign number, which the schema only states tersely, so it edges toward useful without reaching 4-level depth on fare/payment semantics.

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 ("Books a ride") scoped to Addis Ababa at the fixed fare from quote_ride. It is clearly distinguishable from the pricing sibling quote_ride and from get_ride_status/cancel_ride, which handle post-booking lifecycle.

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 concrete usage context: fare must come from quote_ride, inputs passed "as the user confirmed them", and a full explanation of the booking-for-someone-else variant. It does not explicitly name the when-not path (e.g. use cancel_ride to undo, or re-quote if details change), so the routing guidance is strong but not exhaustive.

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