エキテン（日本全国のお店・施設の情報サイト）のネット予約を提供するMCPサーバー。オールジャンルの日本国内店舗・施設が対象。店舗検索・空き確認・予約登録・キャンセルに対応。
ログイン済みユーザーの予約をキャンセルする。未ログインユーザーはキャンセル不可（ログインしていない場合は 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 of disclosing behavior. It mentions the prerequisite of login, the need for confirmation (implying destructive action), and the fallback to start_login. However, it does not explicitly state the irreversible nature of cancellation or any potential side effects beyond the cancellation itself.
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 concise yet complete, with each sentence serving a distinct purpose: stating the action, specifying login requirements, identifying the parameter source, and mandating user confirmation. No redundant information is present.
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 the tool's purpose, prerequisites, parameter source, and confirmation requirement. However, since there is no output schema, it does not mention what the tool returns (e.g., success/failure, updated reservation status), leaving a minor gap in completeness.
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 single parameter reservationNo has a description that fully explains its meaning and source (from create_reservation's response), covering 100% of the schema. The description adds value by clarifying the required provenance of the value.
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 cancels a reservation for a logged-in user, using the verb 'キャンセルする' (cancel) and the specific resource '予約' (reservation). It is distinct from sibling tools like create_reservation and start_login.
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 guidance: it notes that unauthenticated users cannot cancel and instructs to call start_login and present the loginUrl. It also specifies that reservationNo should come from create_reservation's response and requires user confirmation before execution.
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?
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.
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.
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.
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.
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.
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.
指定した店舗の予約可能な空き枠を、日時・人数・メニュー・スタッフ・禁煙喫煙・クーポン等の条件で取得する。事前に 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 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.
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.
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.
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.
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.
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.
エキテンの大ジャンル・小ジャンルの全件一覧を取得する。ジャンルはキーワード検索ではなく一覧から選ぶ方式。引数は不要。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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
cancel_reservationcreate_reservationget_availabilityget_genreslogoutsearch_shopsstart_loginClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
MCP server for lacita - appointment management software
Hotel booking MCP server. Search, book, and manage reservations across 250K+ properties worldwide.
日本の住所と郵便番号を相互変換するMCPサーバー。住所から郵便番号を検索、郵便番号から住所を逆引きします。
株式会社一創（issoh.co.jp）の技術記事・サービス・制作実績を検索できる MCP サーバー。システム開発・AI・クラウド・Web 制作の日本語情報
Add one secure layer between your agents and this server.
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.
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.
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.
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.
