Skip to main content
Glama
sablier-ai

Sablier MCP Server

Official
by sablier-ai

create_rule

Adds systematic trading rules to a portfolio for day-by-day evaluation on FLOW forward paths. Supports signal rules for trend-following and binary rules for risk overrides.

Instructions

Add a systematic trading rule to a portfolio. Rules are evaluated day-by-day on FLOW forward paths during forward_test_rules — not backtested on history.

TWO RULE TYPES: • Signal rules (action.type='signal_weight') — continuous indicator → proportional position. For CTAs and trend-followers. • Binary rules (all other action types) — trigger fires → discrete weight change. For risk overlays, hard stops, regime gates.

Use signal rules (priority 0) for the core strategy; binary rules (priority 1+) for risk overrides.

── SIGNAL RULE ── trigger: {indicator, asset, params} ← no operator/threshold action: {type:'signal_weight', asset, normalizer, max_weight, min_weight} normalizer = typical signal magnitude; clip(signal/normalizer, -1, 1) → position weight = scaledmax_weight if scaled≥0 else scaled|min_weight|

trigger={indicator:'macd_line', asset:'CL=F', params:{fast:12, slow:60}} action={type:'signal_weight', asset:'CL=F', normalizer:2.0, max_weight:0.6, min_weight:-0.3}

trigger={indicator:'z_score', asset:'ZN=F', params:{window:60}} action={type:'signal_weight', asset:'ZN=F', normalizer:2.0, max_weight:0.5, min_weight:-0.5}

── BINARY RULE ── trigger: {indicator, asset, params, operator, threshold} OR {combinator:'all'|'any', conditions:[...]} indicators: raw | moving_average | ema | rsi | bollinger_upper | bollinger_lower | bollinger_width | macd_line | macd_signal | rolling_std | rolling_volatility | rate_of_change | z_score asset: portfolio assets OR conditioning factors ('^VIX', 'DX-Y.NYB', 'T10Y2Y', 'ZN=F', ...) operator: '>' | '<' | '>=' | '<=' | '==' | 'crosses_above' | 'crosses_below' action: exit | set_weight (exact value, negative=short) | scale_weight (multiplier) | reverse

trigger={indicator:'rsi', asset:'CL=F', params:{period:14}, operator:'>', threshold:70} action={type:'exit', asset:'CL=F'}

trigger={combinator:'all', conditions:[ {indicator:'raw', asset:'^VIX', params:{}, operator:'>', threshold:30}, {indicator:'rsi', asset:'CL=F', params:{period:14}, operator:'>', threshold:65}]} action={type:'scale_weight', asset:'CL=F', value:0.5}

IMPORTANT: Trigger assets can be portfolio assets OR conditioning factors (VIX, DXY, etc.). For forward_test_rules, the FLOW model must include ALL referenced features — missing features cause rules to silently fail. For evaluate_rules (live data), any feature in training_data works with no model dependency.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesShort descriptive name for the rule
actionYesSignal: {type:'signal_weight', asset, normalizer, max_weight, min_weight} OR binary: {type:'exit'|'set_weight'|'scale_weight'|'reverse', asset, value?}
triggerYesFor BINARY rules: single condition {indicator,asset,params,operator,threshold} or multi-condition {combinator:'all'|'any', conditions:[...]}. For SIGNAL rules: just {indicator,asset,params} — no operator or threshold needed.
priorityNoEvaluation order when multiple rules fire (lower = first, default 0)
is_activeNoWhether the rule is active (default false)
descriptionNoOptional longer description
portfolio_idYesPortfolio UUID

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

No safety annotations are provided, so the description bears full responsibility. It discloses evaluation behavior, the difference between signal and binary rules, the mathematical scaling of signal weights, and critical failure mode: 'missing features cause rules to silently fail.' Also explains that evaluate_rules works with any feature in training_data. This is comprehensive behavioral disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but every section adds necessary value. It is front-loaded with purpose and evaluation context, then organized by rule type with examples, and finishes with a critical warning. Formatting with headings and code blocks makes it scannable. Despite length, it remains appropriately concise for the 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 the nested object schemas and existing output schema, the description provides all necessary context: what the tool does, how rules are evaluated, both rule types, allowed values, examples, and warnings about data requirements. No critical information is missing for an agent to construct and invoke this tool correctly.

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

Parameters5/5

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

Although schema descriptions cover 100% of parameters, the description substantially enriches the schema by providing full rule syntax, example triggers/actions, lists of valid indicators and operators, and semantics for normalizer, max_weight, min_weight, and combinator logic. It also clarifies how priority should be used. This goes well beyond the schema baseline.

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 opens with 'Add a systematic trading rule to a portfolio' – a specific verb and resource. It distinguishes from siblings by explaining that rules are evaluated during forward_test_rules, not backtested, and details two rule types with distinct actions. This clearly separates create_rule from list/update/delete/toggle/validate/evaluate tools.

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?

Explicitly states when rules are evaluated ('day-by-day on FLOW forward paths during forward_test_rules') and contrasts with live evaluation ('evaluate_rules'). Provides concrete guidance: 'Use signal rules (priority 0) for the core strategy; binary rules (priority 1+) for risk overrides.' Warns about missing features causing silent failure, giving users a clear decision framework.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/sablier-ai/sablier-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server