Skip to main content
Glama
Keel — Hyperliquid trading strategies

Keel — Hyperliquid trading strategies

by keel-trade

Search Components

keel_components_search
Read-onlyIdempotent

Search the Keel component catalog to find pipeline building blocks by keyword, semantic query, category, input/output type, or position (after/before) when assembling a strategy.

Instructions

Search the Keel pipeline component catalog — the chosen candidates go to keel_components_get_many, which verifies their types and slots. It matches keyword (narrows), a natural-language query (ranks), category, input_type / output_type, or pipeline position (after / before); clock_direction filters to one re-clocking direction (resample raw data fine → coarse, project signals coarse → fine). Domain concepts (beta hedge, regime) are components, found here. Returns compact entries (name, category, description, input/output type); one component's full contract is keel_components_get.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "keel_components_search"
  }
}

Input Schema

NameRequiredDescriptionDefault
afterNoReturn components that can FOLLOW the named component (their input type accepts that component's output).
limitNoMaximum number of results (default 20); `total` is the number returned.
queryNoFree-text semantic query — tokens are matched against name, category, and description with weighted scoring (name ×3, category ×2, description ×1); components scored > 0 return ranked by relevance. Combined with `keyword` (or the CLI positional keyword), the substring narrows first and the query ranks.
beforeNoReturn components that can PRECEDE the named component (their output type matches that component's input).
keywordNoCase-insensitive substring match against name or description, e.g. `momentum` keeps the components mentioning it. `query` adds weighted token scoring across name/category/description.
categoryNoRestrict to one component category.
input_typeNoRestrict to components consuming this type (e.g. `SignalSeries`).
output_typeNoRestrict to components producing this type (e.g. `ForecastSeries`).
sub_categoryNoRestrict to one sub-category, case-insensitive exact match (e.g. `trade_reader`, `trade_action`, `trade_factory`).
clock_directionNoRestrict 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).
include_deprecatedNoAlso return deprecated components (hidden by default); each carries `status` and `replacement_text`. A lookup by name (`keel_components_get`) always answers.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.9.0
    • addedInput schema / properties / include_deprecated
      Added value: +{
      +  "default": false,
      +  "description": "Also return deprecated components (hidden by default); each carries `status` and `replacement_text`. A lookup by name (`keel_components_get`) always answers.",
      +  "type": "boolean"
      +}
    • changedInput schema / properties / keyword / description
      Previous value: -"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."New value: +"Case-insensitive substring match against name or description, e.g. `momentum` keeps the components mentioning it. `query` adds weighted token scoring across name/category/description."
    • changedInput schema / properties / limit / description
      Previous value: -"Maximum number of results."New value: +"Maximum number of results (default 20); `total` is the number returned."
    • addedInput schema / properties / limit / minimum
      Added value: +1
    • changedInput schema / properties / query / description
      Previous value: -"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."New value: +"Free-text semantic query — tokens are matched against name, category, and description with weighted scoring (name ×3, category ×2, description ×1); components scored > 0 return ranked by relevance. Combined with `keyword` (or the CLI positional keyword), the substring narrows first and the query ranks."
    • addedInput schema / properties / sub_category
      Added value: +{
      +  "description": "Restrict to one sub-category, case-insensitive exact match (e.g. `trade_reader`, `trade_action`, `trade_factory`).",
      +  "type": "string"
      +}
  2. Changed1 schema field changedv0.7.0
    • 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"
      +}
  3. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: it states the returned entries are compact (name, category, description, input/output type) and that downstream type/slot verification happens in get_many rather than here.

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?

Purpose and the downstream routing are front-loaded, then it enumerates match modes. It is dense but each clause carries information; the second-to-last sentence on return shape earns its place. Slightly packed rather than wasteful.

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?

For a complex 11-parameter tool, the description covers purpose, match modes, downstream workflow, and return shape, and an output schema plus annotations fill remaining gaps. Only very minor detail is left to the schema, so it is effectively complete.

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% and each parameter is richly documented in the schema itself, including the keyword-narrows/query-ranks interaction and clock_direction semantics. The description largely restates those parameters rather than adding new semantics, so the baseline 3 applies.

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?

States a specific verb and resource ('Search the Keel pipeline component catalog') and explicitly carves out its place relative to `keel_components_get_many` (bulk verification) and `keel_components_get` (one full contract). An agent can distinguish it from the sibling retrieval tools without opening any schema.

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?

Routes the agent through an explicit workflow: this search produces candidates, which then go to `keel_components_get_many`, and the note that domain concepts like 'beta hedge' and 'regime' are components is a clear when-to-use cue. Names the alternatives and the condition that selects them.

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