Skip to main content
Glama

株主優待 MCP (Yutai MCP)

estimate_cross_fee

株主優待クロス取引(現物買い+信用売りを同時に建てて優待だけ受け取る手法)の手数料を試算する。

【対象範囲】 ・同一証券会社内で「買い」と「売り」の両方を建てるケースのみを計算する。証券会社をまたいだ 組み合わせ(例: 楽天で買ってカブコムで売る)は計算しない。 ・buyMethod: 'spot'=現物買い(sbi/gmo/rakuten/kabucom) / 'system_margin_then_receipt'=制度信用買い+現引き(smbcのみ) ・sellMethod: 'general_short'=一般信用(短期) / 'general_long'=一般信用(無期限・長期) / 'system'=制度信用 ユーザーへの回答時はこれらの値をそのまま出さず、日本語(現物買い、制度信用買い+現引き、短期一般信用、 無期限一般信用、制度信用)に訳して説明すること。

【sellMethod=systemの行について】 逆日歩(金額が事前に確定しない追加費用)が別途発生しうる。total はあくまで「逆日歩が0だった場合の金額」 であり、確定額ではないことを必ず説明すること。前回の逆日歩率が分かる場合は note に参考値として付くが、 将来の逆日歩を予測するものではない。

【note フィールドについて】 一般信用の売り建てが現在できない・残数が無い証券会社も除外せず参考値として計算し、その旨を note に 記載する。note が無い行は現時点で実際にクロス可能。

【日付フィールドについて】 vestingDate=権利確定日(基準日)、lastDayWithRights=権利付最終日、exRightsDate=権利落ち日。 ユーザーが「いつまでに買えばいいか」を知りたいときは lastDayWithRights を案内すること (vestingDate は権利が確定する日そのものであり、買い付けの締切ではない)。

【assumptions フィールドについて】 実際に使用した証券会社プラン設定(ゼロ革命の有無、楽天のコース、カブコムの大口優遇ランク等)を毎回 そのまま返す。呼び出し側のAIは回答時に必ずこの内容(特にユーザーによって異なりうる設定)を明示し、 実際の契約プランと違う場合は指定し直せることを案内すること。 例:「楽天は"ゼロコース"、カブコムは大口優遇なしを前提に計算しています。異なるプランをご利用でしたら教えてください」

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeYes銘柄コード。例: "7476"
dateNo約定日 (YYYY-MM-DD)。省略時は「今注文したとき」の約定日を自動算出する(JST 15:30より前なら当日、以降なら翌営業日。土日祝ならさらに翌営業日まで繰り上げる)
priceNo実勢株価を上書きする場合に指定。省略時は取得済みの概算株価を使う
unitsNoクロスする株数。省略時は minRequiredUnits(優待に必要な最小株数)を使う
gmoVipNoGMO VIPプラン。既定false
sbiVipNoSBI大口優遇(建玉5億円以上)。既定false
kabucomSorNoカブコムSOR(スマート・オーダー・ルーティング)。既定false
rakutenVipNo楽天大口優遇。既定false
rakutenCourseNo楽天のコース。既定"zero"(ゼロコース)
kabucomLargeLotNoカブコム大口優遇ランク。既定"none"
sbiZeroRevolutionNoSBIゼロ革命(電子交付設定)。既定true
rakutenPreferentialRateNo楽天優遇金利適用。既定false

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeNo
nameNo
priceNo計算に使った株価(円)。入力のpriceを省略した場合は取得済みの概算株価(現在の正確な株価ではない)を使う
messageNo計算できなかった場合の理由。このときcode以外の他フィールドは付かない
resultsNo証券会社×売り方式ごとの手数料内訳。totalの昇順
crossUnitNoクロスする株数
tradeDateNo約定日 (YYYY-MM-DD)
totalPriceNoprice × crossUnit
assumptionsNo実際に使用した証券会社プラン設定
vestingDateNo権利確定日(基準日)
exRightsDateNo権利落ち日。クロスの決済(現渡し等)を入れる日
interestDaysNo信用金利/貸株料の対象日数
lastDayWithRightsNo権利付最終日。買い付けの締切はこちら(vestingDateではない)
managementFeeMonthsNo事務管理費がかかる月数

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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 thoroughly: it warns that sellMethod=system incurs 逆日歩 risk and that total is only the 逆日歩=0 figure, discloses the note-field caveat for brokers that cannot currently short-sell, and explains that assumptions are echoed back each call. This is exactly the non-obvious behavioral context an agent needs.

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?

Long, but front-loaded with the core purpose and organized under clear 【...】 headings that map to specific concerns. Some segments are instructions to the answering AI about response phrasing rather than tool-selection content, which slightly dilutes focus, but the size is largely justified for a 12-param tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, yet the description goes further and explains the non-self-evident output fields (dates, note, assumptions) and how they should be interpreted. Nothing an agent needs in order to call this tool and interpret the result is missing.

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%, so the 12 input parameters are already documented; the baseline is 3. The description adds meaning for output-side fields (vestingDate, lastDayWithRights, exRightsDate, assumptions) but adds little for the actual input parameters beyond what the schema states.

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 the 【対象範囲】 section explicitly bounds the scope to same-broker spot-buy + margin-sell combinations. The siblings (calc_dates, get_benefit, search_benefits) cover entirely different resources, so the agent can route correctly without ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit exclusion (証券会社をまたいだ組み合わせは計算しない) and clarifies which buyMethod/sellMethod cases are in scope. However, it never names an alternative tool for the cases it declines, so the when-not is stated but the redirect is left to inference.

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