patternfetch

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

With no annotations, the description carries full burden. It discloses that the tool returns a distribution (win-rate, median, etc.), is not a prediction, and includes a disclaimer about past performance. It does not contradict any annotations since none exist. The description adequately conveys the tool's read-only and informational nature.

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 three sentences, front-loaded with the core action. Every sentence adds value: purpose, usage guidance, an example, and a disclaimer. There is no redundancy or 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?

Given 5 parameters, no output schema, and no annotations, the description partially covers the tool's context. It explains the return format (distribution stats) and usage context but lacks explanations for several parameters (window, horizon, market). This leaves gaps for the agent to fully understand inputs and 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 description coverage is 0%, so the description must compensate. Only 'ticker' and 'timeframe' are mentioned via an example; 'window', 'horizon', and 'market' (with enum) are not explained. Without further details, the agent cannot correctly configure the required and optional parameters.

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 finds historical windows resembling current price action and returns the full distribution of outcomes. It explicitly distinguishes from prediction and backtest, aligning with sibling tool names that suggest other patternfetch variants. The purpose is specific and unambiguous.

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 guidance: 'an agent wants historical context for a setup.' It also clarifies what the tool is NOT (prediction, backtest, advice). However, it does not directly name sibling tools as alternatives, though the context is implied.

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?

No annotations provided, so description bears full burden. It details market coverage (US stocks/ETFs with adjustments, crypto spot), data recency (delayed/EOD vs realtime), and clarifies the output is impersonal data, not investment advice. Could mention that it does not perform any actions, but it's implied.

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?

Description is well-structured with clear sections (output, coverage, when, examples). It is somewhat long but front-loads the main purpose. Every sentence adds 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?

Given no output schema and multiple output elements (candles, patterns, base rates, supports, trends, indicators), the description thoroughly lists what is returned. It covers use cases, exclusions, and market specifics, making it complete for the tool's complexity.

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 has 0% description coverage for parameters. The description partially compensates by explaining ticker and timeframe through examples, but does not clarify the 'market' enum values or the 'limit' parameter. Agent may be left guessing.

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 a token-compact market-state brief with specific outputs (candles, patterns, support/resistance, etc.). The name 'brief' and description distinguish it from siblings like 'analogs', 'capabilities', 'delta', and 'multi' which likely provide other functionalities.

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 provides WHEN and WHEN NOT guidance: 'when an agent needs the current technical picture' and 'when not: you need order execution or portfolio advice'. Also includes examples clarifying usage.

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?

No annotations are provided, so the description carries full burden. It discloses that the tool requires no input and is a discovery call with no mention of side effects or mutations. While it is transparent about the lack of input, it does not explicitly state that the operation is read-only or safe, but the context strongly implies it.

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 extremely concise: two sentences, no superfluous words. It front-loads the key directive 'Call this FIRST' and specifies the output (supported assets, timeframes, endpoints, limits) and intended order relative to siblings.

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 tool's simplicity (no params, no output schema), the description fully covers what the agent needs to know: when to call it, what it provides, and that no input is needed. It is complete for its purpose.

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 schema coverage is effectively 100%. The description correctly states 'No input required,' which is sufficient. Per the guidelines, baseline for 0 parameters is 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's purpose: to discover supported assets, timeframes, endpoints, and limits. It also explicitly distinguishes this from its siblings by instructing to call it first before the other tools (brief/delta/analogs/scan).

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 usage guidance: 'Call this FIRST to discover... before calling brief/delta/analogs/scan.' It also notes that no input is required, making the usage conditions very clear.

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?

No annotations provided, so description carries full burden. It discloses that the tool returns 'changed=false when nothing material changed' and marks data as 'impersonal data, not advice'. It implies a read-only operation but does not explicitly state it. Lacks details on rate limits or side effects, but is not misleading.

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, front-loaded with core purpose, and uses efficient 'WHEN / WHEN NOT' pattern. Example and disclaimer are included. Some redundancy could be trimmed, but overall well-structured.

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?

No output schema, so description should explain return structure beyond the single 'changed' flag. It mentions only one possible return value (changed=false). Also, partial parameter documentation leaves gaps. For a simple delta tool, it covers essential use but lacks full 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?

Schema description coverage is 0%, so description must compensate. It only mentions ticker and timeframe in an example, ignoring 'limit' and 'market' parameters. No descriptions for parameter types, valid values, or purposes beyond property names. This is insufficient for correct invocation.

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?

Description clearly states 'Get only what CHANGED since your last brief for a ticker+timeframe', specifying verb, resource, and scope. It distinguishes from siblings via the 'WHEN NOT: first look at a market (use brief)' directive, differentiating it from patternfetch_brief.

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 provides 'WHEN' and 'WHEN NOT' contexts: use for repeated polling after an initial brief, not for first look. This guides agent decision-making and names the alternative tool (patternfetch_brief).

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?

No annotations provided, so description bears full burden. It discloses output is impersonal descriptive data, not a signal to act. Describes token-compact briefs and alignment read. Could explicitly state read-only nature, but overall 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?

Description is front-loaded with purpose and includes WHENS, but becomes slightly verbose with example and double-underscore formatting. Could be trimmed without losing 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?

Given no output schema or annotations, the description adequately covers input (ticker, timeframes), output (per-timeframe briefs + alignment), and limitations (not advice). Missing details on return structure for 'limit' and 'market' 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?

Schema has 4 parameters with 0% description coverage. Description only explains 'ticker' via example and 'timeframes' with defaults. Does not define 'limit', 'market', or valid timeframe values. Agent would need to guess parameter constraints.

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 specific verb 'Get' and resource 'multi-timeframe market-state view', including per-timeframe briefs and cross-timeframe alignment. It clearly distinguishes from sibling tool 'brief' by contrasting multi vs single timeframe.

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 WHEN to use ('agent wants to know if a setup is confirmed across horizons') and WHEN NOT ('only care about one timeframe, use brief'). Provides example and clarifies it's not investment advice.

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?

No annotations provided, so description carries full burden. It discloses it's a precomputed daily screener over a curated universe, fast and cheap, and states it's impersonal historical data not investment advice. Missing explicit statement about side effects (though inherently read-only), but sufficient for safe invocation.

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?

Description is detailed but well-structured: begins with core purpose, then explains behavior, usage guidelines, example, and disclaimer. Slightly verbose but front-loaded with key info. Every sentence adds 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?

Despite no output schema, the description fully specifies the output format (each row's fields and ranking). Explains filter parameters, source universe, and provides an example. Covers all necessary context for an agent to understand what the tool returns and how to use it.

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 0%, so description must compensate. It explains assetClass, regime, pattern, minBaseRate, and limit with purposes and constraints. However, the 'tf' parameter from the schema is not mentioned in the description, leaving one parameter unexplained. Overall, adds significant meaning beyond enum values for most parameters.

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 it scans US stocks, ETFs, and crypto for tickers in a given regime or pattern, ranked by base rate. It explicitly contrasts with lookup ('discovery, NOT lookup') and distinguishes from sibling 'brief' tool. Verb+resource is specific, and sibling differentiation is present.

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 when to use ('an agent wants to FIND candidates across the market') and when not ('you already have a specific ticker, call brief'). Provides an example query. Clear usage guidance.

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