Redstone Markets
Server Details
Performance, risk, comparisons, backtests and screening for US stocks and ETFs, with charts.
- Status
- Healthy
- Uptime
- 100.0% over 22 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- ChatGPT
- –
- Claude
- Redstone
TDQS
Scored across 6 tools
Each tool maps to a distinct resource+action pair (backtest a user-described portfolio, fetch a public portfolio, single-security metrics, multi-security compare, screen, search portfolios), and descriptions include explicit 'Not for...' disambiguation clauses that separate the closest neighbors. The main residual overlap is backtest_portfolio vs get_portfolio and get_security_metrics vs compare_securities, but the descriptions resolve these clearly.
All six names follow a consistent snake_case verb_noun pattern (backtest_, compare_, get_, get_, screen_, search_). The verb choice is meaningful and predictable across the set.
Six tools is well-scoped for a market analytics server, with each tool covering a distinct analytic surface (single, comparison, portfolio, backtest, screen, discovery). No tool appears redundant or filler.
The surface covers the core analytics lifecycle: discover portfolios, inspect a portfolio, backtest a hypothetical, evaluate a security, compare securities, and screen the universe. Minor gaps remain — there is no ticker/name lookup or reference-data tool (e.g. resolving a symbol, listing an ETF's holdings or sector), which could dead-end an agent needing to identify an instrument before acting.
Available Tools
6 toolsbacktest_portfolioBacktest a stock and ETF portfolioARead-onlyIdempotentInspect
Use this when the user describes a portfolio of US stocks and ETFs with weights (e.g. "60% VTI, 40% BND", "equal parts AAPL, MSFT, NVDA") and wants to know how it would have done or how risky it is: returns over YTD, 1 year and 5 years (rebalanced quarterly), max drawdown, volatility, Sharpe, beta vs SPY, dividend yield and the correlation between holdings, charted against SPY, with a link that opens it on Redstone to save. 2 to 20 holdings. Not for live brokerage accounts, trading or allocation advice.
| Name | Required | Description | Default |
|---|---|---|---|
| positions | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| url | Yes | Opens Redstone's New portfolio form filled in with this mix, to save it and follow it on a dashboard |
| asOf | Yes | Market date (YYYY-MM-DD) of the latest close behind every number |
| holdings | Yes | |
| benchmark | Yes | SPY, for comparison |
| portfolio | Yes | Backtest of the weights, rebalanced back to them every quarter |
| correlation | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior, and the description adds meaningful computation details: quarterly rebalancing, benchmark comparison against SPY, and a shareable Redstone link. It stops short of explaining handling of invalid or unknown tickers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is front-loaded with the usage trigger, then layers outputs, constraints, and exclusions without wasted text. Though dense, every clause contributes to correct invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema available, the description need not enumerate return values, and it still summarizes the key computed metrics and charting behavior. It gives enough context for an agent to decide whether and how to call the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents ticker format and weight rescaling, but the description adds the 2-to-20 holdings range and practical input forms such as '60% VTI, 40% BND' and 'equal parts AAPL, MSFT, NVDA'. This meaningfully helps an agent construct the positions array.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('backtest ... portfolio') and immediately scopes it to weighted US stock/ETF portfolios with named example inputs. The trigger conditions and listed outputs make it clearly distinct from sibling tools like compare_securities and get_security_metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use conditions (user describes a weighted portfolio and wants historical performance or risk) plus concrete examples. It also provides exclusions ('Not for live brokerage accounts, trading or allocation advice') and the 2-to-20-holding constraint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_securitiesCompare stocks or ETFsARead-onlyIdempotentInspect
Use this when the user wants to compare 2 to 5 US stocks or ETFs side by side (e.g. "VOO vs QQQ", "SCHD or VYM?"): returns, drawdown, volatility, Sharpe, beta, dividend yield and how correlated they are, with an overlaid 1Y/5Y chart. End-of-day data for US large and mid caps, major foreign stocks and US ETFs. Not for intraday quotes or recommendations on what to buy.
| Name | Required | Description | Default |
|---|---|---|---|
| tickers | Yes | Tickers to compare, in the order the user named them |
Output Schema
| Name | Required | Description |
|---|---|---|
| url | Yes | Redstone compare page (pairs only) |
| asOf | Yes | Market date (YYYY-MM-DD) of the latest close behind every number |
| securities | Yes | |
| correlation | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, non-destructive), so the description adds real value by disclosing data freshness ('end-of-day data') and the supported universe (US large/mid caps, major foreign stocks, US ETFs). It doesn't mention latency, rate limits, or what happens with an unknown ticker, which keeps it short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences: the trigger plus examples come first, coverage and exclusions after. Every clause carries information an agent would otherwise have to guess, and nothing is repeated from structured fields except the unavoidable ticker count.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description needn't explain return shape; it instead supplies the universe, freshness, and chart timeframes an agent needs to decide eligibility. Nothing required to call this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description only restates the schema's own constraints (2 to 5 tickers, US symbols). No extra meaning is added about ordering, casing, or how invalid or non-US tickers are handled, so this sits at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('compare 2 to 5 US stocks or ETFs side by side') and enumerates the exact outputs (returns, drawdown, volatility, Sharpe, beta, dividend yield, correlation, overlaid chart). The concrete examples ('VOO vs QQQ', 'SCHD or VYM?') make it instantly distinguishable from get_security_metrics and screen_securities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Opens with an explicit trigger ('Use this when the user wants to compare...') and closes with explicit exclusions ('Not for intraday quotes or recommendations on what to buy'). Both the when and the when-not are stated, so no inference is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_portfolioGet a shared or model portfolioARead-onlyIdempotentInspect
Use this when the user asks about one public Redstone portfolio, usually a search_portfolios result: its holdings with each one's own figures, its returns over YTD, 1 year and 5 years, max drawdown, volatility, Sharpe, beta and dividend yield, charted against SPY. Not for a portfolio the user describes (use backtest_portfolio) or private portfolios.
| Name | Required | Description | Default |
|---|---|---|---|
| portfolio | Yes | The portfolio's Redstone url, as search_portfolios returns it |
Output Schema
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| asOf | Yes | Market date (YYYY-MM-DD) of the latest close behind every number |
| holdings | Yes | The largest holdings, up to 20, with their own figures |
| benchmark | Yes | SPY, for comparison |
| portfolio | Yes | As its page shows it: rebalanced back to its weights every quarter |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile needs no restating. The description adds value by disclosing the data payload (holdings, return horizons, risk metrics, SPY benchmark) and the public-only constraint. It doesn't mention what happens with an invalid or stale URL, which is the one remaining behavioral unknown.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One dense sentence with the trigger front-loaded and exclusions trailing, so the reader hits the decision rule first. The long metric list is informative but slightly overstuffed for a description whose output schema already enumerates the returns.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description needn't detail return structure, and it correctly focuses on selection criteria and scope. Combined with full annotation coverage and a single required parameter, the definition is essentially complete; only failure-mode behavior for a bad URL is left unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is a single parameter with 100% schema description coverage, and the schema already states it is the Redstone URL as returned by search_portfolios. The description's phrase 'usually a search_portfolios result' reinforces the provenance but adds no format or validation detail beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-and-resource ('get one public Redstone portfolio') and immediately enumerates what comes back: holdings with per-holding figures, multi-horizon returns, drawdown, volatility, Sharpe, beta, dividend yield, charted against SPY. It also scopes the tool to public portfolios, which separates it from private-portfolio behavior and from backtest_portfolio without requiring the schema to be read.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit trigger ('when the user asks about one public Redstone portfolio, usually a search_portfolios result') and explicit exclusions with the alternative named: a portfolio the user describes goes to backtest_portfolio, and private portfolios are out of scope. The routing decision is fully determined from the description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_security_metricsGet stock or ETF performance and riskARead-onlyIdempotentInspect
Use this when the user asks how a single US stock or ETF has performed or how risky it is: YTD, 1-year and 5-year annualized returns, max drawdown, volatility, Sharpe, Sortino, beta, alpha and dividend yield, with a 1Y/5Y chart. End-of-day data for US large and mid caps, major foreign stocks and US ETFs. Not for intraday quotes, news, earnings, fundamentals or price targets.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | US ticker symbol, e.g. AAPL, VOO or BRK.B |
Output Schema
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| asOf | Yes | Market date (YYYY-MM-DD) of the latest close behind every number |
| security | Yes | |
| comparisons | Yes | Popular Redstone comparisons for this ticker |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavioral context: data is end-of-day (not intraday) and coverage is limited to US large/mid caps, major foreign stocks and US ETFs. It doesn't mention latency, pagination, or what happens for an uncovered ticker, which keeps it below a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both front-loaded: the trigger first, the metric payload second, the exclusions last. The dense metric list is functional specification rather than filler, and nothing repeats the schema or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return shape is handled elsewhere; the description still usefully previews the metric set and the 1Y/5Y chart. Combined with the coverage universe and exclusions, an agent has everything needed to decide to call this and to pass a valid ticker.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single ticker parameter, including examples (AAPL, VOO, BRK.B), so the baseline is 3. The description adds only indirect value by implying the universe of valid symbols (US large/mid caps, major foreign stocks, US ETFs) rather than saying anything new about ticker syntax or format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a concrete verb-and-resource pair ('how a single US stock or ETF has performed or how risky it is') and enumerates the exact metrics returned (returns, drawdown, volatility, Sharpe, Sortino, beta, alpha, dividend yield). The word 'single' distinguishes it from compare_securities without the agent needing to open either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit trigger ('Use this when the user asks how a single US stock or ETF has performed or how risky it is') and explicit exclusions ('Not for intraday quotes, news, earnings, fundamentals or price targets'). What's missing is naming the sibling to route to instead — compare_securities or screen_securities — for multi-ticker or screening use cases, so the agent must infer the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
screen_securitiesScreen stocks and ETFs by performance and riskARead-onlyIdempotentInspect
Use this when the user wants a ranked list of US stocks or ETFs by a performance, risk or dividend yield metric, optionally within a sector or ETF category (e.g. "lowest volatility dividend ETFs", "highest yielding bond ETFs", "highest Sharpe tech stocks this year", "energy stocks with the smallest drawdown"). Covers about 2,900 US-listed stocks and about 1,200 US ETFs, end-of-day. Not for fundamentals (P/E, revenue), news or buy recommendations.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Limit to stocks, ETFs, or both | all |
| limit | No | ||
| order | No | desc | |
| sector | No | Case-insensitive match on a stock's GICS sector (e.g. Information Technology, Health Care, Energy, Financials) or an ETF's category (e.g. Dividend, Bonds, Treasury, Large Cap Growth, Emerging Markets, Gold) | |
| sortBy | No | Metric to rank by. For lowest risk, sort volatility1yPct ascending, maxDrawdown1yPct descending (closest to 0) or beta1y ascending | return1yPct |
| filters | No | Optional bounds in each metric's own units, e.g. {metric: 'beta1y', max: 1}. maxDrawdown1yPct is negative, so a drawdown smaller than 20% is {metric: 'maxDrawdown1yPct', min: -20} |
Output Schema
| Name | Required | Description |
|---|---|---|
| url | Yes | Redstone screener with every column and filter |
| asOf | Yes | Market date (YYYY-MM-DD) of the latest close behind every number |
| results | Yes | |
| totalMatches | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, closed-world), so the description's added value is the universe size (~2,900 stocks / ~1,200 ETFs) and the end-of-day data cadence, both genuinely useful for deciding whether results will satisfy a request. It does not mention the 25-row cap or latency, but the cap is in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, tightly packed: usage trigger first, then universe scope, then exclusion. Nothing is repeated from schema or annotations, and the illustrative examples double as disambiguation rather than filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value explanation is unnecessary; the description instead supplies exactly the missing context an agent needs — universe size, data freshness, and hard exclusions. For a 6-parameter, zero-required read tool, nothing material is left ambiguous.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% and the undocumented parameters (limit, order) are low-risk defaults. The description earns extra credit by mapping natural-language intent onto sortBy semantics — 'lowest volatility dividend ETFs', 'smallest drawdown', 'highest Sharpe tech stocks' — showing how sector + sortBy + order compose, which the schema alone does not spell out.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: a ranked list of US stocks or ETFs by a performance, risk, or dividend metric. It bounds the universe (~2,900 stocks, ~1,200 ETFs, end-of-day) and explicitly excludes fundamentals, news, and recommendations, which distinguishes it sharply from get_security_metrics and compare_securities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The opening 'Use this when the user wants a ranked list...' plus the four quoted natural-language phrasings make the triggering condition concrete, and 'Not for fundamentals (P/E, revenue), news or buy recommendations' is an explicit exclusion. It stops short of naming sibling tools as alternatives, so routing decisions rely on inference from the exclusion rather than a direct pointer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_portfoliosFind shared and model portfoliosARead-onlyIdempotentInspect
Use this when the user wants to see real portfolios to learn from or copy (e.g. "show me low-drawdown dividend portfolios", "portfolios that hold SCHD", "the best risk-adjusted portfolios on Redstone"): the public portfolios Redstone's users built and shared, and Redstone's model portfolios, with past-year returns, risk and yield. Describe the kind of portfolio with the figure filters where one fits; nameIncludes only matches names, so keep it for themes no figure captures, such as "AI". Up to 10 results. Not for the user's own brokerage account or for recommending a portfolio to buy.
| Name | Required | Description | Default |
|---|---|---|---|
| holds | No | Tickers every result must hold | |
| limit | No | ||
| order | No | desc puts the highest first; for drawdown the highest is the shallowest | desc |
| madeBy | No | community: portfolios users built and shared; redstone: Redstone's model portfolios | anyone |
| sortBy | No | sharpe1y | |
| minSharpe | No | ||
| nameIncludes | No | Words to look for in portfolio names, e.g. 'dividend' or 'AI'; any one matching is enough | |
| minReturn1yPct | No | ||
| minDividendYieldPct | No | ||
| maxDrawdownNoWorseThanPct | No | Keep portfolios whose worst fall over the past year was no deeper than this, e.g. -10 |
Output Schema
| Name | Required | Description |
|---|---|---|
| url | Yes | Redstone's portfolio library, to sort and filter |
| asOf | Yes | Market date (YYYY-MM-DD) of the latest close behind every number |
| portfolios | Yes | |
| totalMatches | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent and non-destructive, so the description does not need to restate safety. It adds real context beyond them: result cap ('Up to 10 results') and the fact that results carry past-year returns, risk and yield. It stops short of describing pagination or result-completeness behavior, which keeps it off a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the use case, then the filter-selection rule, then the exclusions, so the most important content comes first. The single dense sentence packs in nested parentheticals and quoted examples, making it slightly harder to scan than it needs to be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description needn't explain return shapes, and it covers when to use, when not to, result caps and filter strategy for a 10-parameter tool. Minor gap: the numeric threshold parameters and default ordering are not given any semantic framing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50%, and the description compensates by explaining the crucial filter-selection rule: use the figure filters when a metric expresses the intent, and reserve nameIncludes for themes no figure captures like 'AI'. It doesn't clarify sortBy, minSharpe or the min* thresholds, leaving several undocumented params to be inferred from their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (search public/community and Redstone model portfolios) with concrete example queries, and clearly separates it from get_portfolio ('Not for the user's own brokerage account') and the metric tools by naming the returned dimensions (past-year returns, risk, yield). An agent can pick it over its siblings without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit trigger ('when the user wants to see real portfolios to learn from or copy'), concrete utterance examples, an explicit exclusion zone (own brokerage account, recommending a portfolio to buy), and routing guidance on choosing figure filters vs nameIncludes. Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
6 tool updates
- Changed
backtest_portfolio10 fields changed- changed
Output schema / properties / benchmark / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "alpha1yPct": { - "description": "Annualized, versus SPY", - "type": [ - "number", - "null" - ] - }, - "beta1y": { - "description": "Versus SPY, from daily returns over the past year", - "type": [ - "number", - "null" - ] - }, - "maxDrawdown1yPct": { - "description": "Worst peak-to-trough fall over the past year (negative)", - "type": [ - "number", - "null" - ] - }, - "name": { - "type": "string" - }, - "price": { - "description": "Latest close in USD", - "type": [ - "number", - "null" - ] - }, - "return1dPct": { - "type": [ - "number", - "null" - ] - }, - "return1yPct": { - "type": [ - "number", - "null" - ] - }, - "return5yAnnualizedPct": { - "type": [ - "number", - "null" - ] - }, - "returnYtdPct": { - "type": [ - "number", - "null" - ] - }, - "sector": { - "description": "GICS sector for stocks, category for ETFs", - "type": [ - "string", - "null" - ] - }, - "sharpe1y": { - "type": [ - "number", - "null" - ] - }, - "sortino1y": { - "type": [ - "number", - "null" - ] - }, - "statsSince": { - "description": "YYYY-MM-DD, set only when there is less than a year of history: the 1Y figures (return, drawdown, Sharpe, Sortino, beta, alpha) then run from this first close, and so does the YTD return if it falls this year. Screens on those metrics leave such securities out", - "type": [ - "string", - "null" - ] - }, - "ticker": { - "type": "string" - }, - "type": { - "enum": [ - "stock", - "etf" - ], - "type": "string" - }, - "url": { - "description": "Redstone page for this security", - "type": "string" - } - }, - "required": [ - "return1dPct", - "returnYtdPct", - "return1yPct", - "return5yAnnualizedPct", - "maxDrawdown1yPct", - "sharpe1y", - "sortino1y", - "beta1y", - "alpha1yPct", - "statsSince", - "ticker", - "name", - "type", - "sector", - "price", - "url" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "alpha1yPct": { + "description": "Annualized, versus SPY", + "type": [ + "number", + "null" + ] + }, + "beta1y": { + "description": "Versus SPY, from daily returns over the past year", + "type": [ + "number", + "null" + ] + }, + "dividendYieldPct": { + "description": "Trailing 12-month dividend yield: dividends that went ex in the past year over the latest close. 0 pays none; null when unknown (paid in another currency)", + "type": [ + "number", + "null" + ] + }, + "maxDrawdown1yPct": { + "description": "Worst peak-to-trough fall over the past year (negative)", + "type": [ + "number", + "null" + ] + }, + "name": { + "type": "string" + }, + "price": { + "description": "Latest close in USD", + "type": [ + "number", + "null" + ] + }, + "return1dPct": { + "type": [ + "number", + "null" + ] + }, + "return1yPct": { + "type": [ + "number", + "null" + ] + }, + "return5yAnnualizedPct": { + "type": [ + "number", + "null" + ] + }, + "returnYtdPct": { + "type": [ + "number", + "null" + ] + }, + "sector": { + "description": "GICS sector for stocks, category for ETFs", + "type": [ + "string", + "null" + ] + }, + "sharpe1y": { + "type": [ + "number", + "null" + ] + }, + "sortino1y": { + "type": [ + "number", + "null" + ] + }, + "statsSince": { + "description": "YYYY-MM-DD, set only when there is less than a year of history: the 1Y figures (return, drawdown, volatility, Sharpe, Sortino, beta, alpha, yield) then run from this first close, and so does the YTD return if it falls this year. Screens on those metrics leave such securities out", + "type": [ + "string", + "null" + ] + }, + "ticker": { + "type": "string" + }, + "type": { + "enum": [ + "stock", + "etf" + ], + "type": "string" + }, + "url": { + "description": "Redstone page for this security", + "type": "string" + }, + "volatility1yPct": { + "description": "Annualized standard deviation of daily returns over the past year", + "type": [ + "number", + "null" + ] + } + }, + "required": [ + "return1dPct", + "returnYtdPct", + "return1yPct", + "return5yAnnualizedPct", + "maxDrawdown1yPct", + "sharpe1y", + "sortino1y", + "beta1y", + "alpha1yPct", + "volatility1yPct", + "dividendYieldPct", + "statsSince", + "ticker", + "name", + "type", + "sector", + "price", + "url" + ], + "type": "object" + }, + { + "type": "null" + } +] - added
Output schema / properties / holdings / items / properties / dividendYieldPctAdded value: +{ + "description": "Trailing 12-month dividend yield: dividends that went ex in the past year over the latest close. 0 pays none; null when unknown (paid in another currency)", + "type": [ + "number", + "null" + ] +} - changed
Output schema / properties / holdings / items / properties / statsSince / descriptionPrevious value: -"YYYY-MM-DD, set only when there is less than a year of history: the 1Y figures (return, drawdown, Sharpe, Sortino, beta, alpha) then run from this first close, and so does the YTD return if it falls this year. Screens on those metrics leave such securities out"New value: +"YYYY-MM-DD, set only when there is less than a year of history: the 1Y figures (return, drawdown, volatility, Sharpe, Sortino, beta, alpha, yield) then run from this first close, and so does the YTD return if it falls this year. Screens on those metrics leave such securities out" - added
Output schema / properties / holdings / items / properties / volatility1yPctAdded value: +{ + "description": "Annualized standard deviation of daily returns over the past year", + "type": [ + "number", + "null" + ] +} - changed
Output schema / properties / holdings / items / requiredPrevious value: -[ - "return1dPct", - "returnYtdPct", - "return1yPct", - "return5yAnnualizedPct", - "maxDrawdown1yPct", - "sharpe1y", - "sortino1y", - "beta1y", - "alpha1yPct", - "statsSince", - "ticker", - "name", - "type", - "sector", - "price", - "url", - "weightPct" -]New value: +[ + "return1dPct", + "returnYtdPct", + "return1yPct", + "return5yAnnualizedPct", + "maxDrawdown1yPct", + "sharpe1y", + "sortino1y", + "beta1y", + "alpha1yPct", + "volatility1yPct", + "dividendYieldPct", + "statsSince", + "ticker", + "name", + "type", + "sector", + "price", + "url", + "weightPct" +] - added
Output schema / properties / portfolio / properties / dividendYieldPctAdded value: +{ + "description": "Trailing 12-month dividend yield: dividends that went ex in the past year over the latest close. 0 pays none; null when unknown (paid in another currency)", + "type": [ + "number", + "null" + ] +} - changed
Output schema / properties / portfolio / properties / statsSince / descriptionPrevious value: -"YYYY-MM-DD, set only when there is less than a year of history: the 1Y figures (return, drawdown, Sharpe, Sortino, beta, alpha) then run from this first close, and so does the YTD return if it falls this year. Screens on those metrics leave such securities out"New value: +"YYYY-MM-DD, set only when there is less than a year of history: the 1Y figures (return, drawdown, volatility, Sharpe, Sortino, beta, alpha, yield) then run from this first close, and so does the YTD return if it falls this year. Screens on those metrics leave such securities out" - added
Output schema / properties / portfolio / properties / volatility1yPctAdded value: +{ + "description": "Annualized standard deviation of daily returns over the past year", + "type": [ + "number", + "null" + ] +} - changed
Output schema / properties / portfolio / requiredPrevious value: -[ - "return1dPct", - "returnYtdPct", - "return1yPct", - "return5yAnnualizedPct", - "maxDrawdown1yPct", - "sharpe1y", - "sortino1y", - "beta1y", - "alpha1yPct", - "statsSince" -]New value: +[ + "return1dPct", + "returnYtdPct", + "return1yPct", + "return5yAnnualizedPct", + "maxDrawdown1yPct", + "sharpe1y", + "sortino1y", + "beta1y", + "alpha1yPct", + "volatility1yPct", + "dividendYieldPct", + "statsSince" +] - changed
Output schema / properties / url / descriptionPrevious value: -"Where to build and save this portfolio on Redstone"New value: +"Opens Redstone's New portfolio form filled in with this mix, to save it and follow it on a dashboard"
- Changed
compare_securities4 fields changed- added
Output schema / properties / securities / items / properties / dividendYieldPctAdded value: +{ + "description": "Trailing 12-month dividend yield: dividends that went ex in the past year over the latest close. 0 pays none; null when unknown (paid in another currency)", + "type": [ + "number", + "null" + ] +} - changed
Output schema / properties / securities / items / properties / statsSince / descriptionPrevious value: -"YYYY-MM-DD, set only when there is less than a year of history: the 1Y figures (return, drawdown, Sharpe, Sortino, beta, alpha) then run from this first close, and so does the YTD return if it falls this year. Screens on those metrics leave such securities out"New value: +"YYYY-MM-DD, set only when there is less than a year of history: the 1Y figures (return, drawdown, volatility, Sharpe, Sortino, beta, alpha, yield) then run from this first close, and so does the YTD return if it falls this year. Screens on those metrics leave such securities out" - added
Output schema / properties / securities / items / properties / volatility1yPctAdded value: +{ + "description": "Annualized standard deviation of daily returns over the past year", + "type": [ + "number", + "null" + ] +} - changed
Output schema / properties / securities / items / requiredPrevious value: -[ - "return1dPct", - "returnYtdPct", - "return1yPct", - "return5yAnnualizedPct", - "maxDrawdown1yPct", - "sharpe1y", - "sortino1y", - "beta1y", - "alpha1yPct", - "statsSince", - "ticker", - "name", - "type", - "sector", - "price", - "url" -]New value: +[ + "return1dPct", + "returnYtdPct", + "return1yPct", + "return5yAnnualizedPct", + "maxDrawdown1yPct", + "sharpe1y", + "sortino1y", + "beta1y", + "alpha1yPct", + "volatility1yPct", + "dividendYieldPct", + "statsSince", + "ticker", + "name", + "type", + "sector", + "price", + "url" +]
- Added
get_portfolio - Changed
get_security_metrics4 fields changed- added
Output schema / properties / security / properties / dividendYieldPctAdded value: +{ + "description": "Trailing 12-month dividend yield: dividends that went ex in the past year over the latest close. 0 pays none; null when unknown (paid in another currency)", + "type": [ + "number", + "null" + ] +} - changed
Output schema / properties / security / properties / statsSince / descriptionPrevious value: -"YYYY-MM-DD, set only when there is less than a year of history: the 1Y figures (return, drawdown, Sharpe, Sortino, beta, alpha) then run from this first close, and so does the YTD return if it falls this year. Screens on those metrics leave such securities out"New value: +"YYYY-MM-DD, set only when there is less than a year of history: the 1Y figures (return, drawdown, volatility, Sharpe, Sortino, beta, alpha, yield) then run from this first close, and so does the YTD return if it falls this year. Screens on those metrics leave such securities out" - added
Output schema / properties / security / properties / volatility1yPctAdded value: +{ + "description": "Annualized standard deviation of daily returns over the past year", + "type": [ + "number", + "null" + ] +} - changed
Output schema / properties / security / requiredPrevious value: -[ - "return1dPct", - "returnYtdPct", - "return1yPct", - "return5yAnnualizedPct", - "maxDrawdown1yPct", - "sharpe1y", - "sortino1y", - "beta1y", - "alpha1yPct", - "statsSince", - "ticker", - "name", - "type", - "sector", - "price", - "url" -]New value: +[ + "return1dPct", + "returnYtdPct", + "return1yPct", + "return5yAnnualizedPct", + "maxDrawdown1yPct", + "sharpe1y", + "sortino1y", + "beta1y", + "alpha1yPct", + "volatility1yPct", + "dividendYieldPct", + "statsSince", + "ticker", + "name", + "type", + "sector", + "price", + "url" +]
- Changed
screen_securities7 fields changed- changed
Input schema / properties / filters / items / properties / metric / enumPrevious value: -[ - "return1dPct", - "returnYtdPct", - "return1yPct", - "return5yAnnualizedPct", - "maxDrawdown1yPct", - "sharpe1y", - "sortino1y", - "beta1y", - "alpha1yPct" -]New value: +[ + "return1dPct", + "returnYtdPct", + "return1yPct", + "return5yAnnualizedPct", + "maxDrawdown1yPct", + "sharpe1y", + "sortino1y", + "beta1y", + "alpha1yPct", + "volatility1yPct", + "dividendYieldPct" +] - changed
Input schema / properties / sortBy / descriptionPrevious value: -"Metric to rank by. For lowest risk, sort maxDrawdown1yPct descending (closest to 0) or beta1y ascending"New value: +"Metric to rank by. For lowest risk, sort volatility1yPct ascending, maxDrawdown1yPct descending (closest to 0) or beta1y ascending" - changed
Input schema / properties / sortBy / enumPrevious value: -[ - "return1dPct", - "returnYtdPct", - "return1yPct", - "return5yAnnualizedPct", - "maxDrawdown1yPct", - "sharpe1y", - "sortino1y", - "beta1y", - "alpha1yPct" -]New value: +[ + "return1dPct", + "returnYtdPct", + "return1yPct", + "return5yAnnualizedPct", + "maxDrawdown1yPct", + "sharpe1y", + "sortino1y", + "beta1y", + "alpha1yPct", + "volatility1yPct", + "dividendYieldPct" +] - added
Output schema / properties / results / items / properties / dividendYieldPctAdded value: +{ + "description": "Trailing 12-month dividend yield: dividends that went ex in the past year over the latest close. 0 pays none; null when unknown (paid in another currency)", + "type": [ + "number", + "null" + ] +} - changed
Output schema / properties / results / items / properties / statsSince / descriptionPrevious value: -"YYYY-MM-DD, set only when there is less than a year of history: the 1Y figures (return, drawdown, Sharpe, Sortino, beta, alpha) then run from this first close, and so does the YTD return if it falls this year. Screens on those metrics leave such securities out"New value: +"YYYY-MM-DD, set only when there is less than a year of history: the 1Y figures (return, drawdown, volatility, Sharpe, Sortino, beta, alpha, yield) then run from this first close, and so does the YTD return if it falls this year. Screens on those metrics leave such securities out" - added
Output schema / properties / results / items / properties / volatility1yPctAdded value: +{ + "description": "Annualized standard deviation of daily returns over the past year", + "type": [ + "number", + "null" + ] +} - changed
Output schema / properties / results / items / requiredPrevious value: -[ - "return1dPct", - "returnYtdPct", - "return1yPct", - "return5yAnnualizedPct", - "maxDrawdown1yPct", - "sharpe1y", - "sortino1y", - "beta1y", - "alpha1yPct", - "statsSince", - "ticker", - "name", - "type", - "sector", - "price", - "url" -]New value: +[ + "return1dPct", + "returnYtdPct", + "return1yPct", + "return5yAnnualizedPct", + "maxDrawdown1yPct", + "sharpe1y", + "sortino1y", + "beta1y", + "alpha1yPct", + "volatility1yPct", + "dividendYieldPct", + "statsSince", + "ticker", + "name", + "type", + "sector", + "price", + "url" +]
- Added
search_portfolios
4 tool updates
- Changed
backtest_portfolio5 fields changed- changed
Output schema / properties / benchmark / anyOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "alpha1yPct": { - "description": "Annualized, versus SPY", - "type": [ - "number", - "null" - ] - }, - "beta1y": { - "description": "Versus SPY, from daily returns over the past year", - "type": [ - "number", - "null" - ] - }, - "maxDrawdown1yPct": { - "description": "Worst peak-to-trough fall over the past year (negative)", - "type": [ - "number", - "null" - ] - }, - "name": { - "type": "string" - }, - "price": { - "description": "Latest close in USD", - "type": [ - "number", - "null" - ] - }, - "return1dPct": { - "type": [ - "number", - "null" - ] - }, - "return1yPct": { - "type": [ - "number", - "null" - ] - }, - "return5yAnnualizedPct": { - "type": [ - "number", - "null" - ] - }, - "returnYtdPct": { - "type": [ - "number", - "null" - ] - }, - "sector": { - "description": "GICS sector for stocks, category for ETFs", - "type": [ - "string", - "null" - ] - }, - "sharpe1y": { - "type": [ - "number", - "null" - ] - }, - "sortino1y": { - "type": [ - "number", - "null" - ] - }, - "ticker": { - "type": "string" - }, - "type": { - "enum": [ - "stock", - "etf" - ], - "type": "string" - }, - "url": { - "description": "Redstone page for this security", - "type": "string" - } - }, - "required": [ - "return1dPct", - "returnYtdPct", - "return1yPct", - "return5yAnnualizedPct", - "maxDrawdown1yPct", - "sharpe1y", - "sortino1y", - "beta1y", - "alpha1yPct", - "ticker", - "name", - "type", - "sector", - "price", - "url" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "alpha1yPct": { + "description": "Annualized, versus SPY", + "type": [ + "number", + "null" + ] + }, + "beta1y": { + "description": "Versus SPY, from daily returns over the past year", + "type": [ + "number", + "null" + ] + }, + "maxDrawdown1yPct": { + "description": "Worst peak-to-trough fall over the past year (negative)", + "type": [ + "number", + "null" + ] + }, + "name": { + "type": "string" + }, + "price": { + "description": "Latest close in USD", + "type": [ + "number", + "null" + ] + }, + "return1dPct": { + "type": [ + "number", + "null" + ] + }, + "return1yPct": { + "type": [ + "number", + "null" + ] + }, + "return5yAnnualizedPct": { + "type": [ + "number", + "null" + ] + }, + "returnYtdPct": { + "type": [ + "number", + "null" + ] + }, + "sector": { + "description": "GICS sector for stocks, category for ETFs", + "type": [ + "string", + "null" + ] + }, + "sharpe1y": { + "type": [ + "number", + "null" + ] + }, + "sortino1y": { + "type": [ + "number", + "null" + ] + }, + "statsSince": { + "description": "YYYY-MM-DD, set only when there is less than a year of history: the 1Y figures (return, drawdown, Sharpe, Sortino, beta, alpha) then run from this first close, and so does the YTD return if it falls this year. Screens on those metrics leave such securities out", + "type": [ + "string", + "null" + ] + }, + "ticker": { + "type": "string" + }, + "type": { + "enum": [ + "stock", + "etf" + ], + "type": "string" + }, + "url": { + "description": "Redstone page for this security", + "type": "string" + } + }, + "required": [ + "return1dPct", + "returnYtdPct", + "return1yPct", + "return5yAnnualizedPct", + "maxDrawdown1yPct", + "sharpe1y", + "sortino1y", + "beta1y", + "alpha1yPct", + "statsSince", + "ticker", + "name", + "type", + "sector", + "price", + "url" + ], + "type": "object" + }, + { + "type": "null" + } +] - added
Output schema / properties / holdings / items / properties / statsSinceAdded value: +{ + "description": "YYYY-MM-DD, set only when there is less than a year of history: the 1Y figures (return, drawdown, Sharpe, Sortino, beta, alpha) then run from this first close, and so does the YTD return if it falls this year. Screens on those metrics leave such securities out", + "type": [ + "string", + "null" + ] +} - changed
Output schema / properties / holdings / items / requiredPrevious value: -[ - "return1dPct", - "returnYtdPct", - "return1yPct", - "return5yAnnualizedPct", - "maxDrawdown1yPct", - "sharpe1y", - "sortino1y", - "beta1y", - "alpha1yPct", - "ticker", - "name", - "type", - "sector", - "price", - "url", - "weightPct" -]New value: +[ + "return1dPct", + "returnYtdPct", + "return1yPct", + "return5yAnnualizedPct", + "maxDrawdown1yPct", + "sharpe1y", + "sortino1y", + "beta1y", + "alpha1yPct", + "statsSince", + "ticker", + "name", + "type", + "sector", + "price", + "url", + "weightPct" +] - added
Output schema / properties / portfolio / properties / statsSinceAdded value: +{ + "description": "YYYY-MM-DD, set only when there is less than a year of history: the 1Y figures (return, drawdown, Sharpe, Sortino, beta, alpha) then run from this first close, and so does the YTD return if it falls this year. Screens on those metrics leave such securities out", + "type": [ + "string", + "null" + ] +} - changed
Output schema / properties / portfolio / requiredPrevious value: -[ - "return1dPct", - "returnYtdPct", - "return1yPct", - "return5yAnnualizedPct", - "maxDrawdown1yPct", - "sharpe1y", - "sortino1y", - "beta1y", - "alpha1yPct" -]New value: +[ + "return1dPct", + "returnYtdPct", + "return1yPct", + "return5yAnnualizedPct", + "maxDrawdown1yPct", + "sharpe1y", + "sortino1y", + "beta1y", + "alpha1yPct", + "statsSince" +]
- Changed
compare_securities2 fields changed- added
Output schema / properties / securities / items / properties / statsSinceAdded value: +{ + "description": "YYYY-MM-DD, set only when there is less than a year of history: the 1Y figures (return, drawdown, Sharpe, Sortino, beta, alpha) then run from this first close, and so does the YTD return if it falls this year. Screens on those metrics leave such securities out", + "type": [ + "string", + "null" + ] +} - changed
Output schema / properties / securities / items / requiredPrevious value: -[ - "return1dPct", - "returnYtdPct", - "return1yPct", - "return5yAnnualizedPct", - "maxDrawdown1yPct", - "sharpe1y", - "sortino1y", - "beta1y", - "alpha1yPct", - "ticker", - "name", - "type", - "sector", - "price", - "url" -]New value: +[ + "return1dPct", + "returnYtdPct", + "return1yPct", + "return5yAnnualizedPct", + "maxDrawdown1yPct", + "sharpe1y", + "sortino1y", + "beta1y", + "alpha1yPct", + "statsSince", + "ticker", + "name", + "type", + "sector", + "price", + "url" +]
- Changed
get_security_metrics2 fields changed- added
Output schema / properties / security / properties / statsSinceAdded value: +{ + "description": "YYYY-MM-DD, set only when there is less than a year of history: the 1Y figures (return, drawdown, Sharpe, Sortino, beta, alpha) then run from this first close, and so does the YTD return if it falls this year. Screens on those metrics leave such securities out", + "type": [ + "string", + "null" + ] +} - changed
Output schema / properties / security / requiredPrevious value: -[ - "return1dPct", - "returnYtdPct", - "return1yPct", - "return5yAnnualizedPct", - "maxDrawdown1yPct", - "sharpe1y", - "sortino1y", - "beta1y", - "alpha1yPct", - "ticker", - "name", - "type", - "sector", - "price", - "url" -]New value: +[ + "return1dPct", + "returnYtdPct", + "return1yPct", + "return5yAnnualizedPct", + "maxDrawdown1yPct", + "sharpe1y", + "sortino1y", + "beta1y", + "alpha1yPct", + "statsSince", + "ticker", + "name", + "type", + "sector", + "price", + "url" +]
- Changed
screen_securities2 fields changed- added
Output schema / properties / results / items / properties / statsSinceAdded value: +{ + "description": "YYYY-MM-DD, set only when there is less than a year of history: the 1Y figures (return, drawdown, Sharpe, Sortino, beta, alpha) then run from this first close, and so does the YTD return if it falls this year. Screens on those metrics leave such securities out", + "type": [ + "string", + "null" + ] +} - changed
Output schema / properties / results / items / requiredPrevious value: -[ - "return1dPct", - "returnYtdPct", - "return1yPct", - "return5yAnnualizedPct", - "maxDrawdown1yPct", - "sharpe1y", - "sortino1y", - "beta1y", - "alpha1yPct", - "ticker", - "name", - "type", - "sector", - "price", - "url" -]New value: +[ + "return1dPct", + "returnYtdPct", + "return1yPct", + "return5yAnnualizedPct", + "maxDrawdown1yPct", + "sharpe1y", + "sortino1y", + "beta1y", + "alpha1yPct", + "statsSince", + "ticker", + "name", + "type", + "sector", + "price", + "url" +]
4 tool updates
- First observed
backtest_portfolio - First observed
compare_securities - First observed
get_security_metrics - First observed
screen_securities
Related MCP Connectors
Daily ML stock signals for 4,000+ US stocks, screening, company data and a portfolio optimizer.
Stock prices, charts & technical analysis for US stocks, ETFs and crypto. Read-only, no signup.
Financial statements, metrics, screens and insider trades for US-listed companies.
US stock quotes, analyst targets, superinvestor 13F, insider buys and earnings from SEC filings
Related MCP Servers
AlicenseAqualityAmaintenanceCorrelation, ETF holdings overlap, beta, volatility and diversifiers for 4,700+ US stocks and ETFs, any of 11.3M pairs. Free API, no key, read-only.6559 npm2MIT- AlicenseAqualityAmaintenanceDaily stock screens, RS ratings, market breadth and group rankings for 12 markets. No API keys.209414Apache 2.0
- AlicenseNot gradedqualityCmaintenanceEnables AI assistants to retrieve citable risk and return metrics—including Sharpe, Sortino, volatility, drawdowns, tail risk, correlations, and calendar-year returns—for stocks, ETFs, crypto, and commodities.CC BY-4.0
- AlicenseAqualityCmaintenanceEnables querying stock quotes and computing portfolio risk/return metrics such as Sharpe ratio, drawdown, volatility, and correlations, as well as historical summaries and asset comparisons.4MIT
Glama MCP Gateway
Add one secure layer between your agents and this server.