BinaSmart MCP Server

Search the BinaSmart directory

search_places

Read-only

Find Addis Ababa buildings, hotels, hospitals, shops, cafés, restaurants, banks, gyms, and offices by name or category, returning bilingual names, contacts, coordinates, and BinaSmart pages.

Instructions

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, the phone only for shops that have claimed their listing, 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. For hospitals, clinics, dentists, labs and doctors anywhere in Addis Ababa, use search_health. For food (restaurants, cafes, a dish, "lunch near Megenagna") with no listed shop it returns map_place results from the city map: name, area, distance, coords and ride link, with no phone, hours, prices or menu (see map_note).

Input Schema

Name	Required	Description
`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

Output Schema

Name	Required	Description
`note`	No	How to use or present this result
`count`	No	Number of items returned
`results`	No	Matching places
`source_url`	No	bina.et page this result comes from; cite it

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": {
+    "count": {
+      "description": "Number of items returned",
+      "type": [
+        "number",
+        "null"
+      ]
+    },
+    "note": {
+      "description": "How to use or present this result",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "results": {
+      "anyOf": [
+        {
+          "items": {
+            "additionalProperties": true,
+            "properties": {
+              "city": {
+                "description": "City",
+                "type": [
+                  "string",
+                  "null"
+                ]
+              },
+              "coords": {
+                "anyOf": [
+                  {
+                    "additionalProperties": true,
+                    "properties": {
+                      "lat": {
+                        "description": "Latitude",
+                        "type": [
+                          "number",
+                          "null"
+                        ]
+                      },
+                      "lng": {
+                        "description": "Longitude",
+                        "type": [
+                          "number",
+                          "null"
+                        ]
+                      }
+                    },
+                    "type": "object"
+                  },
+                  {
+                    "type": "null"
+                  }
+                ],
+                "description": "Coordinates; pass as \"lat,lng\" to quote_ride"
+              },
+              "is_hospital": {
+                "description": "Use get_hospital_departments",
+                "type": [
+                  "boolean",
+                  "null"
+                ]
+              },
+              "is_hotel": {
+                "description": "Use get_hotel_rooms",
+                "type": [
+                  "boolean",
+                  "null"
+                ]
+              },
+              "kind": {
+                "description": "Place type",
+                "type": [
+                  "string",
+                  "null"
+                ]
+              },
+              "name": {
+                "description": "Name",
+                "type": [
+                  "string",
+                  "null"
+                ]
+              },
+              "name_am": {
+                "description": "Name in Amharic",
+                "type": [
+                  "string",
+                  "null"
+                ]
+              },
+              "slug": {
+                "description": "Place slug",
+                "type": [
+                  "string",
+                  "null"
+                ]
+              },
+              "sub_city": {
+                "description": "Sub-city",
+                "type": [
+                  "string",
+                  "null"
+                ]
+              },
+              "url": {
+                "description": "bina.et page",
+                "type": [
+                  "string",
+                  "null"
+                ]
+              }
+            },
+            "type": "object"
+          },
+          "type": "array"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "Matching places"
+    },
+    "source_url": {
+      "description": "bina.et page this result comes from; cite it",
+      "type": [
+        "string",
+        "null"
+      ]
+    }
+  },
+  "type": "object"
+}

First observedv0.1.0Oct 18, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only declare readOnlyHint and openWorldHint; the description adds substantial extra context — phone numbers appear only for claimed listings, coordinates are reusable as pickup/dropoff for quote_ride, hotels/hospitals are flagged, and the map fallback omits phone/hours/prices/menu. This is meaningful behavioral disclosure beyond the structured fields.

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?

Purpose and coverage are front-loaded, and the semicolon-separated content mostly earns its place, but the single dense paragraph packs in return-field and fallback detail that borders on overload.

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?

Given an output schema exists, the description need not explain returns, yet it still covers the key asymmetries (claimed vs unclaimed phone, map fallback limitations) and routing to sibling tools, leaving nothing an agent needs to call it correctly.

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 query, limit (default 8, max 25), and category are already documented. The description lists categories in prose but adds no syntax or format detail beyond the schema, so baseline 3 is appropriate.

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 ('Find') and resource (buildings, hotels, hospitals, shops in Addis Ababa listed on BinaSmart) and enumerates the covered categories. It clearly differentiates itself from siblings like search_health, get_hotel_rooms, and get_hospital_departments, so an agent can route without opening a schema.

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 names alternatives and the conditions that select them: use get_hotel_rooms / get_hospital_departments for detail, search_health for health providers anywhere in the city, and it explains the map_place fallback for food searches with no listed shop. When-to-use and when-to-switch are both spelled out.

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