Skip to main content
Glama

TheStrat for agents

find_signals

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.

Input Schema

NameRequiredDescriptionDefault
nowNoCurrent time, ISO 8601. Decides if the last bar is still open. Default: the server clock.
barsYesOHLC 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.
timeframeNoTimeframe of the bars: 5, 15, 30, 60, D, W, M, Q or Y.D
include_historyNoAlso list older setups and what happened to them (evidence of participation).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.7/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so 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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources