Rule Trade - Japanese equity verification layer

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.

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 transparently discloses key constraints: 1 business day delay, only top 3 by deviation rate, no price/volume data, and that it is not investment advice. It does not mention return format or error behavior, but the disclosed limitations are substantial.

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?

Three compact sentences: the first states the core function, the second lists restrictions, and the third is a necessary legal disclaimer. Every sentence serves a purpose, with no redundant or filler content.

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 two optional parameters and no output schema, the description offers enough context for an agent to invoke it correctly and know what to expect: returned stocks, watch candidates, and the free-tier limitations. Minor gaps remain around return field details and ordering, but these are not critical given the tool's simplicity.

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 both parameters fully (100% coverage), including the bnf enum for strategy and the judge=watch meaning for include_watch. The description aligns with these definitions but does not add meaningful new parameter semantics 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 'returns' stocks matching the public BNF 25-day deviation rule and watch candidates, with explicit resource scope. It distinguishes itself from siblings like get_anomaly_summary and get_market_regime by focusing on daily rule hits rather than anomalies or market conditions.

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: if you need the daily list of rule hits, use this tool. It provides context about the free version's limitations (1-day delay, top 3 only, no trading info), but it does not explicitly state when to choose this over alternative tools or mention any exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations, the description carries the disclosure burden, and it does reasonably well: it says the data is updated intraday by the production system, returns specific market fields, explicitly excludes stock names, and notes the optional history behavior. It does not describe the response shape, but for a read-only getter the behavioral exposure is solid.

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?

Two short sentences deliver all the essential information: what is returned, what is excluded, and the optional history. No filler; the most important output fields are named in the first clause.

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, no annotations, and no output schema, the description is nearly sufficient: it tells the agent what it will receive and how to ask for history. The main gap is the absence of an exact response structure, but the low complexity keeps this from being a major omission.

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 sentence 'オプションで日次履歴も返す' mostly restates the schema's history_days description and adds little new semantic detail beyond connecting the parameter to the output.

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 resource (market environment status) and lists the exact fields returned: regime, circuit-breaker/HALT state, VIX, Nikkei average, and daily signal count. The title adds the regime enum (BULLISH/NEUTRAL/BEARISH/PANIC), and the explicit 'does not include stock names' distinguishes this market-level tool from likely stock-level 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?

No guidance is given about when to prefer this tool over siblings such as get_anomaly_summary or get_daily_signals. The 'market regime' framing implies a use case, but the description never states conditions, prerequisites, or alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

There are no annotations, so the description carries the full burden. It does disclose what the tool returns and that it is intended as an initial informational call, which implies a non-mutating guide. However, it does not explicitly state side-effect-freedom or response format, so the behavioral disclosure is adequate but not rich.

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 a single well-structured sentence that front-loads the main purpose and then lists the specific content categories. It also adds the usage expectation without redundancy.

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 guide tool, the description covers the key aspects: what is returned, the scope of content, and when to call it. It is slightly light on return format expectations, but no output schema exists and the tool's purpose is simple enough that 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 tool has zero parameters, so there is no parameter semantics for the description to clarify. This matches the baseline for 0-param tools; the description appropriately focuses on output content.

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 specifies the verb (返す/returns), the resource (this server's tool explanations, data update timing/delay, free-version limits, disclaimers, roadmap), and is immediately distinguishable from the data-focused sibling tools. An agent can tell this is a meta/guide tool rather than a signal-retrieval 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?

The description explicitly states the intended invocation timing: '最初に一度呼ぶことを想定' (assumed to be called once at the beginning). This gives clear contextual guidance, though it does not explicitly name alternative tools for when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.