Skip to main content
Glama

エキテン ネット予約

get_availability

指定した店舗の予約可能な空き枠を、日時・人数・メニュー・スタッフ・禁煙喫煙・クーポン等の条件で取得する。事前に search_shops(店舗検索ツール)で取得した shopId を指定すること。予約方式(timeUnit/tableUnit)によって返却項目が異なる。フィルタ条件を指定した場合、条件に合致しない空き枠は除外(canReserve: falseに更新)され、選択できないメニュー・スタッフ・クーポンには isSelectable: false と unselectableReason(選択不可の理由コード)が付与される。AIがユーザーに予約条件を提示し、条件を確定するための情報として使用する。【reservationType による create_reservation への影響】取得した reservationType によって次ステップ create_reservation の必須パラメータが変わる。timeUnit(全ジャンル向け):headcount不要・staffId指定可・smokingPreference不要。tableUnit(グルメ向け):headcountBreakdownEnabled が false なら headcount 必須、true なら headcountBreakdown(内訳)必須。smokingSetting が separate(分煙)なら smokingPreference 必須。staffId はトルツメ。menuSelectionRequired が true の場合は menuId 必須。【人数上限の確認】tableUnit(グルメ向け)で headcountBreakdownEnabled が true の場合、各 slots[] の headcountBreakdownMax が日時・禁煙喫煙・選択済みメニューの限定数・連結可能なテーブルの最大定員数を反映した合計人数の動的な上限値。ユーザーに人数を提示・確認する際はこの値を上限として使用すること。【選択不可の判定に含まれる要素】menuId・staffId を指定した場合、限定条件(利用可能時間・曜日・日・1日の限定数)に加えて、メニューの同時対応可能件数・スタッフの同時担当可能件数が該当時間枠で上限に達していないかも判定される。staffId・couponId を先に指定した場合、対応不可・併用不可のメニューも isSelectable: false となる(メニュー側の判定はスタッフ・クーポン起点でも双方向に働く)。【tableUnit のテーブル割り当て】tableUnit で headcount または smokingPreference を指定した場合の canReserve 判定は、実際の予約確定時にテーブルを割り当てるアルゴリズムと同一のロジックで判定される(最少人数を満たす単独テーブル優先→連結テーブル→最少人数未満の単独テーブルの順、禁煙/喫煙は同属性同士のみ連結可)。【初回呼び出しの注意】menuId・staffId・couponId・headcountBreakdownの有効な値は店舗ごとに異なり事前にはわからないため、初回呼び出し時はこれらを指定せず、レスポンスのmenus/staffs/coupons/headcountBreakdownItemsから選択肢を取得すること。ユーザーが選択した後、必要であればその値を指定して再度呼び出す。【次のステップ】取得した条件をもとにユーザーへ日時・人数・メニュー等を質問し、create_reservation を呼び出す。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sinceNo空席情報の取得開始日。YYYY-MM-DD 形式。省略時は当日。reservationDate を指定した場合はそちらが優先される。until との期間(until - since)は14日以内とすること
untilNo空席情報の取得終了日。YYYY-MM-DD 形式。省略時は当日から2週間後。reservationDate を指定した場合はそちらが優先される。since との期間(until - since)は14日以内とすること
menuIdNoメニューID。指定した場合、そのメニューの限定条件(利用可能時間・曜日・日・1日の限定数)および該当時間枠の同時対応可能件数に合致する枠のみ canReserve: true とする。省略可
shopIdYes店舗ID。必須。店舗検索ツールで取得した shopId を指定
staffIdNoスタッフID。timeUnit(全ジャンル向け)のみ有効。指定した場合、そのスタッフの受付可能時間および該当時間枠の同時担当可能件数に合致する枠のみ canReserve: true とする。省略可
couponIdNoクーポンID。指定した場合、そのクーポンの限定条件に合致する枠のみ canReserve: true とする。省略可
headcountNo予約人数。tableUnit(グルメ向け予約)かつ内訳なしの場合に指定。省略可
reservationDateNo予約希望日(単一日)。YYYY-MM-DD 形式。指定した場合 since / until より優先し、その日の空き枠のみ返す。省略可
reservationTimeNo予約希望時間。HH:MM 形式。指定した場合、該当時間の枠のみ返す。省略可
smokingPreferenceNo禁煙/喫煙希望。tableUnit(グルメ向け)かつ分煙店舗の場合に指定。省略可 noSmoking / smoking / noPreference
headcountBreakdownNo来店人数の内訳。tableUnit かつ内訳ありの場合に指定。キーは headcountBreakdownItems[].itemKey、値は各内訳の人数。省略可

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so extensively. It discloses filter behavior (canReserve: false, isSelectable: false, unselectableReason), reservationType-dependent return fields, the dynamic headcountBreakdownMax, the exact table-allocation algorithm, and bidirectional menu/staff/coupon selection constraints. No contradiction with annotations exists.

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?

The description is long but well-organized with bracketed section headers and front-loaded purpose and prerequisite. Some sections, such as the create_reservation parameter rules, could arguably be trimmed or moved, but the structure makes the density navigable.

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?

There is no output schema, yet the description explains the key response concepts (slots[], menus/staffs/coupons/headcountBreakdownItems, canReserve, isSelectable, unselectableReason, headcountBreakdownMax, reservationType), the correct initial call flow, and the next step. Minor operational details like pagination or error handling are not essential for this tool's selection and invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/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 adds substantial meaning beyond the schema: timeUnit vs tableUnit parameter requirements, when headcount vs headcountBreakdown is required, smokingPreference rules, first-call omission guidance, and how each filter affects canReserve and isSelectable. This is far more than the schema provides.

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?

The description names a specific verb and resource (取得する 予約可能な空き枠), scopes it to a specified shop, and lists the filtering dimensions (日時・人数・メニュー・スタッフ・禁煙喫煙・クーポン). It also distinguishes itself from siblings by requiring shopId from search_shops and positioning itself before create_reservation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives strong workflow guidance: use shopId from search_shops, call initially without menuId/staffId/couponId/headcountBreakdown, then optionally call again with user-selected values, and follow up by asking the user and calling create_reservation. It does not explicitly state 'when not to use this tool' versus alternatives, so it stops just short of a 5.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.3/5.0
Disambiguation5/5

Each tool has a unique, clearly defined purpose: login, logout, search, genres, availability, create, and cancel. No two tools overlap in functionality, making selection straightforward.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern in snake_case (e.g., search_shops, get_availability, create_reservation). This predictable naming makes the API easy to navigate.

Tool Count5/5

Seven tools neatly cover the necessary operations for an online reservation system without redundancy or bloat. The scope is appropriately focused on the core workflow.

Completeness4/5

The toolkit covers the essential reservation lifecycle: login, search, availability check, create, cancel, and logout. While an update/modify reservation tool is absent, it is not a typical requirement for this type of system, so the coverage is nearly complete.

Resources