Verified Japanese equity studies: 50 anomalies, 26 indicators, 12 candlesticks, events, ETF decay.
Scored across 8 tools
Each tool targets a clearly distinct verification domain: calendar anomalies, candlestick patterns, technical indicators, event reactions, ETF decay, daily signals, market regime, and a meta guide. Even the three 'verdict' tools are easily separable by their subject matter and input filters.
Tool names follow a highly predictable get_<domain> pattern in lowercase snake_case, with list_tools_guide as the only intentional and readable exception for a meta tool. There are no vague generic names or mixed naming conventions.
Eight tools is well-scoped for a specialized Japanese equity verification layer. Each tool earns its place by covering a distinct area of analysis, and there is no sense of bloat or excessive fragmentation.
The set covers the major verification categories—anomalies, candlesticks, indicators, event reactions, ETF decay—plus current market regime and daily signals. Minor gaps exist, such as the deliberate restriction to only one current signal candidate and the lack of a generic custom-rule backtest tool, but these are workable constraints rather than fatal omissions.
日本株の言い伝え(アノマリー/ジンクス)50本を61年分の日経平均データで検証した結果(判定・勝率・平均リターン・標本数・p値)を返す。name を渡すとその名前を含むものだけに絞り込める(例: セルインメイ, 節分天井, 干支)。あわせて、5つの暴落前兆(逆イールド・CAPE・信用膨張・過熱・引き締め)の点灯状況と、着火メーター(7フラグ・20営業日以内に-10%が起きた過去の割合)の現在値も返す。detail=true で年代別の内訳・統計表・書籍上の根拠を含める。返すのは判定結果と統計値のみで、価格系列や財務値は含まない。
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | アノマリー名またはカテゴリの部分一致で絞り込む(例: セルインメイ / 節分 / 曜日 / 都市伝説)。省略すると全50本の要約を返す | |
| detail | No | 年代別の内訳(extra)・中央値/標準偏差/対照群・書籍上の根拠(book)・着火メーターの統計表と履歴を含めるか |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and handles it well. It states that the tool returns only judgments and statistics, explicitly excludes price series and financial values, and describes what detail=true adds. The read-only nature is clear from '返す' and the absence of side effects.
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 compact but information-dense: main return contract, filtering, crash-precursor data, optional detail mode, and explicit exclusions. Each sentence earns its place, and key information is 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?
There is no output schema, so the description must define the response scope, and it does. It lists the exact stats returned, names the five crash precursors, defines the ignition meter, covers both optional parameters, and states what is deliberately excluded. An agent has enough to call and interpret the result correctly.
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 adds no substantially new parameter meaning beyond the schema: it repeats the partial-match filter for name and the detail contents for detail. It is consistent but does not elevate understanding beyond the input 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 names a specific verb (返す) and a precise resource: verified results for 50 Japanese stock-market anomalies based on 61 years of Nikkei data, plus crash-precursor indicators and an ignition meter. It clearly distinguishes this from siblings by specifying the exact metrics and optional filters.
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 gives clear context for when the tool is appropriate: when an agent needs anomaly validation statistics, crash-precursor lights, or the ignition meter value. It does not explicitly name sibling tools or state when not to use them, but the described scope is specific enough that confusion with get_daily_signals, get_market_regime, or list_tools_guide is unlikely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
三尊天井・赤三兵・三空叩き込みなど酒田五法12本を東証プライム1,550銘柄・10年半で検証した結果を返す。取引回数・勝率・PF・平均超過収益・p値・負け年・5つの採用基準のどれで落ちたか・不採用の理由を含む。12本すべてが採用基準を満たさなかった(採用ゼロ本)。最も PF の高い三空叩き込み(PF 3.04)も、期間を前半と後半に分けると符号が反転するため不採用としている。pattern を渡すとその形だけに絞り込める(日本語・英語の別名可。例: 三尊, head and shoulders, 赤三兵)。detail=true で保有日数別・相場環境別の内訳を含める。銘柄名・銘柄コード・価格は含まない。
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | 保有日数別(5/10/20営業日)の内訳・75日移動平均で分けた相場環境別の内訳・検証に使った規定値を含めるか | |
| pattern | No | 形の名前で絞り込む(部分一致・日英の別名可。例: 三尊 / 逆三尊 / 三空 / 赤三兵 / morning star)。省略すると12本の一覧を返す |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full disclosure burden and does so thoroughly. It reveals that all 12 patterns were rejected, that the highest-PF pattern flips sign when the period is split, and that it excludes ticker names, codes, and prices, which helps an agent set correct expectations.
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 yet every sentence earns its place: scope, result fields, headline conclusion, filter behavior, detail option, and exclusions are all covered. It is front-loaded with the most important scope and verdict.
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, so the description must explain return values; it lists the exact metrics and the inclusion/exclusion rules. Combined with parameter descriptions and a clear filter example, an agent can call this tool correctly without needing further documentation.
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 already has 100% description coverage, the description adds semantics beyond it by clarifying that pattern supports partial matches and Japanese/English aliases, and by re-stating what detail=true adds. This is useful, but the schema already carried most of the payload.
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 very specific action and resource: it returns verification results for 12 Sakata Five Sakata candlestick patterns across 1,550 TSE Prime stocks over 10.5 years. It clearly distinguishes itself from the sibling tools by describing candlestick-specific output rather than generic signals or indicators.
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 makes the use case clear by listing the exact result fields and the zero-adoption conclusion, so an agent knows this is the tool for candlestick-pattern backtest statistics. It does not explicitly name sibling tools or state when not to use it, so it lacks full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
公開ルール(BNF 25日線乖離が -15% 以下)に該当した銘柄を返す。★返すのは1件だけ★(該当した全銘柄の一覧は配布しない)。件数は返すので「今日は何件あったか」は分かる。1営業日遅れ(前営業日の終値で判定)。価格・株数・利確/損切ラインは含まない。該当は機械的な条件への一致であって、売買の判断ではない。
| Name | Required | Description | Default |
|---|---|---|---|
| strategy | No | ルール名。現在は bnf(25日線乖離の逆張りルール)のみ | bnf |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden and does a strong job by disclosing the one-item limit, the presence of a count, the one-business-day delay, and the absence of price, quantity, and profit/loss lines. It also clarifies that matching is mechanical, not investment advice. The only gap is the exact response format.
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 efficient, front-loading the core purpose and then listing caveats in compact sentences. The attention markers and parentheticals help highlight the most important constraint without adding redundant text.
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 tool with one optional parameter and no output schema, the description conveys the essential constraints an agent needs: single result, count, delay, excluded data, and non-advisory nature. It is slightly incomplete regarding the exact fields of the returned item, but 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?
The input schema already covers its single parameter fully with an enum and description, so the baseline is 3. The description reinforces the rule context but does not add new parameter-level semantics beyond what the schema already states.
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: it returns stocks matching the public BNF rule (25-day moving average deviation <= -15%). It also clearly differentiates itself by emphasizing that it returns exactly one item, not the full list of matches, which distinguishes it from potential list-returning sibling 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?
The description gives useful context for usage: it returns one item, includes a count of matches, is one business day delayed, and excludes certain data. However, it never explicitly names sibling tools or states when to choose this tool over alternatives like get_anomaly_summary or list_tools_guide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
日経ダブルインバース(1357)などレバレッジ・インバース型ETFを12年・2,964営業日ぶん実測した結果を返す。年別の理論値と実績・保有日数別の勝率と理論との乖離・地合い条件別の PF と最大ドローダウン・「戻るまで待つ」を305回試した結果を含む。日々の値動きを2倍にする商品なので、上下を往復するだけで元に戻らない(日経が+10%のあと-9.1%で元の水準に戻る2日間で、100→80→94.5)。検証結果には各節の「解釈で注意すべき点」を必ず添えて返す(日経が12年で約4倍になった上昇相場のデータであるため)。detail=true で地合い条件別の72通りを含める。日足の価格系列と個別株の銘柄情報は含まない。
| Name | Required | Description | Default |
|---|---|---|---|
| code | No | 検証対象のETF(1357=ダブルインバース / 1570=レバレッジ)。省略すると両方を含む全体を返す | |
| detail | No | 地合い条件別(75日線割れ初日・200日線割れ初日など8条件 × 保有日数4 × コスト2 = 72通り)の PF と最大ドローダウンを含めるか |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden and does so richly: it reveals the tool always appends per-section interpretation caveats, notes the bull-market bias of the sample (Nikkei roughly 4x over 12 years), includes a worked decay example, includes 305 rebound-wait trials, and states that detail=true adds 72 combinations. This goes well beyond a generic 'returns results' phrasing.
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 longer than average but every sentence earns its place: a lead summary, output inventory, a compact numerical decay illustration, a mandatory caveat, the detail toggle, and clear exclusions. It is front-loaded and well organized enough to absorb without effort.
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 there is no output schema and no annotations, the description fully compensates: it enumerates the result sections, explains optional detail output, warns about interpretational limits, and states what is not included. An agent has enough information to invoke this tool correctly and understand what it will receive.
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 already documents both parameters, including the 72-combination breakdown for detail and the ETF code meanings. The description adds no new parameter semantics beyond restating that detail=true includes extra condition results, so the 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?
The description states a specific verb and resource: it returns 12-year/2,964-day measured results for leverage/inverse ETFs such as 1357 and 1570. It lists the main output categories and explicitly excludes daily price series and individual stock data, making it easy to distinguish from siblings.
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 intended use is clearly implied: when a user needs long-horizon decay analysis for leveraged/inverse ETFs rather than daily signals or market regime data. The description also gives guidance on when to set detail=true and explicitly states what the tool does not provide, although it does not name sibling tools as alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ある出来事のあとに何が起きたかを、3つの検証からまとめて返す。(1)出来事27種 — 地震・利上げ・円安・関税・パンデミックなどのあと、市場全体を上回る動きがあったか。判定は 持続型/初動型/不発/逆行/市場全体のみ の5種類と、5つの窓(当日/翌日/5営業日後/1か月後/3か月後)の超過収益・勝率・p値。(2)決算後のドリフト — 決算発表のあと値動きが続くか。約26,000件の決算で検証。(3)指数の入替 — TOPIX の採用・除外でいつ・どちら向きに動くか。3つは別々のデータから同じ形を示している: 反応は出来事を通過する前か、ごく初期に終わる。出来事27種の「初動型」は翌朝の寄り付きで終わり、決算後のドリフトは+5日で統計的に消え、指数の入替は実施日で止まる。event を渡すと絞り込める(例: 地震, earthquake, 利上げ, 決算, PEAD, TOPIX, 日経225)。省略すると3つの見出しを返す。銘柄名・銘柄コード・銘柄バスケットは含まない。返すのは分類と統計だけ。
| Name | Required | Description | Default |
|---|---|---|---|
| event | No | 出来事の名前で絞り込む(部分一致・日英の別名可)。出来事27種: 地震 / earthquake / 利上げ / 円安 / 関税 / パンデミック など。決算後のドリフト: 決算 / earnings / PEAD。指数の入替: TOPIX / 日経225 / 除外 / 採用。省略すると3つの検証の見出しと、出来事27種の一覧を返す | |
| detail | No | 絞り込んだときに、分類前の全標本数・各窓での市場全体の動き・決算の区分別内訳(発表時刻/四半期/規模/期間)とルール別の成績まで含めるか。event を省略したときは効かない(全件の詳細は 50KB を超えるため) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds valuable context: it explicitly states that the tool does not include stock names/codes/baskets and returns only classifications and statistics. It also discloses a practical limitation—the detail parameter is ignored when event is omitted because full details exceed 50KB. This goes beyond the schema and gives the agent important expectations about output scope.
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 and well-structured, using numbered lists to enumerate the three verifications and a clear summary of the common pattern. While long, every sentence carries necessary information, and the filtering instructions are front-loaded after the purpose. It is appropriately sized for the complexity of the tool.
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 tool with no output schema and no annotations, the description covers the essential aspects: what it does, what it returns, how to filter, what it excludes, and behavioral limitations (50KB). It explains the default behavior when event is omitted. This is sufficient for an agent to call the tool correctly, though a more explicit return format would make it fully complete.
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%, so the baseline is 3. The description adds extra meaning beyond the schema: it clarifies the filtering semantics with examples (e.g., 地震, PEAD, TOPIX) and explains why detail is ignored without an event (50KB size constraint). This enriches the parameter understanding beyond what 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 clearly states the tool's purpose: it returns what happened after an event based on three distinct verifications (27 event types, post-earnings drift, index changes). It specifies the output (classifications and statistics) and explicitly notes what it excludes (stock names/codes/baskets). This distinguishes it from sibling analysis tools, which focus on other aspects like anomalies or candlestick patterns.
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 clear instructions on how to use the tool: pass an event to filter, or omit to get three headings. It also explains the behavior of the 'detail' parameter. However, it does not explicitly compare this tool with alternatives or state when to prefer it over sibling tools, leaving the choice to the agent's judgment based on the tool's name and focus.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
RSI・MACD・移動平均クロス・ボリンジャーバンドなどテクニカル指標26種を、教科書どおりの買い方で TOPIX500・10年・約50万回の売買として検証した結果を返す。勝率・期待値・PF・ランダムな売買との超過収益を、出口2種類(20営業日で手仕舞い / 8%トレーリング)で返す。判定は 使える9個 / 条件付き4個 / 捨てろ13個 の3段。「使える」の基準は8区分(出口2 × 上昇/下落/前半/後半)すべてで超過収益が +0.3% を超えること。捨てろ13個には入門書の最初に出てくる指標が並んでいる。name を渡すとその指標だけに絞り込める(日本語・英語の別名可。例: RSI, 一目, ichimoku, 乖離率)。detail=true で8区分すべての内訳を含める。銘柄名・銘柄コード・価格は含まない。
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | 指標名またはカテゴリで絞り込む(部分一致・日英の別名可。例: RSI / MACD / ボリンジャー / オシレーター / volume)。省略すると26種の一覧を返す | |
| detail | No | 8区分(出口A・B × 上昇/下落/前半/後半)それぞれの超過収益を含めるか |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description bears the full burden. It extensively discloses the methodology: backtest on TOPIX500 over 10 years, ~500,000 trades, exit strategies (20-day or 8% trailing), and the exact criteria for 'usable' (excess return >0.3% in all 8 segments). It also notes that the 'discard' category includes common beginner indicators)SkipThe description is transparent about what it returns and excludes. One minor gap: it doesn't specify whether the tool is read-only or compute-intensive, but that's not expected for a non-annotation tool.
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 well-structured: it starts with the core purpose, then metrics, exit types, classification, criteria, and optional parameters. Every sentence adds critical information without redundancy. It's longer than typical, but given the complex domain, it earns its length. The key facts are front-loaded (purpose) and the parameter details are at the end, which is logical.
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 tool has a complex behavior: multiple metrics, multiple segments, and a decision criterion. The description covers all necessary aspects: the dataset, the metrics, the exit strategies, the classification logic, the filter options, and what is excluded. Since there is no output schema, the description does the job of explaining the return format (though not literally a schema). The sibling tools (get_daily_signals, get_market_regime) are distinct, and the description makes clear this is about indicator evaluation. Given the lack of an output schema, the description is sufficiently complete for an agent to invoke it correctly.
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 schema already documents both parameters. The description adds value by clarifying the behavior of the name parameter: it supports partial matching, Japanese/English aliases, and gives concrete examples (RSI, 一目, ichimoku, 乖離率). It also explains what happens when omitted (returns full list). The detail parameter is explained (includes 8-segment breakdown) but the schema already covers that; the description reinforces it.
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 performs backtesting of 26 technical indicators on TOPIX500 over 10 years, returning win rates, expectancy, PF, and excess returns. It also explains the three-tier verdict (usable, conditional, discard) and mentions specific metrics. This distinguishes it from siblings like get_market_regime or get_candlestick_verdict, which likely focus on other analyses.
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 explains when to use the tool: when one needs verdicts on technical indicators' effectiveness. It also clarifies that it does not provide stock names, codes, or prices, so users needing those should use other tools. It implicitly suggests it's for indicator evaluation, not signal generation (unlike get_daily_signals). The description is explicit about optional filters (name, detail), making usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
本番システムが日中に更新している相場環境の判定、サーキットブレーカー(HALT)状態、VIX、日経平均、当日シグナル件数を返す。あわせて3軸スコア(トレンド・短期リスク・需給をそれぞれ -2〜+2 で採点し、合計 -6〜+6 を5段階に分けたもの)と、各軸がその点数になった理由・5営業日以内の大型イベントを返す。銘柄名は含まない。オプションで日次履歴も返す。相場の予想ではない。
| Name | Required | Description | Default |
|---|---|---|---|
| history_days | No | 直近N日分の地合い履歴を含める(0=含めない、最大60) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses scope boundaries ('does not include stock names', 'not a market forecast') and notes the underlying data is updated by the production system intraday. It does not explicitly state read-only behavior, return format, freshness guarantees, or failure semantics, but for a 'get' tool this is a moderate gap rather than a fatal flaw.
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 organized: it front-loads the main output components, adds the score breakdown, then optional history, and closes with a caveat. Some redundancy with the title's enumerated modes exists, but the sentences all carry useful scope 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?
For a simple optional-parameter read tool with no output schema, the description covers the main result set and important exclusions well, including the 3-axis scoring scale and event window. It could be more complete by specifying the exact response structure or threshold mapping, but nothing an agent needs to invoke the tool correctly is missing.
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?
There is only one optional parameter, and the schema already documents history_days fully with default, range, and description. The description's phrase 'オプションで日次履歴も返す' adds minimal added meaning over the schema, so 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?
The description identifies a specific resource (market regime/environment) and enumerates concrete outputs: judgment, HALT state, VIX, Nikkei average, signal count, 3-axis score, reasons, and events. It is clear about what the tool returns, though it does not explicitly contrast itself with sibling 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?
The description implies usage context: it is a market-level, non-forecast snapshot tool that deliberately excludes stock names, which helps an agent avoid using it for individual-stock or predictive questions. However, it never states when to prefer this tool over siblings like get_daily_signals or get_event_reaction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
このサーバーの全ツール(8本)の説明、データの更新タイミングと遅延、返さないものの一覧、免責事項、今後の予定を返す。最初に一度呼ぶことを想定。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that it returns a list of what is not returned ('返さないものの一覧') and mentions data update timing and delay, which are behavioral details. It implicitly indicates a read-only operation without side effects, though it does not state this explicitly. This is adequate for a guide tool.
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, compact Japanese sentence that lists all the returned content categories and includes the usage instruction. Every clause contributes to the purpose, and it is front-loaded with the main content list. No wasted words.
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 it has no parameters, no output schema, and no annotations, the description adequately explains what the tool returns: tool descriptions, update timing, exclusions, disclaimers, and future plans. It could mention the format or length of the response, but for a guide tool, this is sufficiently complete for an agent to know what to expect.
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 0 parameters, so the baseline is 4 per the rubric. The description adds no parameter-specific information, but none is needed. The schema coverage is trivially 100% with an empty 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 clearly states the tool returns descriptions of all 8 tools, data update timing/delay, a list of what is not returned, disclaimers, and future plans. The verb '返す' (returns) and the resource list make it unambiguous. It distinguishes itself from the sibling get_* tools which return specific analyses, while this is a meta/guide tool.
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 says it is assumed to be called once at the beginning ('最初に一度呼ぶことを想定'). This gives clear when-to-use context. However, it does not mention when not to use it or provide alternatives, but given its unique role as a guide, the usage is clear enough.
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.
get_candlestick_verdictget_daily_signals1 field changedInput schema / properties / include_watchRemoved value: -{
- "default": true,
- "description": "ルール未達だが乖離が大きい監視候補(judge=watch)も含めるか",
- "type": "boolean"
-}get_etf_decayget_event_reactionget_indicator_verdictget_anomaly_summaryget_daily_signalsget_market_regimelist_tools_guideSearch 5,000+ trading papers with verified backtests, strategies, datasets, and courses.
Praxis: published trading strategies re-run and audited — verdicts, claimed vs measured stats.
Japan business days & holidays (official Cabinet Office data). Free tool + x402 USDC paid tools.
Validated trading edges across futures, equities, crypto. Live signals, full audit trail.
Add one secure layer between your agents and this server.
