Skip to main content
Glama

BinaSmart

by et.bina
OverviewDiscussionsAdmin

Ride status

get_ride_status
Read-only

Current status of a BinaSmart ride (dispatching, assigned, arriving, arrived, ontrip, completed, cancelled) with driver name, vehicle and plate once assigned. Needs the ride id and the rider phone used to book.

Input Schema

NameRequiredDescriptionDefault
ride_idYesRide id returned by request_ride
rider_phoneYesEthiopian phone number used to book the ride, in the form 09xxxxxxxx or +2519xxxxxxxx

Output Schema

NameRequiredDescriptionDefault
noteNoHow to use or present this result
testNotrue for a reviewer test booking (no driver is sent)
tierNoVehicle tier
driverNoAssigned driver, null until one is assigned
pickupNoPickup place
statusNodispatching, assigned, arriving, arrived, ontrip, completed, cancelled, or test_booking
dropoffNoDrop-off place
ride_idNoRide id (needed for get_ride_status and cancel_ride)
fare_etbNoFixed fare in birr
source_urlNobina.et page this result comes from; cite it
requested_atNoWhen the ride was requested (ISO time)
tracking_urlNoLive tracking page
payment_methodNocash, telebirr or chapa
payment_statusNoPayment status

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / rider_phone / description
      Previous value: -"Ethiopian phone number used to book the ride, e.g. 0911234567 or +251911234567"New value: +"Ethiopian phone number used to book the ride, in the form 09xxxxxxxx or +2519xxxxxxxx"
  2. Changed3 schema fields changed
    • addedInput schema / properties / ride_id / description
      Added value: +"Ride id returned by request_ride"
    • addedInput schema / properties / rider_phone / description
      Added value: +"Ethiopian phone number used to book the ride, e.g. 0911234567 or +251911234567"
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": true,
+  "properties": {
+    "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"
+      ]
+    },
+    "fare_etb": {
+      "anyOf": [
+        {
+          "type": [
+            "number",
+            "string"
+          ]
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "Fixed fare in birr"
+    },
+    "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"
+      ]
+    }
+  },
+  "type": "object"
+}
  3. First observed

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered by structured data. The description still adds real value by disclosing the status state machine (dispatching through cancelled), the conditional nature of driver/vehicle fields ('once assigned'), and the identity requirement of the booking phone.

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, zero filler, and the payload description plus the prerequisite are both front-loaded. Every clause earns its place by either naming the statuses, the returned fields, or the required inputs.

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?

An output schema exists, so return values need not be re-explained, and the description covers the status values, conditional driver data, and required identifiers. It stops short of noting failure modes (invalid ride id, mismatched phone), which would round out a lookup tool with an identity check.

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 both parameters are already documented in the schema (ride_id 'returned by request_ride', rider_phone with format guidance). The description restates that the phone must be the one used to book, adding only a mild ownership-check framing rather than syntax or format detail, so the baseline 3 applies.

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 (current status of a BinaSmart ride), enumerates the full status lifecycle, and adds what extra data appears once a driver is assigned (name, vehicle, plate). An agent can distinguish it from request_ride, quote_ride and cancel_ride 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 Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The sentence 'Needs the ride id and the rider phone used to book' establishes the prerequisite context for use, implying it is a lookup for a ride the caller already booked. However, it never says when to prefer this over alternatives such as cancel_ride or request_ride, nor what to do if the ride is not found.

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

All BinaSmart toolsInspect
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