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(メールアドレス)を指定する。予約後に認証メールが送信される(キャンセル不可)。ユーザーにどちらで進めるか確認し、実行前に予約内容の最終確認を求めること。

Input Schema

TableJSON 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. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

The description fully discloses behavioral traits: 401 triggers start_login, email-based reservations send an authentication email and are non-cancellable, while logged-in reservations support cancellation. It also specifies conditional parameter requirements without relying on annotations.

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

Conciseness5/5

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

The description is dense but every sentence serves a purpose: purpose, precondition, conditional rules, two flows, and final confirmation instruction. The structure is logical and avoids repetition.

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?

The description covers preconditions, parameter selection, authentication flows, and user-communication steps. It lacks an explicit statement of the output format or success response, but given the tool's straightforward purpose, this is a minor 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 descriptions already cover 100% of parameters with detailed conditions (e.g., email required when logged out, menuId dependency on get_availability, headcountBreakdown constraints). The main description only summarizes these rules without adding new per-parameter semantics.

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 clearly states the tool's purpose—registering an Ekiten online reservation—while distinguishing it from siblings like get_availability (retrieving availability) and cancel_reservation. It also explains the two reservation modes (login vs. email) and the prerequisite of calling get_availability first.

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 instructs the agent to use get_availability before creating a reservation, and describes when to use start_login (on 401) and the email-based alternative. It also directs the agent to confirm the user's preferred mode and obtain final confirmation before execution.

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