Skip to main content
Glama
jasonwu001t

marketlens-mcp

by jasonwu001t

Beta

analytics_beta
Read-onlyIdempotent

Compute beta, alpha, and R-squared for stored asset price series against one benchmark, using shared timestamps and optional rolling windows in DuckDB.

Instructions

Beta of each asset series against a benchmark, from two stored price results (the benchmark must hold exactly one series), computed locally in DuckDB. Returns (simple or log) are computed over the timestamps both results share: beta = covar_samp(r_a, r_b) / var_samp(r_b), alpha = mean(r_a) - beta x mean(r_b) per period, r_squared = corr^2; fewer than min_obs (20) shared returns gives None (insufficient_data). Bars of different timeframes are refused unless period samples both to the same UTC buckets. With window, a rolling beta per window end. Large outputs are stored and you get a result_id.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
periodNoSample both to the last price per UTC bucket first (needed when their bars differ).
windowNoRolling beta over this many shared returns (one row per window end).
min_obsNoFewest shared returns for a static beta; below it None.
return_kindNoReturns used for both series.simple
price_columnNoNumeric price column in both results. Default: each model's first value column (close).
series_columnNoAsset column naming each series. Default: its group column.
asset_result_idYesA stored result of prices of one or more assets (one beta per series).
benchmark_result_idYesA stored result of prices of exactly one benchmark series (e.g. SPY).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), yet the description adds substantial behavior: local DuckDB computation, shared-timestamp return alignment, the None/insufficient_data outcome below min_obs, refusal of mismatched timeframes, and rolling output when window is set. It even discloses that large outputs are persisted and returned as a result_id, which is exactly the kind of context annotations cannot carry.

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?

dense but no waste

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?

With no output schema, the description partially compensates by naming the returned quantities (beta, alpha, r_squared, or None) and the result_id fallback, and annotations cover safety. It stops short of describing the full output shape/columns, so it is strong but not exhaustive.

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 3, but the description adds cross-parameter meaning the schema does not: the shared-timestamp alignment rule, the min_obs=20 cutoff behavior, and the fact that window yields one row per window end. These interactions go beyond per-parameter field descriptions.

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 states a precise operation: 'Beta of each asset series against a benchmark, from two stored price results ... computed locally in DuckDB.' That verb+resource combination is unmistakably distinct from every sibling (analytics_correlation, analytics_volatility, analytics_returns, etc.), and the added note that the benchmark must hold exactly one series further sharpens the scope.

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

Usage Guidelines3/5

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

Usage is only implied through prerequisites: two stored results are required, the benchmark must be a single series, and period is 'needed when their bars differ.' There is no explicit when-to-use-this-vs-an-alternative guidance (e.g., correlation vs beta), leaving the agent to infer selection.

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