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 を呼び出す。

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "shopId": "<shopId>"
    },
    "name": "get_availability"
  }
}

Input 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.

  1. Changed1 schema field changed
    • addedInput schema / properties / shopId / pattern
      Added value: +"^[0-9]+$"
  2. First observed

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations the description carries the full burden and discharges most of it: it discloses the side effect that non-matching slots are returned as canReserve:false, that unusable menus/staffs/coupons get isSelectable:false plus unselectableReason, that capacity checks include concurrent-booking limits, and that tableUnit availability uses the same allocation algorithm as the actual booking. It does not cover error behavior, whether the call is read-only, or rate/limit constraints, which keeps it below a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is front-loaded with purpose and prerequisite, and the 【】 section headers make the dense text navigable. But it is far longer than needed, with repeated statements of headcount/menu requirements and an extended create_reservation parameter matrix that arguably belongs to that tool's own definition.

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 an 11-parameter, dual-mode tool with no annotations and no output schema, the description covers mode-dependent behavior, response-derived option lists (menus/staffs/coupons/headcountBreakdownItems), the slots[] cap field, and the next step. Remaining gaps are the full shape of a slot entry and error/failure behavior.

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; the description earns above that by adding cross-parameter semantics the schema does not: the initial-call rule to leave identifier params empty, the bidirectional interaction between staffId/couponId and menu selectability, the note that staffId is ignored for tableUnit, and that headcountBreakdownMax is a dynamic per-slot cap. It stops short of giving any format or validation 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?

The first sentence names a specific verb and resource (retrieve reservable slots for a given shop) and enumerates the filter conditions it accepts. It also distinguishes itself from siblings by naming search_shops as the prerequisite source of shopId and create_reservation as the follow-up step.

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 the prerequisites (shopId from search_shops), the correct first-call pattern (omit menuId/staffId/couponId/headcountBreakdown because valid values are shop-specific and must be read from the response), the re-call pattern after user selection, and the handoff to create_reservation. This is close to a full decision procedure.

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.

Resources