エキテン（日本全国のお店・施設の情報サイト）のネット予約を提供するMCPサーバー。オールジャンルの日本国内店舗・施設が対象。店舗検索・空き確認・予約登録・キャンセルに対応。
Scored across 7 tools
Each tool maps to a distinct step or resource in the reservation flow: genre lookup, shop search, availability, booking creation, cancellation, and login/session management. No two tools overlap enough to cause likely misselection.
Most tools use a consistent snake_case verb_noun convention such as search_shops, get_availability, create_reservation, and cancel_reservation. logout is the only verb-only name, which is a minor deviation from the pattern.
Seven tools are well-scoped for an end-to-end reservation workflow, and each tool has a clear role. The set is neither thin nor bloated.
The surface covers discovery, availability, booking, cancellation, and authentication, but it lacks a way to list or retrieve a user's existing reservations. Cancellation depends on a reservationNo returned by create_reservation, and there is no modify/reschedule operation, which limits realistic reservation management.
ログイン済みユーザーの予約をキャンセルする。未ログインユーザーはキャンセル不可（ログインしていない場合は start_login を呼び、返されたloginUrlをユーザーに提示してログインを案内すること）。キャンセルする reservationNo は create_reservation（予約登録ツール）のレスポンスで取得した値を使用する。実行前に必ずユーザーにキャンセル対象の予約内容を確認し、最終確認を求めること。
| Name | Required | Description | Default |
|---|---|---|---|
| reservationNo | Yes | キャンセルする予約番号。必須。create_reservation（予約登録ツール）のレスポンスで取得した reservationNo。 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden well by disclosing authentication requirements, the login fallback, the source of the reservation number, and the required final confirmation. It stops short of describing irreversibility, side effects, or failure behavior for an already-cancelled or invalid reservation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four focused sentences, front-loading the purpose before auth guidance, prerequisite sourcing, and confirmation requirements. Every sentence adds operational value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter mutation with no output schema, the description covers the critical operational context: login requirement, alternative login flow, reservationNo source, and confirmation. It is slightly incomplete because it does not describe post-cancellation outcomes or error cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already documents reservationNo as required with its source from create_reservation. The description repeats that source but adds no additional syntax or semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: cancelling a logged-in user's reservation. It also distinguishes the tool from siblings by routing unauthenticated users to start_login and directing agents to create_reservation for the reservation number.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states the login prerequisite, the fallback action when not logged in (call start_login and present loginUrl), where to obtain reservationNo, and the mandatory confirmation step before execution. This gives clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
エキテンのネット予約を登録する。事前に get_availability（予約在庫状況取得ツール）で店舗の予約可能な空き枠（reservationType・空席スロット・メニュー・スタッフ・クーポン・人数設定等）を取得してから使用すること。tableUnit（グルメ向け）かつ headcountBreakdownEnabled: true（内訳あり）の場合、headcountBreakdown の合計人数は get_availability の該当 slots[].headcountBreakdownMax を上限とする。予約方法は2通り。(1)ログインして予約する場合: email を付けずに呼び出す。未ログインなら 401 認証要求が返るので start_login を呼び、返されたloginUrlをユーザーに提示してログインを完了してもらい、完了後に再実行する（ログインすると会員情報が反映され、予約後のキャンセルも可能）。(2)ログインせず予約する場合: email（メールアドレス）を指定する。予約後に認証メールが送信される（キャンセル不可）。ユーザーにどちらで進めるか確認し、実行前に予約内容の最終確認を求めること。
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | お店へのご要望。省略可（上限2000文字） | |
| No | メールアドレス。未ログイン時は必須。ログイン済みの場合は省略可（会員登録済みアドレスを使用） | ||
| phone | Yes | 電話番号。必須。ハイフンなし。携帯・IP電話(070/080/090/050等)は11桁、固定電話(03/06等)は10桁。形式: ^(0[5-9]0[0-9]{8}|0[1-9][1-9][0-9]{7})$ | |
| menuId | No | メニューID。予約在庫状況取得ツール（get_availability）で取得した menus[] から選択したメニューの menuId を指定する。同ツールの menuSelectionRequired が true の場合は必須（false の場合は省略可） | |
| shopId | Yes | エキテン店舗ID。必須。 | |
| staffId | No | スタッフID。reservationType が timeUnit（全ジャンル向け）のみ有効。省略可（指名なし）。tableUnit（グルメ向け）の場合はトルツメ | |
| couponId | No | クーポンID。省略可 | |
| lastName | Yes | 予約者の姓。必須。 | |
| firstName | Yes | 予約者の名。必須。 | |
| headcount | No | 予約人数。tableUnit（グルメ向け）かつ headcountBreakdownEnabled: false（内訳なし）の場合のみ必須。それ以外（timeUnit、または内訳ありの場合）はトルツメ | |
| lastNameKana | Yes | 予約者の姓（ふりがな）。必須。 | |
| firstNameKana | Yes | 予約者の名（ふりがな）。必須。 | |
| reservationDate | Yes | 予約日。必須。YYYY-MM-DD 形式。 | |
| reservationTime | Yes | 予約時間。必須。HH:MM 形式。 | |
| smokingPreference | No | 禁煙/喫煙希望。reservationType が tableUnit（グルメ向け）かつ smokingSetting が separate（分煙）の場合のみ有効・必須。それ以外の場合はトルツメ | |
| headcountBreakdown | No | 来店人数の内訳。tableUnit かつ headcountBreakdownEnabled: true（内訳あり）の場合のみ必須。キーは headcountBreakdownItems[].itemKey、値は各内訳の人数（integer）。合計人数は get_availability の headcountBreakdownMax が上限。それ以外はトルツメ。例：{"adult": 2, "child": 1} |
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.
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.
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.
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.
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.
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.
指定した店舗の予約可能な空き枠を、日時・人数・メニュー・スタッフ・禁煙喫煙・クーポン等の条件で取得する。事前に 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 を呼び出す。
| Name | Required | Description | Default |
|---|---|---|---|
| since | No | 空席情報の取得開始日。YYYY-MM-DD 形式。省略時は当日。reservationDate を指定した場合はそちらが優先される。until との期間（until - since）は14日以内とすること | |
| until | No | 空席情報の取得終了日。YYYY-MM-DD 形式。省略時は当日から2週間後。reservationDate を指定した場合はそちらが優先される。since との期間（until - since）は14日以内とすること | |
| menuId | No | メニューID。指定した場合、そのメニューの限定条件（利用可能時間・曜日・日・1日の限定数）および該当時間枠の同時対応可能件数に合致する枠のみ canReserve: true とする。省略可 | |
| shopId | Yes | 店舗ID。必須。店舗検索ツールで取得した shopId を指定 | |
| staffId | No | スタッフID。timeUnit（全ジャンル向け）のみ有効。指定した場合、そのスタッフの受付可能時間および該当時間枠の同時担当可能件数に合致する枠のみ canReserve: true とする。省略可 | |
| couponId | No | クーポンID。指定した場合、そのクーポンの限定条件に合致する枠のみ canReserve: true とする。省略可 | |
| headcount | No | 予約人数。tableUnit（グルメ向け予約）かつ内訳なしの場合に指定。省略可 | |
| reservationDate | No | 予約希望日（単一日）。YYYY-MM-DD 形式。指定した場合 since / until より優先し、その日の空き枠のみ返す。省略可 | |
| reservationTime | No | 予約希望時間。HH:MM 形式。指定した場合、該当時間の枠のみ返す。省略可 | |
| smokingPreference | No | 禁煙/喫煙希望。tableUnit（グルメ向け）かつ分煙店舗の場合に指定。省略可 noSmoking / smoking / noPreference | |
| headcountBreakdown | No | 来店人数の内訳。tableUnit かつ内訳ありの場合に指定。キーは headcountBreakdownItems[].itemKey、値は各内訳の人数。省略可 |
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.
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.
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.
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.
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.
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.
エキテンの大ジャンル・小ジャンルの全件一覧を取得する。ジャンルはキーワード検索ではなく一覧から選ぶ方式。引数は不要。AIはユーザーの入力（「美容」「グルメ」等）とレスポンス内の largeGenreName / smallGenreName を照合し、該当する largeGenreId / smallGenreId を選択すること。曖昧または複数該当する場合はユーザーに確認すること。取得したIDを店舗検索ツールに渡す。【次のステップ】選択した largeGenreId / smallGenreId を使って search_shops を呼び出す。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden. It discloses that the tool takes no arguments, returns genre names and IDs, and requires the AI to perform matching and confirmation. No hidden side effects or permissions are implied, and the behavior is fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is slightly verbose, repeating the matching instruction and the next-step guidance, but each sentence carries essential operational detail. It could be tightened without losing clarity, yet it remains well-structured and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description adequately specifies the response elements (largeGenreName/smallGenreName, largeGenreId/smallGenreId) and the decision logic for handling ambiguous matches. It also explains the follow-up action, making the tool's context fully understandable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema has zero parameters, the description explicitly states '引数は不要' (no arguments required), which confirms the parameter expectation and prevents any misinterpretation. This adds clarity beyond the empty schema, though the baseline for zero parameters is already 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the full list of major and sub genres ('大ジャンル・小ジャンルの全件一覧を取得する') and explicitly distinguishes its purpose from keyword search, positioning it as a selection-from-list mechanism. It also indicates the subsequent use of the retrieved IDs, leaving no ambiguity about the tool's role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: it instructs the AI to match user input (e.g., '美容', 'グルメ') against genre names and select the corresponding IDs, and specifies to ask for confirmation if ambiguous or multiple matches. It also names the next step (call search_shops with the selected IDs), effectively guiding the agent through the workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
現在のセッションのログイン状態を解除する。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description is the sole behavioral disclosure. It clearly identifies the state-changing action (releasing login state) but does not mention side effects such as token invalidation, idempotency, or error behavior when no session exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise Japanese sentence with no filler; the action and target are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter logout with no output schema, the description gives enough to invoke the tool correctly. It lacks return/error semantics, but the operation is simple and the sibling set makes the purpose clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and 100% schema coverage, so there is nothing for the description to add; baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb (解除する, 'release/terminate') and a clear resource (現在のセッションのログイン状態, the current session's login state). It is immediately distinguishable from the sibling start_login, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to call logout versus start_login or other siblings. The intended context (after an authenticated session exists) is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
エキテンのネット予約に対応した店舗を検索する。店舗名・住所・大ジャンル・小ジャンルに加え、日時・人数の大まかな条件で絞り込み可能。取得した shopId を予約在庫状況取得・予約登録ツール（get_availability）で使用する。keyword / address / prefecture / city / prefectureCode / cityCode / largeGenreId / smallGenreId のいずれか1つ以上を必ず指定すること。日時・人数条件は任意。メニュー・スタッフ・禁煙喫煙等の詳細条件は search_shops では絞り込めないため、候補店舗ごとに予約在庫状況取得・予約登録ツール（get_availability）を使用すること。
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | 市区町村名。市区町村名で絞り込み。省略可。(例: 渋谷区) | |
| page | No | ページ数。1始まり。省略時は1 | |
| address | No | 住所。住所をフリーワードで絞り込み(都道府県名・市区町村名・町名等)。省略可 | |
| keyword | No | 店舗名。店舗名または店舗名のキーワードで検索(部分一致)。省略可 | |
| perPage | No | 1ページあたりの取得件数(最大20)。省略時は10 | |
| cityCode | No | 市区町村JISコード。市区町村JISコードで絞り込み。city・prefectureより優先。prefectureCode より優先。省略可。(例: "13113"＝渋谷区) | |
| headcount | No | 予約人数。指定した場合、その人数を受け入れ可能な店舗のみに絞り込む。グルメ予約(tableUnit)の店舗のみ判定対象。グルメ予約以外(timeUnit)の店舗は人数条件を無視して結果に含める。省略可 | |
| prefecture | No | 都道府県名。都道府県名で絞り込み。省略可。(例: 東京都) | |
| largeGenreId | No | 大ジャンルID。大ジャンルIDで絞り込み。省略可 | |
| smallGenreId | No | 小ジャンルID。小ジャンルIDで絞り込み。省略可 largeGenreId と組み合わせて使用、親子関係が不一致の場合はsmallGenreIdを優先 | |
| prefectureCode | No | 都道府県JISコード。都道府県JISコードで絞り込み。prefecture より優先。省略可。(例: "13"＝東京都) | |
| reservationDate | No | 予約日(YYYY-MM-DD形式)。指定した場合、その日に予約枠(即予約またはリクエスト予約)がある店舗のみに絞り込む。省略可 | |
| reservationTime | No | 予約時間(HH:MM形式)。reservationDateとの同時指定が必須(単独指定はエラー)。指定した場合、その日時に予約枠がある店舗のみに絞り込む。省略時はreservationDate当日のいずれかの時間に空きがあれば対象とする |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses detailed behavior: reservation date/time filters narrow results to shops with available slots, headcount filtering applies only to tableUnit shops and is ignored for timeUnit shops, and parameter precedence rules (e.g., cityCode over prefecture, smallGenreId over mismatched largeGenreId) are stated. It also warns that reservationTime alone is an error, making the tool's runtime behavior transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but not wasteful; each sentence adds necessary detail about parameter semantics or tool behavior. Some repetition (e.g., '省略可' appearing many times) is present, but it serves to keep individual parameter notes self-contained. Overall it is appropriately sized given the 13 parameters and their rules.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all input parameters and their behavioral effects, but it lacks an explicit output schema or description of the response structure beyond mentioning shopId. Given that no output schema is provided, the agent would have to infer other returned fields, though the primary use (feeding shopId to get_availability) is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 13 parameters have descriptive comments covering format examples (e.g., cityCode "13113" for Shibuya), default values, maximum constraints (perPage=20), and inter-parameter relationships such as required pairing of reservationTime with reservationDate. This goes well beyond the schema basics and fully clarifies each parameter's meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to search for shops on Ekiten that support online reservations, accepting multiple filters. It also explicitly ties the returned shopId to the get_availability tool, distinguishing it from sibling tools like reservation creation or cancellation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance on when to use the tool, including the requirement that at least one of the listed filter parameters must be specified. It also explains that detailed conditions (menu, staff, smoking) cannot be filtered here and directs users to use get_availability for those, offering clear usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ネット予約のログインを開始する。返されたloginUrlをユーザーに提示し、ブラウザで開いてログインを完了するよう案内すること。このURLは短命かつ一度きりの使い切りであり、他人と共有しないようユーザーに必ず注意喚起すること。ログイン完了後、AIは同じチャット内で予約操作（cancel_reservation等）を再実行してよい。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the one-time, short-lived nature of the loginUrl and instructs warning users not to share it, along with the post-login re-execution behavior; no annotations to contradict.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise yet comprehensive; front-loads the purpose and then gives necessary user guidance and warnings. A bit lengthy but each sentence carries essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Provides all necessary operational context: the login flow, URL properties, user instructions, and post-login behavior, despite having no annotations or parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema is empty, so there is no parameter information to add; the mention of loginUrl refers to output, so it neither adds nor misses parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States clearly that the tool starts the login process for online reservations, naming the specific action and resource, and distinguishes itself from reservation and logout tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides concrete instructions for guiding the user through the loginUrl and notes when to retry reservation operations after login, but does not explicitly state when to call this tool instead of alternatives; still fairly clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
全国の医療機関224,540件・介護事業所189,943件・保育施設（東京・大阪パイロット）を検索できるMCPサーバー。地点と半径による商圏集計にも対応。
MCP server for lacita - appointment management software
Hotel booking MCP server. Search, book, and manage reservations across 250K+ properties worldwide.
Add one secure layer between your agents and this server.
