Quant price analysis for agents: TheStrat price action, multi-timeframe signals, simultaneous breaks
Scored across 15 tools
Several signal-screening tools overlap in purpose: buy_sell_list, find_signals, signals_in_force, potential_signals_next_bar, sim_setups, and sim_breaks all deal with signals/setups across symbols or timeframes. Descriptions help differentiate them, but an agent could still misselect among them; most other tools are clearly distinct.
All names use snake_case, but conventions are mixed: some are verb_noun (find_signals, classify_bars, resample_bars), some are noun phrases (exhaustion, sector_analysis, signals_in_force, timeframe_continuity), and docs_search is noun_verb. Readable, but not a predictable pattern.
15 tools sits at the top of the preferred 3–15 range and is reasonable for a specialized trading-analysis server. A few overlapping signal tools could potentially be consolidated, but the count is not excessive.
The surface covers bar classification, resampling, price description, signal discovery/in-force/potential, simultaneous breaks/setups, sector analysis, timeframe continuity, exhaustion, and docs/meta decisions. Minor gap: no explicit tool for fetching or listing symbols/bars, but the analysis lifecycle is otherwise broad.
Buy list and sell list: reversal signals in force across timeframes (technical signals screener on your own data). Buy: hammer, 2d-2u, 3-2u, 1-2u in force. Sell: shooter, 2u-2d, 3-2d, 1-2d in force. Continuations (2u-2u, 2d-2d) do not count. Per timeframe: symbols, count, % of basket, trigger, target and level of reclaim; plus which timeframes each symbol is on.
| Name | Required | Description | Default |
|---|---|---|---|
| now | No | Current time, ISO 8601. Decides if the last bar is still open. Default: the server clock. | |
| as_of | No | Optional ISO time. Use only bars that start at or before this time (replay a past bar). | |
| basket_by_timeframe | Yes | Bars per timeframe, then per symbol: {"M": {"AAPL": [...], ...}, "W": {...}}. Up to 4 timeframes; 60 symbols and 500 bars per symbol each. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the output composition (symbols, count, percent of basket, trigger, target, reclaim level, and timeframes per symbol) and the signal inclusion criteria, but it does not explicitly state read-only behavior, performance limits, or data-handling constraints.
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 appropriately front-loaded with the core purpose, followed by pattern criteria and output details. The pattern enumerations are necessary domain content rather than filler, though the semicolon-separated structure could be easier to scan.
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 a complex nested basket input, no output schema, and no annotations, the description does well to explain the signal criteria and the returned fields per timeframe. Remaining parameter details are covered by the fully documented schema, so the definition is nearly complete for correct 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 description coverage is 100%, so the schema already explains now, as_of, and basket_by_timeframe in detail. The description adds no parameter-specific syntax or defaults beyond implying that the screener operates on the user's basket data, so the baseline score of 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 analytical operation: producing buy and sell lists of reversal signals in force across timeframes from the user's own bar data. It clearly defines buy patterns versus sell patterns, but it does not distinguish this tool from close siblings such as signals_in_force or find_signals.
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 by explaining which patterns count as buy or sell signals and that continuations do not count. However, it gives no explicit guidance on when to choose this tool over alternatives like signals_in_force or find_signals, and no exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Label every bar as TheStrat scenario 1, 2u, 2d or 3 (Truth #1).
Rule: compare each bar with the bar before it. Took the prior high only = 2u. Took the
prior low only = 2d. Took both = 3. Took neither = 1 (inside bar). Equal to the prior
high/low is NOT a take-out (still a 1). The first bar has no scenario (null).
Also returns color, hammer/shooter shape, failed-2 flags (2u red / 2d green = potential 3)
and 3u/3d when the bar has first_side data. Use this instead of reading a chart.
| Name | Required | Description | Default |
|---|---|---|---|
| bars | Yes | OHLC bars, oldest first. Each bar is an object {t, o, h, l, c, v?} (also accepts open/high/low/close/time) or a row [t, o, h, l, c, v?]. t = bar START time, ISO 8601 (New York time if no offset). Daily bars may use a date only. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses edge-case semantics (equal to prior high/low is NOT a take-out, first bar yields null) and enumerates the derived fields returned. It does not explicitly state that the operation is pure/read-only or what happens on malformed/insufficient bar data, which keeps it short of a 5.
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?
Front-loaded with purpose, then the decision rule, then secondary outputs, then the routing directive — every sentence carries content. Minor drag from jargon ('Truth #1', 'first_side data') that is never defined and slightly interrupts the flow.
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 single-parameter, no-output-schema tool, the description covers the classification rule, the null first bar, and names the extra returned fields. It stops short of giving the actual return object's field names/shape, so an agent still guesses at exact output keys, but the substance is sufficient to call 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% and the bars parameter is fully documented (accepts objects or row arrays, t is bar START time, ISO 8601). The description only reinforces ordering via 'compare each bar with the bar before it', consistent with the schema's 'oldest first' but adding little beyond it. Baseline 3 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?
States a specific verb and resource ('Label every bar') plus the exact output domain (TheStrat scenarios 1, 2u, 2d, 3). It also declares the secondary outputs (color, hammer/shooter, failed-2 flags, 3u/3d), so the agent knows precisely what it gets back and can distinguish it from siblings like find_signals or potential_signals_next_bar.
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 closing directive 'Use this instead of reading a chart' gives a clear positive usage condition, and the labeling rule implies it applies to raw OHLC series. However, it never contrasts itself with the numerous sibling analysis tools (signals_in_force, find_signals, etc.), leaving the agent to infer which analysis entry point to pick.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Define a TheStrat term with a quote from the docs and its source_url (67-term glossary: definition, machine_rule where the docs state one, status "needs Alex" where the docs conflict). If the term is not in the glossary, returns the best docs_search hits.
| Name | Required | Description | Default |
|---|---|---|---|
| term | Yes | A TheStrat word, e.g. 'FTFC', 'rev strat', 'level of reclaim'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and discloses useful behavior: returned quote, source_url, glossary status, machine_rule when available, and "needs Alex" conflict handling. It does not discuss permissions, rate limits, or caching, but for a read-only definition lookup these are minor gaps.
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?
Front-loads the core action and return shape, then adds only essential glossary and fallback details. There is no wasted 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 one-parameter lookup tool with no output schema, the description explains the returned fields and fallback behavior sufficiently for correct invocation and interpretation. No annotations are needed to understand its read-only definition role.
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% and the term parameter already includes examples such as 'FTFC', 'rev strat', and 'level of reclaim'. The description reinforces that term is a TheStrat word but adds no syntax or formatting detail beyond the 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?
States a specific verb and resource: "Define a TheStrat term" with a quote and source_url. It also explains the glossary scope and the non-glossary fallback to docs_search, so an agent can distinguish it from docs_search without opening schemas.
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?
Clearly indicates the primary use case (glossary terms) and fallback behavior when the term is not in the glossary: returning best docs_search hits. It does not explicitly say when to choose docs_search instead for general documentation lookup, but the fallback gives enough routing context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Multi-timeframe price analysis in plain language for one symbol (quant price action, technical signals, timeframe continuity) from your own bars.
Returns `text` (one short line per timeframe, e.g. "SPY day: 2u, above the day open
(green). Last 3 bars: 2d 1 2u. In force: bullish 2-1-2 ...") and the same facts as
JSON: scenario, color, last 3 bars, signals in force, setups, and FTFC (M W D 60).
Start here, then quote the text to the user. On the hosted server a free key has a
short cooldown per call; credits skip it (the reply says how many seconds to wait).
| Name | Required | Description | Default |
|---|---|---|---|
| now | No | Current time, ISO 8601. Decides if the last bar is still open. Default: the server clock. | |
| symbol | Yes | Ticker, e.g. SPY. | |
| bars_by_timeframe | Yes | Bars per timeframe, e.g. {"M": [...], "W": [...], "D": [...], "60": [...]}. Give at least 3 bars per timeframe; more gives more signals. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does a good job: it explains the plain-text and JSON return shapes, lists the returned facts, and discloses hosted-server cooldown/credit behavior. It does not explicitly state read-only semantics or error behavior, but the 'from your own bars' analysis framing makes side effects unlikely.
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 purpose is front-loaded in the first sentence, return behavior follows, and operational guidance comes last. The example output and cooldown note earn their place by clarifying usage and hosted-server behavior without excessive length.
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 having no output schema and no annotations, the description explains both the text and JSON return contents, the intended workflow, and rate-limit implications. Combined with full schema description coverage on the three parameters, an agent has enough information to call and interpret this tool 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 description coverage is 100%, so the schema already documents symbol, bars_by_timeframe, and now. The description adds framing such as 'for one symbol' and 'from your own bars,' but does not add parameter-specific meaning beyond the schema. 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?
States a specific resource and scope: multi-timeframe price analysis for one symbol in plain language, using the caller's own bars. It also distinguishes itself from siblings by describing the combined output (price action, technical signals, timeframe continuity) and positioning itself as the starting point. An agent can identify this as the human-readable summary tool without opening other schemas.
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?
Gives clear usage direction: 'Start here, then quote the text to the user.' This establishes an entry-point workflow, but it does not explicitly say when to prefer or avoid sibling tools such as find_signals or signals_in_force. Alternatives are implied by the included dimensions rather than named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search TheStrat docs (titles and descriptions from https://thestrat.ai/llms.txt, cached 24 h). Returns title, URL, section and description. Read the URL for detail.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results. | |
| query | Yes | Words to find, e.g. 'shooter trigger' or 'full timeframe continuity'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose the upstream source, the 24 h cache (staleness caveat) and the returned fields, which is real behavioral context. It stops short of stating that the tool is read-only/does not mutate docs, or anything about result ranking or rate limits.
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 short clauses front-loaded with the action and source, then returns, then the follow-up step. No filler, no repetition of the schema.
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 two-parameter search tool with no output schema, explaining the returned fields (title, URL, section, description) and pointing at the URL for detail is exactly the information an agent needs. Only the lack of explicit read-only/ranking behavior keeps it from being 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%; both 'query' and 'limit' are already documented with examples and a default in the schema. The description adds no parameter meaning beyond that, so the baseline of 3 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?
States a specific verb and resource ('Search TheStrat docs') and narrows the searched fields to titles and descriptions. It doesn't name a sibling (e.g. define_term, find_signals) to contrast with, so differentiation from the other docs-oriented tools is left implicit.
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?
'Read the URL for detail' implies a find-then-fetch workflow, which is modestly useful guidance. There is no explicit statement of when to use this versus define_term or find_signals, and no exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Exhaustion risk: how much time is left in the signal's bar (session minutes, wall-clock minutes, sessions left, fraction left), and until when the fire stays active.
Docs example: a 60-minute hammer that triggers at 9:32 has 58 minutes; at 10:25 it has 5.
Once the bar closes, the signal is gone. The tool reports time; it does not grade it.
| Name | Required | Description | Default |
|---|---|---|---|
| now | No | Current time, ISO 8601. Decides if the last bar is still open. Default: the server clock. | |
| signal | Yes | A signal from find_signals, or {"timeframe": "60", "trigger_bar_t": "2026-10-23T09:30:00-04:00"}. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the temporal behavior—that the bar eventually closes and the signal disappears—and clarifies that the tool only reports time rather than grading it. It does not cover permissions, side effects, or output format, but for an informational tool the key behavior is present.
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 purpose is front-loaded in the first sentence, with a compact example that clarifies edge behavior. The three-sentence structure is efficient, though the docs example is slightly more than the minimum.
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 two-parameter informational tool with no output schema and no annotations, the description explains what is measured and what happens when the bar closes. It is complete enough to call correctly, though it could spell out the result shape more explicitly.
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%, and the schema documents both `signal` and `now` in detail, so the description does not need to restate them. It adds no parameter-level syntax beyond that baseline.
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 resource—time remaining in a signal's bar—and enumerates the reported quantities (session minutes, wall-clock minutes, sessions left, fraction left). It is clearly distinguishable from signals_in_force or find_signals, though it does not name those siblings explicitly.
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 offers no explicit when-to-use or when-not guidance relative to siblings. The closest is "The tool reports time; it does not grade it," which sets a boundary but stops short of routing the agent to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find TheStrat actionable signals on one timeframe.
Patterns: 2-2 reversal, 1-2-2 rev strat, 3-2-2, 2-1-2, 3-1-2, 3-2, hammer, shooter,
momo hammer/shooter, inside bar, outside bar reversal (2d-3u / 2u-3d), 1-3 rev strat,
1-3-2, I-O-I. Each signal has: trigger, target (magnitude, null if the pattern has
none), level_of_reclaim, invalidation, status, sequence, kind (reversal/continuation)
and source_url (the docs page for the rule).
Status: setup (trigger not taken), in_force (taken, target not hit, still active),
triggered (taken, bar closed, no target), hit_target, failed. Timing: a signal is in
force only while its bar is open; D fires stay active until the next session open;
the W is closed from Friday close to Monday open.
| Name | Required | Description | Default |
|---|---|---|---|
| now | No | Current time, ISO 8601. Decides if the last bar is still open. Default: the server clock. | |
| bars | Yes | OHLC bars, oldest first. Each bar is an object {t, o, h, l, c, v?} (also accepts open/high/low/close/time) or a row [t, o, h, l, c, v?]. t = bar START time, ISO 8601 (New York time if no offset). Daily bars may use a date only. | |
| timeframe | No | Timeframe of the bars: 5, 15, 30, 60, D, W, M, Q or Y. | D |
| include_history | No | Also list older setups and what happened to them (evidence of participation). |
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 well: it lists every signal field, explains status values (setup, in_force, triggered, hit_target, failed), and details timing rules such as bar-open validity, daily fires lasting to next session open, and weekly closure from Friday to Monday. This is rich behavioral context beyond the schema.
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 purpose is front-loaded, followed by structured sections for patterns, signal fields, statuses, and timing. The dense pattern enumeration and status details are relevant to the domain, though slightly lengthy; overall it is efficient and every section earns its place.
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 exists, but the description compensates by listing the signal fields and status semantics an agent will receive. Input parameters are fully covered by the schema. It could clarify the exact return shape or ordering and does not mention include_history behavior, but it is largely complete for this complex analysis tool.
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 all four parameters are already documented in the input schema. The description adds only the implied notion of a single timeframe and does not elaborate on parameter usage beyond that, making the baseline 3 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?
States a specific verb ('Find') and resource ('TheStrat actionable signals') with scope ('one timeframe'), and enumerates the patterns it detects. It does not explicitly distinguish itself from sibling tools such as signals_in_force or potential_signals_next_bar, so full sibling differentiation is missing.
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 no explicit when-to-use guidance, when-not conditions, or alternatives. Usage is only implied by the purpose statement; an agent gets no routing help between this and related signal tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rules the docs do not state exactly, with the default this server uses. Read this before you present a borderline result as a rule.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses that the content includes this server's defaults and is relevant for borderline cases, but it does not describe scope, authority, or what the returned rules look like.
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, both doing useful work. The key context is front-loaded and there is no 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?
For a zero-parameter informational tool, the description tells the agent what the tool contains and when to consult it. However, without an output schema, it should say more about what the result actually provides or how exhaustive the rules are.
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 takes zero parameters, so parameter semantics are inherently simple and the baseline is 4. The description adds no parameter detail because there is none to add.
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 the resource as undocumented rules and server-specific defaults, which distinguishes it from docs_search. It is clear enough to understand the tool's role, though it states the content as a noun phrase rather than a direct verb+resource definition.
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 a specific usage condition: read this before presenting a borderline result as a rule. That is a clear when-to-use cue. It does not explicitly state when not to use it or name alternatives, so it stops 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.
Potential signals for the next bar across a basket: every setup whose trigger the next bar (or the open bar) can take, grouped by direction and pattern, with trigger, target and level of reclaim per symbol. A price action watchlist for agents.
| Name | Required | Description | Default |
|---|---|---|---|
| now | No | Current time, ISO 8601. Decides if the last bar is still open. Default: the server clock. | |
| as_of | No | Optional ISO time. Use only bars that start at or before this time (replay a past bar). | |
| basket | Yes | Bars per symbol on ONE timeframe, oldest first: {"XLE": [...], "XOM": [...], ...}. Same bar format as find_signals. Limits: 60 symbols, 500 bars per symbol (10 to 50 are enough). Swing: a sector ETF + its holdings on W. Intraday: SPY QQQ DIA IWM on 30 or 60. | |
| timeframe | No | Timeframe of the bars: 5, 15, 30, 60, D, W, M, Q or Y. | D |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It adds useful output context, namely grouping by direction and pattern and per-symbol trigger, target, and reclaim level, but it does not explicitly state that the tool is read-only, places no orders, or has no side effects, which matters for an agent-facing trading watchlist.
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 short and front-loaded, stating the core purpose before adding output grouping details. The closing sentence, "A price action watchlist for agents," is helpful framing but slightly extra relative to the dense first sentence.
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 four parameters, a nested basket object, no annotations, and no output schema, the description does a good job explaining the returned signal context: direction, pattern, trigger, target, and reclaim level per symbol. It could still be more complete about empty results or exact return structure, but it is sufficient for correct 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 description coverage is 100%, and the schema already explains now, as_of, basket structure, limits, and timeframe thoroughly. The description reinforces the basket-wide and next-bar framing but adds no parameter syntax or format detail beyond what the schema provides, so the baseline of 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-like purpose and resource: potential signals for the next bar across a basket, including every setup whose trigger the next bar or open bar can take. It clearly describes the output grouping and fields, but it does not explicitly name or distinguish itself from siblings such as find_signals or signals_in_force.
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 wording implies usage: a next-bar watchlist for agents, with reference to the open bar and basket-wide setups. However, it gives no explicit guidance on when to use this instead of find_signals, signals_in_force, or sim_setups, so selection still depends on inference from the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build higher-timeframe bars from smaller bars (US equities session 09:30-16:00 New York; 60-minute bars start at 09:30; extended hours are dropped; a partial first period is dropped). Each bar gets first_side (which prior side it took first) for 3u/3d.
| Name | Required | Description | Default |
|---|---|---|---|
| bars | Yes | OHLC bars, oldest first. Each bar is an object {t, o, h, l, c, v?} (also accepts open/high/low/close/time) or a row [t, o, h, l, c, v?]. t = bar START time, ISO 8601 (New York time if no offset). Daily bars may use a date only. | |
| to_timeframe | Yes | 60, 30, 15, D, W, M, Q or Y. | |
| from_timeframe | No | Input timeframe: 1, 5, 15, 30, 60 or D. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so the description carries the full burden, and it does disclose meaningful behavior: session clipping, extended-hours removal, partial-period dropping, 60-minute anchoring, and the added first_side field. It omits error behavior (invalid target timeframe, unsorted bars) and how OHLCV fields are aggregated.
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 dense sentences, front-loaded with the transformation and followed by the caveats an agent most needs. The trailing '3u/3d' reference is unexplained jargon that costs a little clarity.
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?
With no annotations and no output schema, the description must fully explain input expectations and return shape. It covers input domain and one added output field but not the aggregation semantics of o/h/l/c/v or failure modes, leaving real gaps for a transform tool.
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 all three parameters are already documented in the schema; baseline is 3. The description adds no parameter-level detail (e.g., whether from_timeframe is inferred, what happens with daily input), only an output-side note about first_side.
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 a specific verb and resource ('Build higher-timeframe bars from smaller bars') and adds the exact transformation domain (US equities, 60-min alignment). It does not name or contrast any sibling, but no sibling in the list performs resampling, so confusion risk is low.
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 session constraints (09:30-16:00 New York, extended hours dropped, partial first period dropped) implicitly define applicability and exclusions. There is no explicit 'when to use this instead of X' guidance or statement of prerequisites regarding input timeframe.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sector rotation by participation: a sector ETF + its holdings on one timeframe.
Returns the ETF's own state (scenario, color, last 3 bars, signals in force), the most-2s
split of the holdings (1 / 2u / 2d / 3, 2u red, 2d green), simultaneous breaks and
simultaneous setups across ETF + holdings with majority flags, and a `text` summary.
| Name | Required | Description | Default |
|---|---|---|---|
| etf | Yes | The sector ETF ticker, e.g. XLE. Include its bars in the basket. | |
| now | No | Current time, ISO 8601. Decides if the last bar is still open. Default: the server clock. | |
| as_of | No | Optional ISO time. Use only bars that start at or before this time (replay a past bar). | |
| basket | Yes | Bars per symbol on ONE timeframe, oldest first: {"XLE": [...], "XOM": [...], ...}. Same bar format as find_signals. Limits: 60 symbols, 500 bars per symbol (10 to 50 are enough). Swing: a sector ETF + its holdings on W. Intraday: SPY QQQ DIA IWM on 30 or 60. | |
| timeframe | No | Timeframe of the bars: 5, 15, 30, 60, D, W, M, Q or Y. | W |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the return composition, including ETF state, holding splits, simultaneous breaks/setups, majority flags, and a text summary, but it does not state side effects, permissions, error behavior, or deterministic constraints.
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 front-loaded with the purpose and then lists the return contents without generic filler. It is appropriately sized, though the return sentence is dense with domain jargon.
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 complex multi-symbol analysis tool with no output schema, the description gives a useful high-level account of what is returned and emphasizes one timeframe. However, it leaves important domain terms and output organization unexplained, and it does not compensate for the lack of usage guidance or annotations.
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 schema already documents all five parameters in detail, including the ETF, basket format, timeframe, and time controls. The description adds only the high-level idea of ETF plus holdings on one timeframe and does not supplement the parameter definitions.
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 identifies the resource and scope: a sector ETF plus its holdings analyzed on one timeframe for sector rotation by participation. It does not explicitly contrast itself with siblings such as find_signals or classify_bars, so it falls short of the highest clarity tier.
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 what the tool returns but gives no explicit guidance on when to use it versus alternatives. The schema contains useful limits and examples, but the description itself does not say when this tool is the right choice or when another sibling should be used instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Technical signals in force across a basket: every TheStrat actionable signal whose trigger is taken while its bar is open, grouped by direction and pattern, with % of basket and the trigger, target and level of reclaim per symbol.
| Name | Required | Description | Default |
|---|---|---|---|
| now | No | Current time, ISO 8601. Decides if the last bar is still open. Default: the server clock. | |
| as_of | No | Optional ISO time. Use only bars that start at or before this time (replay a past bar). | |
| basket | Yes | Bars per symbol on ONE timeframe, oldest first: {"XLE": [...], "XOM": [...], ...}. Same bar format as find_signals. Limits: 60 symbols, 500 bars per symbol (10 to 50 are enough). Swing: a sector ETF + its holdings on W. Intraday: SPY QQQ DIA IWM on 30 or 60. | |
| timeframe | No | Timeframe of the bars: 5, 15, 30, 60, D, W, M, Q or Y. | D |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It does disclose the return shape (grouped by direction and pattern, % of basket, trigger/target/level of reclaim per symbol), which is real value. It omits what happens with symbols lacking open bars, invalid baskets, or symbols with insufficient bars — leaving the failure profile opaque for a computation 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 dense sentence with no filler, front-loaded on the core concept ('technical signals in force across a basket') before enumerating grouping and per-symbol fields. It is somewhat jargon-heavy ('level of reclaim', 'trigger is taken') without gloss, which slightly impairs first-pass parsing.
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 compute tool with no output schema and a nested basket parameter, the description does cover the conceptual return contents, which is the most important gap. However it says nothing about edge cases, partial results, or per-symbol failure handling, all of which an agent needs before committing a 60-symbol basket.
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 now, as_of, basket and timeframe are all documented in the schema, including limits (60 symbols, 500 bars) and the 'decides if the last bar is still open' semantics. The description adds nothing beyond the schema on any of the four parameters, so the baseline 3 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?
States a specific resource and verb: returns every TheStrat actionable signal whose trigger is taken while its bar is open, across a basket, grouped by direction and pattern. The 'in force / bar still open' framing implicitly separates it from find_signals (historical) and potential_signals_next_bar, though it never names those siblings explicitly.
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?
Usage is implied by 'whose trigger is taken while its bar is open' and by the schema's guidance on basket composition, but the description itself gives no explicit when-to-use, when-not-to-use, or alternative tool to pick instead of find_signals / potential_signals_next_bar / open_decisions. An agent must infer routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Simultaneous breaks: find which symbols in a basket broke their setup bar in the same direction in the same bar (2d-2u, 1-2u, 3-1-2u up / 2u-2d, 1-2d down). Quant price action and sector rotation from your own OHLC data, no third-party feed.
Docs: "A simultaneous break is multiple correlated assets breaking 2 in the same direction
at the same time." No threshold: the count and the % of the basket, ranked. At 80%+ the
group gets the label "80%+ concentration: evidence of algorithmic buying (selling) in this
group". Returns a ranked list per direction with count, % of basket,
symbols, and per symbol the trigger, target and level of reclaim, plus the as-of time
and a `text` line to quote.
| Name | Required | Description | Default |
|---|---|---|---|
| now | No | Current time, ISO 8601. Decides if the last bar is still open. Default: the server clock. | |
| as_of | No | Optional ISO time. Use only bars that start at or before this time (replay a past bar). | |
| basket | Yes | Bars per symbol on ONE timeframe, oldest first: {"XLE": [...], "XOM": [...], ...}. Same bar format as find_signals. Limits: 60 symbols, 500 bars per symbol (10 to 50 are enough). Swing: a sector ETF + its holdings on W. Intraday: SPY QQQ DIA IWM on 30 or 60. | |
| timeframe | No | Timeframe of the bars: 5, 15, 30, 60, D, W, M, Q or Y. | W |
| strict_setup_bar | No | True (default): count only the setup bars on the owner list (2d green / 2d hammer for longs, 2u red / 2u shooter for shorts, inside bars both ways). False: any docs reversal setup. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does so well: it discloses that there is no threshold, that results are ranked by count and % of basket, that an 80%+ concentration triggers a specific label, and it enumerates the return structure (per-direction ranks, per-symbol trigger/target/reclaim, as-of time, quotable text line). It stops short of describing error conditions or side effects, but for an analysis tool the disclosure is 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?
The first sentence is front-loaded and functional, but the description then repeats itself: the 'Docs:' quote ('A simultaneous break is multiple correlated assets breaking 2 in the same direction') largely restates the opening sentence, and the notation is dense enough to require parsing. It is not bloated, but some redundancy and jargon make it less crisp.
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 would need to explain the return value — and it does, listing the ranked structure and per-symbol fields. For a tool with a nested basket parameter and five inputs, the description plus schema together give an agent enough to call it correctly, though it omits failure modes and any explicit relationship to sibling tools.
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 every parameter including the basket format and strict_setup_bar semantics. The description adds only marginal meaning (e.g., 'no threshold'), and the dense bar-pattern notation (2d-2u, etc.) is not tied back to any parameter. Baseline 3 is appropriate when structured fields do the heavy lifting.
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 opens with a specific verb+resource: 'find which symbols in a basket broke their setup bar in the same direction in the same bar'. That tells an agent exactly what the tool does. However, it never explicitly contrasts itself with sim_setups or find_signals, so sibling differentiation is left implicit.
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 the tool is for simultaneous-break detection but gives no when-to-use/when-not-to-use guidance or named alternatives. Concrete usage examples (sector ETF + holdings on W, SPY/QQQ/DIA/IWM on 30 or 60) live only in the schema, not the description, so the agent must infer routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Simultaneous setups (before the break): a concentration of setup bars in one direction across a basket of symbols. A technical signals screener on your own data, any timeframe.
Docs: "A concentration of signals in the same sector or index identifies a potential
simultaneous break: it fires if all of the signals go in force." Returns a ranked list per
direction: count, % of basket, symbols, each with trigger, target and level of reclaim.
| Name | Required | Description | Default |
|---|---|---|---|
| now | No | Current time, ISO 8601. Decides if the last bar is still open. Default: the server clock. | |
| as_of | No | Optional ISO time. Use only bars that start at or before this time (replay a past bar). | |
| basket | Yes | Bars per symbol on ONE timeframe, oldest first: {"XLE": [...], "XOM": [...], ...}. Same bar format as find_signals. Limits: 60 symbols, 500 bars per symbol (10 to 50 are enough). Swing: a sector ETF + its holdings on W. Intraday: SPY QQQ DIA IWM on 30 or 60. | |
| timeframe | No | Timeframe of the bars: 5, 15, 30, 60, D, W, M, Q or Y. | W |
| strict_setup_bar | No | True (default): count only the setup bars on the owner list (2d green / 2d hammer for longs, 2u red / 2u shooter for shorts, inside bars both ways). False: any docs reversal setup. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does reasonably well: it explains the firing condition ('fires if all of the signals go in force'), the default strict-setup-bar behavior (owner-list setups vs any docs reversal), and the shape of the return (count, % of basket, symbols, trigger, target, level of reclaim). It omits error behavior, cost/latency, and what happens when fewer than all signals fire.
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 opening definition is front-loaded, but the quoted 'Docs:' block restates the first sentence about concentration of signals in the same sector, and the phrase 'level of reclaim' is left unexplained. There is genuine waste and internal repetition in a description that is only a few sentences long.
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 5-parameter tool with a nested basket object and no output schema, the description is largely sufficient: it defines the computation, the strict-setup-bar switch, and the returned fields per symbol. What is missing is a note on partial matches (what if only some signals fire) and any guidance on basket sizing beyond the schema limits.
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 all five parameters are already documented in the structured field, making 3 the baseline. The description echoes the basket contract ('same bar format as find_signals') without adding syntax the schema lacks, and gives no extra meaning for now, as_of, or timeframe beyond what the schema 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?
States a concrete verb+resource: it scans a basket of symbols for a concentration of setup bars in one direction and returns a ranked list per direction. That is specific enough to separate it from generic signal tools, but it never names or contrasts the closest siblings (find_signals, sim_breaks, signals_in_force) even though sim_breaks is an obvious near-duplicate.
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?
Usage context is implied rather than stated: the docs quote explains what makes a simultaneous break 'fire' (all signals in force), and the basket schema suggests swing vs intraday configurations. There is no explicit when-to-use / when-not-to-use guidance and no routing to alternatives such as find_signals for single-symbol work or sim_breaks for the adjacent concept.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full timeframe continuity (FTFC, Truth #2): is the last sale above (up) or below (down) the open of every timeframe in the group, or mixed (conflict)?
Returns per-timeframe side, color and aggression (above an open: buyers more aggressive,
willing to buy at higher prices; below: sellers more aggressive), state up/down/mixed,
override (day and 60 agree against the week/month) and the profit-taking note (only the
60 red). FTFC is a state, not a signal.
| Name | Required | Description | Default |
|---|---|---|---|
| group | No | standard = M W D 60 (default), intraday = 60 30 15 5, investing = Y Q M W, all = Y Q M W D 60 30 15 5. | standard |
| opens | Yes | Open price of the CURRENT bar per timeframe, e.g. {"M": 650.1, "W": 662.0, "D": 665.2, "60": 666.0}. | |
| price | Yes | The last sale. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and no output schema, the description carries the burden and largely meets it: it explains the returned fields, the meaning of aggression above/below an open, the override condition (day and 60 disagreeing with week/month), and the profit-taking caveat (only when the 60 is red). It does not state what happens if a timeframe in the group is missing from 'opens' or that the operation is a pure read-only computation.
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?
Content is front-loaded with the core question and every sentence conveys return-value meaning rather than filler. It is, however, dense with undefined in-house jargon ('FTFC, Truth #2') and nested parentheticals that slow first-pass parsing.
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 side-effect-free computation tool with a fully described 3-parameter schema and no output schema, the description gives enough on the return shape and semantics to call it correctly. The gap is edge behavior — missing timeframe keys in 'opens' or mismatched group membership — which an agent would want spelled out.
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 schema already defines group presets, the opens map with an example, and price as the last sale. The description adds only the interpretive gloss on what 'above an open' means behaviorally, not syntax or constraint detail beyond the schema. Baseline 3 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 states a specific evaluation: whether the last sale sits above, below, or mixed relative to the open of every timeframe in a group, and enumerates what it returns (side, color, aggression, state, override, profit-taking note). That is a concrete verb-plus-resource, not a restatement of the name. It only lightly differentiates from siblings ('a state, not a signal'), without naming find_signals or signals_in_force.
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?
Usage is implied rather than stated: 'FTFC is a state, not a signal' hints that this is a contextual read used alongside signal tools, but no explicit when-to-use/when-not rule or named alternative is given. An agent must infer that this is a diagnostic rather than a scan like find_signals.
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.
buy_sell_listclassify_barsdefine_termdescribe_pricedocs_searchexhaustionfind_signalsopen_decisionspotential_signals_next_barresample_barssector_analysissignals_in_forcesim_breakssim_setupstimeframe_continuityPay-per-call trading intelligence for AI agents: live market regime, trading signals, composite conv
The Brain Layer for AI Trading Agents — quant calls + cross-venue arb across perp venues via MCP.
Regime-aware ES1/NQ futures trading signals. HMM + 15 quant strategies. x402 USDC micropayments.
Price-action reads with measured accuracy: day-type odds, breakouts, public scoreboard
Add one secure layer between your agents and this server.
