Skip to main content
Glama

エキテン ネット予約

create_reservation

エキテンのネット予約を登録する。事前に get_availability(予約在庫状況取得ツール)で店舗の予約可能な空き枠(reservationType・空席スロット・メニュー・スタッフ・クーポン・人数設定等)を取得してから使用すること。tableUnit(グルメ向け)かつ headcountBreakdownEnabled: true(内訳あり)の場合、headcountBreakdown の合計人数は get_availability の該当 slots[].headcountBreakdownMax を上限とする。予約方法は2通り。(1)ログインして予約する場合: email を付けずに呼び出す。未ログインなら 401 認証要求が返るので start_login を呼び、返されたloginUrlをユーザーに提示してログインを完了してもらい、完了後に再実行する(ログインすると会員情報が反映され、予約後のキャンセルも可能)。(2)ログインせず予約する場合: email(メールアドレス)を指定する。予約後に認証メールが送信される(キャンセル不可)。ユーザーにどちらで進めるか確認し、実行前に予約内容の最終確認を求めること。

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>",
      "reservationDate": "<reservationDate>",
      "reservationTime": "<reservationTime>",
      "lastName": "<lastName>",
      "firstName": "<firstName>",
      "lastNameKana": "<lastNameKana>",
      "firstNameKana": "<firstNameKana>",
      "phone": "<phone>"
    },
    "name": "create_reservation"
  }
}

Input Schema

NameRequiredDescriptionDefault
noteNoお店へのご要望。省略可(上限2000文字)
emailNoメールアドレス。未ログイン時は必須。ログイン済みの場合は省略可(会員登録済みアドレスを使用)
phoneYes電話番号。必須。ハイフンなし。携帯・IP電話(070/080/090/050等)は11桁、固定電話(03/06等)は10桁。形式: ^(0[5-9]0[0-9]{8}|0[1-9][1-9][0-9]{7})$
menuIdNoメニューID。予約在庫状況取得ツール(get_availability)で取得した menus[] から選択したメニューの menuId を指定する。同ツールの menuSelectionRequired が true の場合は必須(false の場合は省略可)
shopIdYesエキテン店舗ID。必須。
staffIdNoスタッフID。reservationType が timeUnit(全ジャンル向け)のみ有効。省略可(指名なし)。tableUnit(グルメ向け)の場合はトルツメ
couponIdNoクーポンID。省略可
lastNameYes予約者の姓。必須。
firstNameYes予約者の名。必須。
headcountNo予約人数。tableUnit(グルメ向け)かつ headcountBreakdownEnabled: false(内訳なし)の場合のみ必須。それ以外(timeUnit、または内訳ありの場合)はトルツメ
lastNameKanaYes予約者の姓(ふりがな)。必須。
firstNameKanaYes予約者の名(ふりがな)。必須。
reservationDateYes予約日。必須。YYYY-MM-DD 形式。
reservationTimeYes予約時間。必須。HH:MM 形式。
smokingPreferenceNo禁煙/喫煙希望。reservationType が tableUnit(グルメ向け)かつ smokingSetting が separate(分煙)の場合のみ有効・必須。それ以外の場合はトルツメ
headcountBreakdownNo来店人数の内訳。tableUnit かつ headcountBreakdownEnabled: true(内訳あり)の場合のみ必須。キーは headcountBreakdownItems[].itemKey、値は各内訳の人数(integer)。合計人数は get_availability の headcountBreakdownMax が上限。それ以外はトルツメ。例:{"adult": 2, "child": 1}

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.3/5.0
Behavior4/5

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

No annotations exist, so the description carries the full burden — and it does well: it discloses the 401 auth-challenge flow, the start_login/loginUrl handoff, that logged-in bookings can be cancelled while guest bookings send a verification email and cannot be cancelled. It does not describe the success response (no output schema) or failure modes beyond 401, so it falls short of 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.

Conciseness4/5

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

Front-loaded with the purpose, then the prerequisite, then the two booking flows — a sensible order. It is somewhat long and duplicates the headcountBreakdownMax cap that the schema already states, which costs a point, but there is no filler.

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 16-parameter mutation tool with no annotations and no output schema, the description covers the prerequisite data, the auth branching, the confirmation requirement and the cancellation asymmetry well. It leaves the return value and non-auth error handling undocumented, which is the remaining gap.

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% and the schema already spells out every conditional (tableUnit, headcountBreakdownEnabled, smokingSetting, menuSelectionRequired). The description restates the headcountBreakdownMax cap and the email/login duality that the schema also documents, adding little parameter meaning beyond it. Baseline 3 is appropriate.

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 ('エキテンのネット予約を登録する') and immediately distinguishes itself from its sibling get_availability by declaring it a prerequisite and from cancel_reservation by implication. An agent can identify the operation 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?

Names the required prior call (get_availability) and the exact data to read from it, then splits usage into two explicit modes (logged-in without email vs. guest with email) with the condition that selects each. It also instructs the agent to ask the user which mode and to confirm the booking details before execution — explicit when/when-not guidance with no gaps.

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