Skip to main content
Glama
Sign In
mrbilit-mcp

mrbilit-mcp

by sepehr071
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

All hotels of a city

mb_city_hotels
Read-onlyIdempotent

Browse every listed hotel in a city, sold out ones included, by stars, name or type. Returns ratings and addresses without prices; use date-based tools for pricing.

Instructions

Every listed hotel of a city, sold out ones included, with stars, rating and address; no prices.

Use to browse or find a hotel by stars or type regardless of dates; filters apply to one page of 90 hotels at a time, so check pages. Prices: mb_search_hotels (dates) or mb_hotel_calendar (one hotel).

Input Schema

NameRequiredDescriptionDefault
cityYesCity slug from mb_find_place(mode='hotel'), e.g. 'mashhad' or 'kish'.
nameNoOnly names containing this text, e.g. 'درویشی'.
pageNoPage of 90 hotels (the site's ranking order).
limitNoMax hotels returned from the page.
starsNoOnly this star count, e.g. 4.
hotel_typeNoKind of stay.any

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv0.3.0
    • removedInput schema / properties / city / title
      Removed value: -"City"
    • removedInput schema / properties / hotel_type / title
      Removed value: -"Hotel Type"
    • changedInput schema / properties / limit / default
      Previous value: -40New value: +20
    • removedInput schema / properties / limit / title
      Removed value: -"Limit"
    • removedInput schema / properties / name / title
      Removed value: -"Name"
    • removedInput schema / properties / page / title
      Removed value: -"Page"
    • removedInput schema / properties / stars / title
      Removed value: -"Stars"
    • changedOutput schema / (root)
      Previous value: -{
-  "additionalProperties": true,
-  "title": "mb_city_hotelsDictOutput",
-  "type": "object"
-}New value: +null
  2. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the description's job is to add semantics beyond that, which it does: sold-out hotels are included, there are no prices, and results are paginated at 90 per page. It stops short of describing the ordering or the full return shape, but the added disclosure is substantive.

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, no filler: the result set is front-loaded, then usage plus the alternative routing. The 'check `pages`' pointer is compact and actionable.

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?

For a 6-parameter, no-output-schema list tool, the description covers scope, pagination limits, absent fields and alternatives, which is enough to call it correctly. Minor gaps remain around result ordering and what a page object contains, but the essential call-time information is present.

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 schema already documents city, name, page, limit, stars and hotel_type, making 3 the baseline. The description echoes the star/type filtering and the 90-per-page pagination unit but adds no syntax or edge-case detail beyond the schema.

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 (every listed hotel of a city) plus the scope boundary that sold-out hotels are included and prices are absent. It distinguishes itself from mb_search_hotels and mb_hotel_calendar by naming them as the price-oriented alternatives.

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 says when to use it ('to browse or find a hotel by stars or type regardless of dates') and when not to ('Prices: mb_search_hotels (dates) or mb_hotel_calendar (one hotel)'), naming the correct siblings. Nothing about partner-tool selection is left to inference.

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

Deploy Server

Other Tools