BRONLA

Create Booking (requires user confirmation)

create_booking

Destructive

Bronla'da dacha yoki mehmonxona uchun bron yaratadi.

Bu amal bazaga yozadi va to'lov uchun havola/oldindan to'lov yozuvini
yaratishi mumkin. Faqat foydalanuvchi obyekt, sanalar, mehmonlar va to'lov
shartlarini ko'rgandan keyin aniq rozilik berganida chaqiring. Foydalanuvchi
autentifikatsiyasi MCP OAuth orqali keladi; Knox token tool argumentiga
kiritilmaydi va MCP server ichida saqlanadi. Hamyondan foydalanish faqat
`use_wallet=True` yuborilgandagina ishlatiladi (hozir bu parametr o'chirilgan).
Har chaqiruvdan oldin availability'ni tekshiring. Timeout yoki aloqa uzilishi
bo'lsa tool'ni avtomatik qayta chaqirmang: bron oldin yaralgan bo'lishi mumkin.

listing_type: `house` (dacha) yoki `property` (mehmonxona). Mehmonxona
uchun `space_ids` majburiy. `check_out` chiqish kuni, tun sifatida kirmaydi.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`pets`	No	Uy hayvonlari soni.
`adults`	Yes	Kattalar soni.
`babies`	No	Chaqaloqlar soni.
`check_in`	Yes	Kirish sanasi: YYYY-MM-DD yoki dd-mm-yyyy (masalan 2026-06-19).
`children`	No	Bolalar soni.
`check_out`	Yes	Chiqish sanasi (tun hisoblanmaydi): YYYY-MM-DD yoki dd-mm-yyyy.
`space_ids`	No	Mehmonxona uchun majburiy: check_hotel_availability natijasidagi `space_ids` (1-10 ta).
`listing_id`	Yes	E'lonning `id` qiymati (get_listing_details yoki qidiruvdan).
`promo_code`	No	Promokod (faqat dacha uchun), bo'lmasa bo'sh.
`use_wallet`	No	Hamyondan to'lash; hozircha o'chirilgan, false yuboring.
`listing_type`	Yes	`house` (dacha) yoki `property` (mehmonxona).
`payment_method`	No	To'lov usuli: `payme`, `click` yoki `paynet`.	payme

Output Schema

TableJSON Schema

Name	Required	Description
`hint`	No	Xatoni qanday tuzatish haqida ko'rsatma.
`stay`	No	Kirish/chiqish sanalari va tunlar.
`error`	No	Xato kodi; faqat tool bajarilmaganda keladi.
`detail`	No	Upstream API xatosi tafsiloti.
`status`	No	`success` bo'lsa bron yaratildi.
`listing`	No	Bron qilingan e'lon: id, name, slug, type.
`message`	No	Foydalanuvchiga ko'rsatiladigan xabar.
`payment`	No	To'lov summasi tafsilotlari.
`currency`	No	Narxlar valyutasi (UZS).
`prepayment`	No	Oldindan to'lov: pay_open, paid, default_url, options (Payme/Click/Paynet havolalari).

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 6, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, but the description adds real context beyond them: it writes to the DB and may create a payment link/prepayment record, auth arrives via MCP OAuth and the token is never a tool argument, use_wallet is currently disabled, and the non-idempotent warning is explained in concrete user-facing terms (booking may already exist).

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 is front-loaded and the remaining sentences each carry a distinct constraint (auth, wallet, availability, retry). It is moderately long and restates some schema fields (listing_type), but the density is justified by the tool's risk level.

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 a destructive, non-idempotent booking mutation, the description covers auth flow, prerequisites, consent requirements, retry hazards, and payment side effects, and an output schema exists so return values need not be described. Nothing an agent needs to call it safely is missing.

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 baseline is 3, but the description adds domain meaning the schema does not: listing_type semantics, that space_ids is mandatory for hotels, that check_out is a departure day not counted as a night, and that use_wallet is currently disabled. These clarifications genuinely improve correct invocation.

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+resource (creates a booking) and explicitly scopes it to two listing types, house (dacha) and property (mehmonxona), which distinguishes it from siblings like search_rentals or check_availability. An agent can identify the operation's intent without opening the 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 states when to call — only after the user has seen object, dates, guests and payment terms and given clear consent — plus the prerequisite to check availability before every call and the exclusion of auto-retrying after a timeout. This is strong, actionable guidance with both when and when-not conditions.

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

All BRONLA tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?