Skip to main content
Glama
sepehr071

mrbilit-mcp

by sepehr071
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Hotel details

mb_hotel
Read-onlyIdempotent

Retrieve one hotel's details, including stars, guest ratings and reviews, location, landmarks, check-in rules, amenities, and FAQ. Use it to evaluate a stay before checking room prices.

Instructions

One hotel: stars, guest rating (0-5) and latest reviews, location, landmarks, check-in rules, amenities, FAQ.

The site shows ratings x2 out of 10. landmarks: distance in km (drive minutes). Review text is cut at 400 characters unless full_text. For room prices on dates call mb_hotel_rooms with hotel (null after a numeric id: get the 'city/hotel' ref from mb_find_place(mode='hotel') with the name); for the cheapest nights mb_hotel_calendar.

Input Schema

NameRequiredDescriptionDefault
hotelYesHotel as 'city_slug/hotel_slug' (e.g. 'mashhad/enghelab') or its numeric id (e.g. '8778').
reviewsNoHow many of the latest guest reviews to include.
full_textNoReturn long texts uncut instead of clipped.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.3.0
    • addedInput schema / properties / full_text
      Added value: +{
+  "default": false,
+  "description": "Return long texts uncut instead of clipped.",
+  "type": "boolean"
+}
    • removedInput schema / properties / hotel / title
      Removed value: -"Hotel"
    • removedInput schema / properties / reviews / title
      Removed value: -"Reviews"
    • changedOutput schema / (root)
      Previous value: -{
-  "additionalProperties": true,
-  "title": "mb_hotelDictOutput",
-  "type": "object"
-}New value: +null
  2. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already establish readOnly/idempotent/non-destructive/open-world, so the safety profile is covered. The description still adds genuinely useful behavioral context beyond the schema: the returned rating is on a 0-5 scale while the site displays it doubled out of 10, review text is clipped at 400 characters unless full_text is set, and landmark distances are in km with drive minutes in parentheses.

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?

Every sentence carries information — return contents first, then scale/truncation caveats, then routing to the three related tools. The only blemish is the awkward line breaking that splits sentences ('...unless full_text. For room prices...'), which slightly hurts front-loading and readability.

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?

With no output schema, the description carries the return-value burden and does so: it lists the returned sections, flags the rating-scale conversion, and states the review truncation rule and the flag that lifts it. Combined with explicit routing to mb_hotel_rooms/mb_hotel_calendar/mb_find_place, an agent has everything needed to call this correctly.

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 coverage is 100%, so the baseline is 3, but the description goes further by explaining the two accepted identifier forms (numeric id vs 'city/hotel' slug) and how to obtain the slug form via mb_find_place, which is a workflow detail the schema pattern alone does not convey. It also implies the effects of reviews and full_text on the response.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a single, concrete resource and enumerates exactly what is returned (stars, rating, reviews, location, landmarks, check-in rules, amenities, FAQ), and it clearly distinguishes itself from siblings by routing price/calendar queries elsewhere. The only shortfall is that the retrieval verb is implicit — it reads as a noun list ('One hotel: ...') rather than stating 'Returns details for one hotel'.

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?

It explicitly names alternatives and the conditions that select them: mb_hotel_rooms for room prices on dates, mb_hotel_calendar for cheapest nights, and mb_find_place(mode='hotel') to obtain the 'city/hotel' ref. This is exactly the when/when-not/alternatives guidance the dimension asks for.

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