Skip to main content
Glama
sablier-ai

Sablier MCP Server

Official
by sablier-ai

analyze_quantitative

Destructive

Build and train linear factor models to compute portfolio betas, factor exposures, and per-asset R². Adjust the rolling window to detect genuine beta shifts versus noise.

Instructions

Build and train linear factor models for a portfolio in one step (creates models → trains → computes betas). This is the starting point for Moment (linear) analysis. Requires conditioning_set_id (the market drivers — get one from list_feature_set_templates or create_feature_set). Uses a two-layer architecture: thematic factors (conditioning_set_id) + optional baseline factors (baseline_mode='us' absorbs market/value/growth variance via real-time ETF proxies before thematic factors). Pass either portfolio_id or tickers directly (auto-creates portfolio with equal weights). Returns: factor exposures (betas), per-asset R² (in-sample goodness-of-fit — tells you how linear the relationship actually is for the given window), rolling_window used, factor_last_date (effective beta date — may be truncated if a factor has stale data), and data_truncated_by (which factors caused truncation).

Important: there is NO regime-conditional or 'calm vs stress' beta API. If a user asks for regime decomposition, do NOT invent it — the right substitute is to RE-RUN this tool with a shorter rolling_window (e.g. 90 days vs the 252-day default) and compare the betas to the long-window fit. Where (a) a beta shifted meaningfully AND (b) R² stayed reasonable in the short window, that's a real shift to talk about. Where R² collapsed in the short window, the apparent shift is noise from thin degrees of freedom — say so explicitly to the user. Do NOT pick rolling_window < 90 unless you have very few factors: each per-asset regression has (n_factors + n_baseline_etfs) RHS variables, and you need at least ~10 obs per parameter for stable betas (so rolling_window=90 supports up to ~9 RHS variables, rolling_window=60 supports ~6).

Low R² (e.g. < 0.2) suggests nonlinear dynamics or missing factors — flag the asset, don't claim a precise beta decomposition. R² in this Moment model is per-asset (each asset gets its own regression on the conditioning set), so a low R² for one name doesn't impeach the others. Next step: call compute_returns with the simulation_batch_id to run what-if stress tests.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tickersNoTickers to analyze (e.g. ['AAPL', 'MSFT']). Auto-creates a portfolio if portfolio_id is not given.
weightsNoOptional weights for tickers (must sum to 1.0). Defaults to equal weights.
nonlinearNoAlso fit nonlinear factor exposure model on top of linear betas, producing sensitivity curves. Requires Pro+ tier. Default True (runs if tier allows).
portfolio_idNoUUID of an existing portfolio. If omitted, provide tickers instead.
baseline_modeNoBaseline factor orthogonalization region. ETF-based (real-time): 'us', 'global', 'developed_ex_us', 'europe', 'japan'. Legacy FF5 (~2mo lag): 'us_ff5', 'global_ff5'. Set 'none' or omit to skip baseline.
rolling_windowNoRolling window size in trading days for beta estimation (default 252 = ~1 year). Smaller = more responsive to recent regime changes, larger = more stable.
conditioning_set_idYesUUID of the thematic conditioning set (from list_feature_set_templates or create_feature_set)

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

The description discloses side effects beyond the annotations (openWorldHint/destructiveHint): it 'creates models', auto-creates a portfolio when tickers are passed, and computes/returns beta-related artifacts. It explains behavioral nuances such as factor_last_date truncation, data_truncated_by, per-asset R² interpretation, and low R² implications. It also warns about degrees-of-freedom constraints and explicitly denies a regime-conditional API, which is valuable behavioral context. No contradictions 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 lengthy and dense, but nearly every sentence earns its place by conveying critical limitations, parameter semantics, and interpretation guidance. It is front-loaded with the primary action, though the long paragraphs could be improved with bullet points or section breaks for scannability. It is not redundant, but it is at the upper limit of acceptable length.

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?

The description is exceptionally complete given the tool's complexity. It explains the full pipeline, output fields, interpretation caveats (R², truncation), constraints (minimum rolling window, degrees of freedom), and the follow-up workflow (compute_returns with simulation_batch_id). It also covers when to avoid a use case (regime decomposition) and provides a substitute approach, making the tool fully contextualized among its siblings.

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?

With 100% schema coverage, the baseline is 3, but the description substantially enhances parameter meaning. It explains conditioning_set_id as 'market drivers', baseline_mode variants with real-time vs legacy FF5, rolling_window selection with statistical justification (e.g., 'rolling_window=90 supports up to ~9 RHS variables'), tickers auto-creating an equally weighted portfolio, and weights defaulting to equal weights. It adds practical semantics far beyond the schema.

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 'Build and train linear factor models for a portfolio in one step (creates models → trains → computes betas)', which is a specific verb+resource statement. It further positions itself as 'the starting point for Moment (linear) analysis', clearly distinguishing it from siblings like compute_betas by emphasizing the one-step full-pipeline nature.

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?

The description explicitly states when to use the tool (starting point for Moment analysis), what is required (conditioning_set_id), and how to obtain it (from list_feature_set_templates or create_feature_set). It also gives clear exclusions and alternatives: 'there is NO regime-conditional... API' and instead advises re-running with a shorter rolling_window and comparing betas. It warns against rolling_window < 90 and directs the next step to compute_returns.

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