Skip to main content
Glama

BinaSmart

by et.bina

Book a BinaSmart ride

request_ride
Idempotent

Books a ride in Addis Ababa at the fixed fare from quote_ride. ALWAYS confirm pickup, drop-off, tier, fare and the rider's Ethiopian phone number with the user before calling. 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
NameRequiredDescriptionDefault
tierYesVehicle tier from quote_ride
pickupYesPickup: 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.
dropoffYesDrop-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_nameYesRider's name (or the booker's name when booking for someone else)
rider_phoneYesEthiopian mobile: 09XXXXXXXX or +2519XXXXXXXX (any number if booking for someone else)
passenger_nameNoBook for someone else: the passenger's name (the driver calls the passenger)
payment_methodNocash (default) or chapa (telebirr/card link)
passenger_phoneNoBook for someone else: the passenger's Ethiopian mobile (09… or +2519…)

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

It discloses behaviors beyond the annotations: a dispatcher assigns a driver, the rider is contacted on the provided phone, the tool returns a ride id and live tracking link, and it clarifies third-party booking semantics. The idempotentHint is not contradicted, since the description does not claim each call creates a brand-new unique ride.

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?

The description is three focused sentences: purpose, required confirmation, and booking-for-others behavior. Important information is front-loaded, and no sentence is filler.

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 an 8-parameter tool with no output schema, the description covers the essential context: return value (ride id and tracking link), the required pre-call confirmation, the relationship to quote_ride, and the passenger/rider distinction. Nothing critical 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 100%, so the baseline is 3. The description adds meaning by explaining that passenger_name/passenger_phone are used when booking for someone else and that rider_name/rider_phone become the booker in that case, which is not fully obvious from the schema alone.

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?

The description uses a specific verb and resource: 'Books a ride in Addis Ababa at the fixed fare from quote_ride.' This clearly distinguishes the tool from siblings like quote_ride and get_ride_status by stating the action and its relation to the quoting flow.

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?

The description gives strong usage guidance: it mandates confirming pickup, drop-off, tier, fare, and rider phone before calling, and it explains the passenger_name/passenger_phone case for booking on behalf of someone else. It does not explicitly name alternatives like quote_ride or get_ride_status, but the prerequisite relationship to quote_ride is clearly implied.

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
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.2/5.0
Disambiguation5/5

Each tool targets a distinct action and resource: ride tools cleanly split quoting, booking, status, and cancellation; list_events and list_films are clearly separated between in-person events and online films; search_places points to dedicated hotel/hospital detail tools. No two tools have overlapping responsibilities.

Naming Consistency4/5

All names are lowercase snake_case with a leading verb and a domain object, which makes the pattern predictable. There are minor inconsistencies: read operations mix list_ and get_, and get_ethiopia_guide is singular despite being able to return a collection of guides when called without a slug.

Tool Count5/5

10 tools is well-scoped for a multi-vertical consumer platform. Each tool earns its place by covering a necessary step in ride booking, place discovery, entertainment listings, or guide access, with no redundant additions.

Completeness4/5

The ride lifecycle is well covered with quote, request, status, and cancel, and search_places feeds cleanly into hotel and hospital detail tools. Minor gaps exist for generic non-hotel/hospital place details and for transactional booking/rental actions, but those are partially handled via returned external URLs.

Resources