Keel — Hyperliquid trading strategies

Search Components

keel_components_search

Read-onlyIdempotent

Search the Keel component catalog by keyword, semantic query, category, or data type to locate pipeline components for Hyperliquid strategies.

Instructions

Search the Keel pipeline component catalog by keyword, semantic query, category, input/output type, or pipeline position (after/before) — the REQUIRED first step of the two-step discovery every build turn starts with.

Decompose the thesis into roles (universe, signal, entry/exit, filter, sizing, normalize) and search each role — plus every domain concept the user names (beta hedge, vol targeting, risk parity, trailing stop, regime) — in natural language BEFORE selecting anything. This holds for new strategies AND every edit. When the user names a concept, ALWAYS search for it rather than hand-rolling from memory: a manual ConstantForecast(-10) is a static short, not the BetaHedgeAllocator that was asked for.

Keel re-clocks in one direction — resample raw data fine → coarse, project signals coarse → fine. Filter by clock_direction for the operator in the direction you want.

Returns compact entries (name, category, description, input/output type) to triage; feed the set you pick straight into keel_components_detail_batch to verify types and slots before drafting DSL. Do NOT plan a pipeline from names or pattern memory alone — search is not optional. Do NOT use to fetch the full schema of ONE component — use keel_components_compose_help. Do NOT use to enumerate strategies — call keel_strategy_search.

Input Schema

TableJSON Schema

Name	Required	Description
`after`	No	Return components that can FOLLOW the named component (their input type accepts that component's output).
`limit`	No	Maximum number of results.
`query`	No	Free-text semantic query — tokens are matched against name, category, and description with weighted scoring (name ×3, category ×2, description ×1). Returns components scored > 0 ranked by relevance. Pair with `keyword` (or the CLI positional keyword) to first narrow by substring, then rank.
`before`	No	Return components that can PRECEDE the named component (their output type matches that component's input).
`keyword`	No	Case-insensitive substring match against name or description. The CLI positional arg maps here — `keel components search momentum` filters to components mentioning 'momentum'. For weighted token-scoring across name/category/description, use `--query` instead.
`category`	No	Restrict to one component category.
`input_type`	No	Restrict to components consuming this type (e.g. `SignalSeries`).
`output_type`	No	Restrict to components producing this type (e.g. `ForecastSeries`).
`clock_direction`	No	Restrict to components that change the bar clock in one direction. `resample` = fine → coarse aggregation of raw data (e.g. 1h OHLCV → 1d). `project` = coarse → fine, holding the last COMPLETED coarse bar across the finer grid (e.g. a 1d regime signal driving 1h execution) — the only safe way to move a signal down. `synth` = a data loader minting the entry clock. `keep` = leaves the clock untouched (most components).

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.7.0Aug 26, 2026

addedInput schema / properties / clock_direction

Added value: +{
+  "description": "Restrict to components that change the bar clock in one direction. `resample` = fine → coarse aggregation of raw data (e.g. 1h OHLCV → 1d). `project` = coarse → fine, holding the last COMPLETED coarse bar across the finer grid (e.g. a 1d regime signal driving 1h execution) — the only safe way to move a signal down. `synth` = a data loader minting the entry clock. `keep` = leaves the clock untouched (most components).",
+  "enum": [
+    "keep",
+    "synth",
+    "resample",
+    "project"
+  ],
+  "type": "string"
+}

First observedv0.1.0Jun 13, 2026

TDQS

A4.8/5.0

Behavior5/5

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

The annotations already mark this as read-only, idempotent, and non-destructive, and the description adds substantial behavioral context beyond those hints. It explains that results are compact triage entries with name/category/description/input-output type, that returned sets should feed into `keel_components_detail_batch`, that Keel re-clocks in only one direction, and that hand-rolled components from memory can misrepresent the requested concept (e.g., `ConstantForecast(-10)` vs `BetaHedgeAllocator`). No contradiction with annotations.

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 description is long, but nearly every sentence carries operational value: primary purpose, workflow rules, clock-direction caveat, return-format expectation, and explicit exclusions. It is front-loaded with the most important fact (REQUIRED first step) and then structured logically. Minor redundancy in repeated emphasis on 'search is not optional' keeps it from a 5, but it is far from bloated given the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given a search tool with 9 optional parameters, 100% schema coverage, an output schema, and read-only annotations, the description covers everything an agent needs to invoke it correctly: when it is mandatory, how to decompose queries, what results look like, how to follow up, and which sibling tools handle adjacent cases. Nothing material is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is already high; the schema documents every parameter including weighted scoring for `query` and direction semantics for `clock_direction`. The description goes beyond the schema by tying parameters to the discovery workflow (e.g., filter by `clock_direction` for the desired operator direction, pair `keyword` with `query` for narrowing, use `after`/`before` for pipeline position). This adds practical selection guidance rather than merely restating schema fields.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific action ('Search the Keel pipeline component catalog') and the full set of search dimensions (keyword, semantic query, category, input/output type, pipeline position). It also explicitly distinguishes itself from siblings like `keel_components_compose_help` (single-component schema) and `keel_strategy_search` (strategy enumeration), so an agent can disambiguate without opening their schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage guidance is unusually explicit: it declares this tool the REQUIRED first step in every build turn, instructs decomposing the thesis into roles and searching each role, mandates searching whenever the user names a concept, and warns against planning from memory. It also provides concrete exclusions ('Do NOT use to fetch the full schema of ONE component', 'Do NOT use to enumerate strategies') with named alternatives, leaving no ambiguity about when to use this tool versus its siblings.

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