Quote and book fixed-price rides in Addis Ababa, search the BinaSmart directory and Ethiopia guides
Cancels a BinaSmart ride that has not started yet. Confirm with the user first. Needs the ride id and the rider phone used to book.
| Name | Required | Description | Default |
|---|---|---|---|
| ride_id | Yes | ||
| rider_phone | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, readOnlyHint=false, and idempotentHint=true, so the cancellation behavior is expected. The description adds valuable context beyond annotations: the ride must not have started, and confirmation with the user is required before invoking the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each carrying distinct information: what the tool cancels, the precondition, the confirmation requirement, and the required inputs. No filler or repetition of the tool name or title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter cancellation tool with destructive and idempotent annotations already supplied, the description covers the necessary invocation details: target ride, precondition, confirmation step, and required inputs. It does not describe the result/response format, but no output schema exists and the action is straightforwardly conveyed by the verb.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It identifies both required parameters and adds meaning to rider_phone as 'the rider phone used to book.' However, it does not elaborate on ride_id or provide format/usage details beyond what the schema's min/max lengths already state.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Cancels'), a specific resource ('a BinaSmart ride'), and a clear precondition ('has not started yet'). This distinguishes it from sibling tools like request_ride, quote_ride, and get_ride_status without needing to inspect their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: only cancel rides that have not started, and confirm with the user first. It does not explicitly name alternative tools or state when not to use it, but the precondition and confirmation requirement provide solid operational guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
BinaSmart's bilingual (Amharic + English) step-by-step guides to Ethiopian government and banking services: Fayda ID, telebirr, CBE Birr, e-Passport, eVisa, TIN, business licence, VAT/TOT, customs, driving licence, car import, Yellow Card, bank account, birth/marriage certificate, utility bills, Labor ID and LMIS registration and the COC occupational competency certificate (Overseas Employment Proclamation 1389/2025), rental agreements, tenant screening. Call with no slug to list guides; call with a slug for the full text. The guides hold the correct official names and links — prefer them over guessing.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | Guide slug from the list, e.g. tin-registration-ethiopia |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes that this is a safe read operation, and the description adds meaningful behavior beyond that: the no-slug versus slug call modes, the bilingual nature of the guides, and the fact that they contain official names and links. This is useful, transparent context for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average because it enumerates the covered services, but that enumeration is valuable for an agent deciding whether this tool applies. The operational instructions come at the end and are clear, though the long list could be slightly restructured for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description fully covers what the agent needs: what the guide contains, when to use it, how to request the list versus full text, and why the content is authoritative. Nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents the single optional 'slug' parameter with an example, and the description reinforces its semantic by explaining that omitting it lists guides while providing it fetches the full text. This adds practical meaning to the schema at 100% coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource (BinaSmart's bilingual guides to Ethiopian government and banking services) and a specific verb ('Call'). It also states two distinct behaviors: listing guides with no slug and retrieving full text with a slug, which makes the tool's role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly explains when to use the tool: to access step-by-step guides for official Ethiopian services, and how to choose between the list and full-text modes. It also advises preferring these guides over guessing. It does not explicitly name alternatives or exclusions, but no close sibling tool exists in the provided list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Departments of a hospital listed on BinaSmart with consultation fee (ETB), doctors, hours, floor/room and appointment slots left for a date. Use the slug from search_places (is_hospital = true).
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | YYYY-MM-DD (default today) | |
| slug | Yes | Hospital slug from search_places |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds useful behavioral context about what the tool returns per date and the required provenance of the slug. There is no contradiction with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single information-dense sentence. It front-loads the resource and output contents, then gives the input routing instruction. Every part earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only listing tool with only two parameters, the description is complete enough: it names the input source, the optional date dimension, and the output fields. The schema provides the date pattern and default, so nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 reinforces that slug should be a hospital slug from search_places with is_hospital=true, but it does not materially add to the schema's existing parameter documentation for date format or default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource (hospital departments on BinaSmart) and enumerates the returned data: consultation fee in ETB, doctors, hours, floor/room, and appointment slots left for a date. This clearly distinguishes it from sibling tools like get_hotel_rooms and search_places.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit usage context: the slug must come from search_places with is_hospital = true, and the date is the target for slot availability. It does not explicitly name alternatives or state when not to use the tool, but the intended trigger is clear from the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Room types, nightly prices (ETB), capacity and amenities for a hotel listed on BinaSmart. Use the slug from search_places (is_hotel = true).
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Hotel slug from search_places |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so this is a safe read operation. The description adds useful context about the returned content (room types, prices, capacity, amenities) but does not disclose additional behavioral traits such as error handling or empty-result behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both informative and free of filler. The description front-loads the tool's output scope and then provides the input prerequisite, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only tool with a 100%-covered schema, the description is nearly complete: it states what data is returned and how to obtain the required slug. The lack of an output schema is partially compensated by the explicit list of data categories, though the exact response shape remains unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, slug, has full schema-description coverage ('Hotel slug from search_places'), and the tool description repeats this same guidance. Since the schema already documents the parameter adequately, the description adds no semantic value beyond the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (hotel listed on BinaSmart) and the data returned: room types, nightly prices in ETB, capacity, and amenities. It lacks an explicit verb like 'retrieve' or 'list' and does not explicitly differentiate itself from sibling tools, but the content is unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit context on how to invoke the tool: use the slug from search_places with is_hotel = true. It provides a clear prerequisite but does not state when not to use it or name alternatives, so it falls short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| ride_id | Yes | ||
| rider_phone | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds useful behavioral detail: the set of possible ride statuses and the conditional availability of driver/vehicle/plate data only after assignment. This is meaningful context beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two compact sentences with no filler. It front-loads the core purpose and status list, then immediately states the required inputs, making every sentence useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description appropriately names the returned data categories: status, driver name, vehicle, and plate. It also communicates the conditional nature of some fields. It could mention error behavior or real-time freshness, but for a simple read-only lookup tool it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry the semantic weight. It explains that rider_phone is the phone used to book and that ride_id is needed alongside it, which adds meaning the schema alone does not convey, though it could go further in describing expected formats or relationship between the two.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation as retrieving the current status of a BinaSmart ride and enumerates the possible statuses. It also specifies that driver name, vehicle, and plate are included once assigned, which makes the tool's purpose distinct from siblings like cancel_ride or request_ride.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes clear that this tool is for checking a ride's current status and states the required identifying information: ride id and rider phone used to book. It does not explicitly contrast with alternatives, but the read-only status vocabulary and required parameters provide clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upcoming films, concerts, theatre and events on BinaSmart in Addis Ababa with venue, hall, start time, prices per tier and seats left. Seats are chosen and paid at the url returned (Chapa or at the counter); the ticket is a QR code.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, but the description goes further by explaining that seats are selected and paid at a returned URL, payment can be via Chapa or at the counter, and the ticket is a QR code. This adds meaningful behavioral context beyond the annotations and clearly signals that booking/payment is not performed by this tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The first sentence front-loads scope and returned fields, and the second explains the follow-up payment/ticketing flow. Every clause adds useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only listing tool, the description is complete: it names the domain, location, and returned fields, and describes the downstream booking flow. Even without an output schema, an agent can confidently invoke the tool and interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4; there is no parameter information for the description to add. The description focuses on output content and behavior, which is appropriate since no parameters exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (events on BinaSmart in Addis Ababa) and the returned details (venue, hall, start time, prices per tier, seats left). It is not phrased as an explicit verb statement like 'List...', but the tool name and content make the purpose unmistakable. It does not explicitly distinguish itself from the sibling list_films.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: for upcoming events in Addis Ababa. However, it provides no explicit comparison with alternatives such as list_films, and there is no guidance on when not to use it. Usage context is clear but must be inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Licensed Amharic (Ethiopian) films that can be watched online on BinaSmart Watch (bina.et/watch): title in Amharic and English, year, genre, whether it is free or rented for 48 hours (ETB), and the watch url. Free titles are public YouTube releases played through the YouTube player; rentals need Chapa. Optional search by title or genre.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max films, default 20 | |
| query | No | Title (Amharic or English) or genre to filter by; omit for the latest films |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only. The description goes beyond this by explaining that free titles are YouTube releases played through the YouTube player and rentals require Chapa, plus the 48-hour rental window. This gives an agent useful context about watch access without contradicting the readOnlyHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. It front-loads the resource and output fields, then adds access behavior and search capability. The first sentence is somewhat dense but remains readable and appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description explicitly lists the returned fields (title in Amharic and English, year, genre, price, watch URL). It also covers the free vs rental access model. It could mention limit/pagination behavior, but for a simple list tool this is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with limit and query both described. The description's mention of 'optional search by title or genre' mirrors the query parameter, adding no new semantics. Baseline 3 is appropriate since the schema already documents the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states exactly what the tool does: it returns licensed Amharic films watchable online on BinaSmart Watch, including specific fields (title, year, genre, free/rental status, watch URL). The resource and scope are unambiguous, and the tool is clearly distinct from the ride, place, event, and hospital siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: this tool is for discovering Amharic films on BinaSmart Watch, with optional filtering by title or genre. It does not explicitly name alternative tools or when not to use it, but no sibling offers film listing, so the intended usage is effectively communicated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fixed upfront price for a ride inside Addis Ababa, Ethiopia — no surge, cash or telebirr/Chapa. Returns distance, ETA and the fare for every vehicle tier (moto, bajaj, economy, comfort, XL). Call this before request_ride and read the fare to the user.
| Name | Required | Description | Default |
|---|---|---|---|
| pickup | Yes | Pickup: a place name in Addis Ababa (e.g. "Edna Mall", "Bole Airport", "Piassa") or "lat,lng" like "9.0108,38.7578". | |
| 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". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool read-only. The description adds behavioral context: fixed upfront pricing, no surge, accepted payment methods (cash/telebirr/Chapa), and a defined return payload. This goes beyond the schema without contradicting the readOnlyHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences front-load the core purpose, then list return fields and workflow. There is no filler; every sentence adds decision-relevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description names exactly what is returned (distance, ETA, fare per tier), making the call outcome predictable. It also gives the critical sequencing context with request_ride and the geographic scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both pickup and dropoff fully documented including examples. The description adds only scope ('inside Addis Ababa') already present in the schema, so it adds little beyond the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action (quote a ride) and result: fixed upfront price, distance, ETA, and per-tier fares for a ride in Addis Ababa. The mention of 'before request_ride' also distinguishes it from the booking sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to 'Call this before request_ride and read the fare to the user,' which establishes the correct workflow. It does not spell out when not to use it or name alternative tools besides request_ride, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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…) |
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.
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.
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.
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.
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.
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.
Find buildings, hotels, hospitals and shops in Addis Ababa listed on BinaSmart (bina.et): cafés, restaurants, pharmacies, banks, gyms, salons, clinics, offices. Returns names (English + Amharic), building and unit, phone for shops, coordinates when known (usable as pickup/dropoff for quote_ride), and the bina.et page. Hotels and hospitals are flagged — use get_hotel_rooms / get_hospital_departments for details.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results per kind (default 8) | |
| query | Yes | Name or part of a name, English or Amharic | |
| category | No | Shop category filter: cafe | restaurant | pharmacy | retail | service | gym | salon | clinic | bank | office | other |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite readOnlyHint=true and openWorldHint=false annotations, the description adds substantial behavioral detail: exact return fields, English + Amharic names, phone only for shops, coordinates 'when known', and flagging of hotels/hospitals. Since there is no output schema, this output-shape disclosure is especially valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no filler: scope is front-loaded, return fields are enumerated compactly, and sibling routing is given last. Every clause contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only search tool with no output schema, the description covers scope, return values, caveats like 'when known', and routing to specialized sibling tools. The input parameters are fully documented in the schema, and the description fills the output-side gap completely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents query, limit, and category semantics, including category enum values and limit bounds/default. The description does not add parameter-specific meaning beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Find' and names the exact resource: buildings, hotels, hospitals and shops in Addis Ababa listed on BinaSmart. It also lists concrete example place types and return fields, making the tool's scope unmistakable and differentiating it from siblings like get_hotel_rooms and get_hospital_departments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says that hotels and hospitals are flagged and that get_hotel_rooms / get_hospital_departments should be used for their details. It also explains that coordinates are usable as pickup/dropoff for quote_ride, giving the agent clear routing to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
cancel_rideget_ethiopia_guideget_hospital_departmentsget_hotel_roomsget_ride_statuslist_eventslist_filmsquote_riderequest_ridesearch_placesClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Search places, compare ride-hailing options, and plan trotro minibus journeys.
Book rides, get fare estimates, and manage trips across African cities with Rovv.
Read-only Arabic and English Taxi Rido product knowledge and taxi operations guides.
Search vehicles, real estate and jobs; manage your listings, alerts, enquiries and viewings.
Add one secure layer between your agents and this server.
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.
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.
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.
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.
