Servidor MCP y CLI para PairBook, el motor de correlación y solapamiento de ETF que cubre más de 4.700 acciones y ETF de EE. UU. Cualquiera de los 11,3 millones de pares posibles puede compararse: 52.000+ pares populares vienen precalculados con solapamiento de carteras procedente de los emisores, y cualquier otra combinación se calcula bajo demanda a partir de series de rendimientos semanales. La API JSON subyacente es gratuita y estática, no requiere clave y se actualiza cada día de negociación tras el cierre de EE. UU.
Pregúntale a tu asistente de IA cosas como «¿está mi cartera demasiado concentrada?», «¿qué correlación hay entre QQQ y VOO, y cuánto se solapan?» o «encuentra diversificadores para NVDA» y podrá responder con cifras recientes y con fuentes en lugar de adivinar.
Claude Code
claude mcp add pairbook -- npx -y pairbook-mcpCursor: instalación con un clic con
Claude Desktop: añade esto a claude_desktop_config.json:
{
"mcpServers": {
"pairbook": {
"command": "npx",
"args": ["-y", "pairbook-mcp"]
}
}
}Cualquier otro cliente MCP funciona de la misma manera: ejecuta npx -y pairbook-mcp mediante stdio.
Related MCP server: TickerAPI
Herramienta | Qué responde |
| Cartera completa (de 2 a 30 posiciones): contribuciones de riesgo de Euler, ratio de diversificación y apuestas de riesgo independientes, bloques de correlación, drawdown frente a SPY, avisos de solapamiento de ETF entre los fondos en cartera |
| Correlación (1/3/5y, semanal), covarianza, beta frente al S&P 500, volatilidad y solapamiento de carteras para dos activos |
| Un activo: beta, volatilidad, rendimientos, activos más correlacionados |
| Correlaciones a 3 años más bajas/más negativas con un activo dado |
| Series de rendimientos semanales (hasta 156 semanas) para cálculos personalizados |
| "nvidia" → NVDA en todo el universo cubierto |
Pásale una cartera completa (de 2 a 30 posiciones, pesos opcionales) y te dirá qué posiciones son redundantes, dónde se concentra el riesgo, qué diversifica de verdad y si los ETF que tienes se solapan internamente:
pairbook portfolio AAPL:25 MSFT:25 NVDA:20 JNJ:15 XOM:15RISK
volatility 16.7% (weighted average of the parts: 29.0%)
beta vs SPY 0.99 market explains 73% of the moves (R2)
max drawdown -17.4% (2024-12-05 to 2025-04-03, SPY: -16.9%)
RISK BUDGET (share of portfolio risk vs share of capital)
NVDA ############ 43.1% risk 20% capital beta 2.18 risk engine <- 20% of the capital but 43% of the risk
AAPL ######## 27.1% risk 25% capital beta 1.06 diversifier
...La herramienta MCP analyze_portfolio devuelve el mismo análisis como JSON estructurado: contribuciones de riesgo de Euler, ratio de diversificación y apuestas de riesgo independientes, bloques de correlación que se mueven juntos, drawdown frente a SPY y avisos de solapamiento procedentes de los emisores entre los ETF mantenidos (que QQQ y VOO compartan el 53.5% de las mismas acciones es algo que ninguna otra herramienta de carteras informa). Cada fórmula está documentada en docs/methodology.md, los invariantes están cubiertos por pruebas, y nada es una previsión ni un consejo.
Los mismos datos en tu terminal, sin necesidad de instalar nada:
npx -y -p pairbook-mcp pairbook QQQ VOOo después de npm i -g pairbook-mcp:
pairbook QQQ VOO # compare two assets
pairbook NVDA # one asset's profile
pairbook search nvidia # find a ticker
pairbook AAPL MSFT --jsonCódigos de salida: 0 en caso de éxito, 1 ante cualquier error (los errores van a stderr). --json imprime un documento JSON válido en stdout, de modo que pairbook qqq voo --json | jq .correlation_weekly funciona directamente.
DGRO vs SCHD (data as of 2026-08-27)
correlation 1y 0.74 3y 0.88 5y 0.93
beta vs SPY DGRO 0.65 SCHD 0.52
volatility DGRO 11.4% SCHD 12.9%
overlap 20.8% across 32 common holdings (issuer files 2026-08-26)
https://www.pairbook.io/pair/dgro-vs-schd/PairBook es un especialista: correlación, solapamiento y estructura de diversificación. Combina bien con un servidor MCP general de datos de mercado que aporte cotizaciones, fundamentales y noticias, así que instala ambos y deja que tu asistente los combine.
Todo proviene de la API de PairBook gratuita: correlaciones calculadas sobre rendimientos semanales (ventanas de 1/3/5 años), solapamiento a partir de las divulgaciones de cartera de los emisores, recalculado cada día de negociación. El conjunto de datos también se publica como descargas CSV con un DOI.
Gratuito con atribución (un enlace de vuelta a pairbook.io). Solo acciones y ETF cotizados en EE. UU. Nada de esto es asesoramiento de inversión.
El servidor y la CLI se ejecutan íntegramente en tu máquina y son de solo lectura. Llaman a un único host (www.pairbook.io) para obtener datos públicos de mercado, se identifican con una versión y una cadena de superficie en el user agent, y no envían nada más: ni prompts, ni contenido de conversaciones, ni datos personales, ni telemetría. Política completa: pairbook.io/privacy.
MIT © VoidLab
Whole-portfolio risk and diversification analysis for 2 to 30 US stocks or ETFs: which positions are redundant, where the risk concentrates (Euler risk contributions), what actually diversifies, portfolio volatility, beta and market R2, diversification ratio, effective number of independent bets, correlation blocks that move together, max drawdown of the mix vs SPY, and issuer-sourced holdings-overlap warnings between the ETFs held. Use compare_pair for just two assets. Covers ~4,700 US-listed stocks and ETFs only (no crypto, no foreign listings, no inverse/leveraged short funds, no intraday data); figures use weekly closes and refresh once per trading day. Unknown tickers return an error: resolve them with resolve_symbol first.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | auto (default) includes the correlation matrix up to 12 positions; compact never includes it | |
| positions | Yes | The holdings. Example: [{symbol:'AAPL',weight:40},{symbol:'MSFT',weight:30},{symbol:'SCHD',weight:30}] |
| Name | Required | Description |
|---|---|---|
| meta | Yes | |
| flags | Yes | |
| notes | Yes | |
| terms | No | |
| clusters | Yes | |
| drawdown | Yes | |
| portfolio | Yes | |
| positions | Yes | |
| redundant_pairs | Yes | |
| correlation_matrix | No | |
| etf_overlap_warnings | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, but the description adds substantial behavioral context beyond those: weekly close frequency, once-per-trading-day refresh, no intraday data, coverage limits, holdings-overlap warnings, and error behavior for unknown tickers. It does not contradict the annotations.
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?
The description is dense but every clause carries information: scope, outputs, alternatives, exclusions, data cadence, limitations, and error handling. The key purpose is front-loaded, and the alternative routing appears mid-description in a natural place. No filler or repetition of schema details is present.
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?
For a complex analysis tool with an output schema and safety annotations, the description covers everything needed to invoke it correctly: input constraints, supported asset types, data freshness, excluded instruments, error behavior, and sibling routing. It is complete enough that an agent can select and call this tool without further inference.
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 has 100% description coverage for positions and detail, so the baseline is 3. The description adds context beyond the schema by clarifying the asset universe, position count range, and ticker-resolution requirement, which helps the agent choose valid parameter values. It does not need to repeat schema-level normalization rules, so a 4 is warranted.
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 specific verb and resource: whole-portfolio risk and diversification analysis for 2 to 30 US stocks or ETFs. It enumerates concrete outputs (Euler risk contributions, diversification ratio, effective number of bets, correlation blocks) and immediately distinguishes itself from the compare_pair sibling.
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 description explicitly says 'Use compare_pair for just two assets,' which is a direct alternative-routing instruction. It also gives exclusions (no crypto, no foreign listings, no inverse/leveraged funds) and tells the agent to resolve unknown tickers with resolve_symbol first, making when-to-use and when-not-to-use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Correlation (weekly returns), annualized covariance, beta vs S&P 500, volatility, max drawdown, calendar-year returns, fund facts (fees, yield, AUM) or stock fundamentals (market cap, P/E), and ETF holdings overlap with top common positions, for a pair of US stocks or ETFs. Popular pairs come from PairBook's precomputed matrix; any other pair of covered symbols is computed on demand from the weekly return series. Example: a=QQQ, b=VOO. Symbol order does not matter. Covers ~4,700 US-listed stocks and ETFs only (no crypto, no foreign listings, no inverse/leveraged short funds, no intraday data); figures use weekly closes and refresh once per trading day. Unknown tickers return an error: resolve them with resolve_symbol first.
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | First ticker, e.g. AAPL or SPY | |
| b | Yes | Second ticker, e.g. MSFT or VOO |
| Name | Required | Description |
|---|---|---|
| a | Yes | |
| b | Yes | |
| docs | No | |
| fund | No | |
| note | No | |
| page | No | |
| as_of | Yes | |
| terms | No | |
| fundamentals | No | |
| beta_vs_spy_3y | No | |
| holdings_overlap | No | |
| computed_on_demand | No | |
| correlation_weekly | Yes | |
| max_drawdown_3y_pct | No | |
| volatility_ann_pct_3y | No | |
| covariance_ann_pct2_3y | No | |
| calendar_year_returns_pct | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint/idempotentHint/destructiveHint annotations, the description reveals important behaviors: popular pairs are served from a precomputed matrix, any other pair is computed on demand from weekly returns, data refreshes once per trading day, and unknown tickers produce an error. These are precisely the behavioral traits an agent needs to set expectations.
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?
The description is dense but every sentence earns its place: output list, coverage universe, computation mode, example, commutativity, limitations, refresh cadence, and error handling. The most important purpose is front-loaded, and details are logically organized rather than padded.
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?
For a pairwise comparison tool with an output schema and safety annotations, this description is complete: it defines the symbol universe, data frequency, computation path, return value caveats, and failure mode. An agent can determine correct usage and expected behavior without needing supplemental information.
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 both parameters at 100% coverage, so the baseline is 3. The description adds material value by explicitly stating 'Symbol order does not matter' and providing a concrete example (a=QQQ, b=VOO), which removes a likely ambiguity about whether parameter order is significant.
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 clearly specifies the verb 'Compare' with a resource ('a pair of US stocks or ETFs') and enumerates the exact outputs computed, from correlation and beta to holdings overlap. This clearly differentiates it from siblings like symbol_profile and analyze_portfolio, which are single-asset or multi-asset portfolio tools.
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 description gives strong usage context: it covers US-listed equities/ETFs only, excludes crypto, foreign listings, inverse/leveraged funds, and intraday data, and explicitly instructs agents to call resolve_symbol first for unknown tickers. It stops short of naming sibling alternatives such as find_diversifiers or analyze_portfolio for when a single comparison is not the right fit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Assets with the lowest or most negative 3-year correlation to the given US stock or ETF, each with its name and kind so you can screen them. Raw lowest-correlation list: it can contain leveraged/inverse ETNs, volatility products and illiquid micro-caps. Check name and kind before presenting anything as a portfolio diversifier. Covers ~4,700 US-listed stocks and ETFs only (no crypto, no foreign listings, no inverse/leveraged short funds, no intraday data); figures use weekly closes and refresh once per trading day. Unknown tickers return an error: resolve them with resolve_symbol first.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Ticker to diversify away from, e.g. QQQ |
| Name | Required | Description |
|---|---|---|
| docs | No | |
| name | No | |
| page | No | |
| as_of | Yes | |
| terms | No | |
| symbol | Yes | |
| caution | No | |
| diversifiers_3y | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although annotations already mark this as read-only and idempotent, the description adds substantial behavioral context: the raw list may contain leveraged/inverse ETNs, volatility products, and illiquid micro-caps, so name and kind must be checked before presenting results. It also discloses weekly-close data, once-per-day refresh, and error behavior for unknown tickers. This goes well beyond the annotations.
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?
The description is dense but every clause earns its place: purpose, output elements, caveats, coverage scope, data frequency, and error handling. The key purpose is front-loaded, and the warnings are packed into a compact but readable warning block. Nothing is redundant with 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?
For a one-parameter read-only tool with an output schema, the description covers all essential operational knowledge: coverage universe, refresh cadence, error behavior, and important content warnings. An agent has enough information to invoke it correctly and to interpret results safely.
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 single parameter has a clear description ('Ticker to diversify away from, e.g. QQQ'). The tool description adds extra meaning by specifying that the ticker must be a US stock or ETF and that unknown tickers error out. This is valuable enrichment beyond the schema field.
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: it finds assets with the lowest or most negative 3-year correlation to a given US stock or ETF. It also mentions the output includes name and kind, making the tool's function and scope clear. This distinguishes it from siblings like symbol_profile or compare_pair.
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 description gives clear context for when the tool is appropriate: US-listed stocks and ETFs only, no crypto, no foreign listings, no intraday data. It also tells the agent to resolve unknown tickers via resolve_symbol first, which is direct cross-tool guidance. It does not explicitly name alternative siblings for related tasks, but the conditions are strong enough for an agent to select it correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the ticker for a company or fund name (e.g. 'nvidia' -> NVDA) across PairBook's ~4,700 covered US stocks and ETFs. Call this before other tools whenever the exact ticker is uncertain or a lookup returned not-found.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum matches to return (default 8) | |
| query | Yes | Company or fund name, or partial ticker |
| Name | Required | Description |
|---|---|---|
| note | No | |
| matches | Yes | |
| total_matches | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is fully covered. The description adds useful context about the coverage universe (~4,700 US stocks/ETFs) and that it can match company names or partial tickers, but it does not substantially expand on behavioral details beyond what annotations and schema already indicate.
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?
The description is only two sentences, with the core purpose and an example stated first, followed by the usage directive. Every sentence earns its place, and there is no redundant or filler content.
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?
The tool is simple with only two parameters, rich annotations, and an output schema. The description covers the purpose, usage timing, and scope, so an agent has everything needed to select and invoke it correctly.
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%, so the parameter semantics are already fully documented in the schema. The description adds a helpful example for 'query' but no additional meaning for 'limit' or deeper formatting details, so the baseline of 3 is appropriate.
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 clearly states a specific action ('Find the ticker'), the target resource (PairBook's ~4,700 covered US stocks and ETFs), and gives a concrete example ('nvidia' -> NVDA). It is clearly distinguished from siblings like compare_pair or weekly_returns because it is specifically a name-to-ticker resolver.
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 description explicitly tells the agent when to use this tool: 'Call this before other tools whenever the exact ticker is uncertain or a lookup returned not-found.' This provides clear procedural guidance relative to all siblings, making the intended invocation order unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One US stock or ETF: beta vs S&P 500, annualized volatility, 1/3/5-year returns, max drawdown, calendar-year returns, fund facts or stock fundamentals, and its most correlated assets. For diversification candidates use find_diversifiers. Covers ~4,700 US-listed stocks and ETFs only (no crypto, no foreign listings, no inverse/leveraged short funds, no intraday data); figures use weekly closes and refresh once per trading day. Unknown tickers return an error: resolve them with resolve_symbol first.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Ticker, e.g. NVDA or SCHD |
| Name | Required | Description |
|---|---|---|
| docs | No | |
| fund | No | |
| kind | No | |
| name | No | |
| page | No | |
| as_of | Yes | |
| group | No | |
| terms | No | |
| symbol | Yes | |
| return_pct | No | |
| fundamentals | No | |
| beta_vs_spy_3y | No | |
| diversifiers_3y | No | |
| most_correlated_3y | No | |
| max_drawdown_3y_pct | No | |
| volatility_ann_pct_3y | No | |
| calendar_year_returns_pct | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description adds meaningful behavioral context: data uses weekly closes, refreshes once per trading day, excludes intraday data, covers only US-listed stocks/ETFs, and returns an error for unknown tickers. These details clarify what the agent can expect and pre-empt common failure modes.
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?
The description is dense but efficient: it front-loads the returned profile fields, then provides routing guidance, coverage constraints, refresh cadence, and error handling. Every sentence contributes necessary information without redundancy.
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?
Given the single required parameter, the presence of an output schema, and the annotations, the description is complete. It covers intended use, sibling alternatives, universe restrictions, data frequency, and error behavior, leaving no practical gap for an agent deciding whether and how to call this 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 the single symbol parameter with an example, so schema coverage is 100%. The description adds extra semantic context by clarifying that the symbol must be a US stock or ETF, describing coverage limits, and noting that unknown tickers produce an error resolvable with resolve_symbol.
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 clearly identifies the resource (a single US stock or ETF) and enumerates the metrics returned, including beta, volatility, returns, drawdown, and correlated assets. It also distinguishes itself from find_diversifiers, though it lacks an explicit action verb and does not differentiate against all siblings like compare_pair or analyze_portfolio.
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 description gives explicit routing guidance: 'For diversification candidates use find_diversifiers.' It also states when the tool should be used versus alternatives by defining the universe and exclusions, and directs users to resolve_symbol for unknown tickers before calling this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Weekly return series for one US stock or ETF (W-FRI, most recent last, all series end on the same Friday so tails align across symbols), for custom correlation or risk math. Covers ~4,700 US-listed stocks and ETFs only (no crypto, no foreign listings, no inverse/leveraged short funds, no intraday data); figures use weekly closes and refresh once per trading day. Unknown tickers return an error: resolve them with resolve_symbol first.
| Name | Required | Description | Default |
|---|---|---|---|
| weeks | No | Only return the most recent N weeks (default: all, up to 156) | |
| symbol | Yes | Ticker, e.g. AAPL |
| Name | Required | Description |
|---|---|---|
| docs | No | |
| freq | No | |
| as_of | Yes | |
| terms | No | |
| symbol | Yes | |
| returns | Yes | |
| window_weeks | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive, so the description adds substantial behavioral context: W-FRI weekly closes, most recent last, aligned end Fridays, ~4,700 US-listed symbols only, exclusions, once-per-trading-day refresh, and error behavior for unknown tickers. No contradiction 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
One dense paragraph with useful details front-loaded: series format and target use come first, coverage and refresh constraints follow. Slightly long but every clause conveys a distinct operational fact.
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?
For a two-parameter tool with rich annotations and an output schema, the description covers the essential usage context: data scope, exclusions, refresh cadence, calendar alignment, and error handling. An agent has enough information to select and call the tool correctly.
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?
Input schema covers both parameters at 100%, and the description adds extra meaning beyond the schema: symbol domain restrictions (US-listed stocks/ETFs, no crypto/foreign/inverse funds), unknown-ticker error behavior, and the weekly cadence. This meaningfully supplements the schema's basic type descriptions.
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?
Clearly states the tool returns a weekly return series for one US stock or ETF, with an explicit purpose ('for custom correlation or risk math'). The single-symbol scope and series alignment details distinguish it from sibling tools like compare_pair, analyze_portfolio, and find_diversifiers.
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?
Names the intended use case ('custom correlation or risk math') and explicitly instructs users to resolve unknown tickers with resolve_symbol first. It does not enumerate when to choose this tool over every sibling, but the constraints and workflow guidance are clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.3.1analyze_portfoliocompare_pairfind_diversifiersresolve_symbolsymbol_profileweekly_returnsScored across 6 tools
Each tool targets a distinct level of analysis: single-symbol profile, pair comparison, portfolio analysis, raw return series, ticker resolution, and diversifier discovery. The only mild ambiguity is between compare_pair and analyze_portfolio for two-asset cases, but the descriptions explicitly state analyze_portfolio should be used for 2–30 assets and compare_pair for just two.
Tool names are uniformly lowercase and underscore-separated, and most follow verb_noun structure: compare_pair, find_diversifiers, resolve_symbol, analyze_portfolio. symbol_profile and weekly_returns break that pattern slightly by being noun phrases, but the naming remains predictable and readable.
Six tools is a well-scoped set for a financial analytics server: symbol resolution, single-asset profile, pair analysis, portfolio analysis, raw data access, and diversifier discovery each cover a distinct workflow without redundancy.
The core analytical workflows are well covered: resolving tickers, profiling a single asset, comparing pairs, finding diversifiers, fetching raw returns, and analyzing a full portfolio. Minor gaps remain, such as no bulk multi-symbol return/correlation endpoint or a standalone holdings-overlap tool, but agents can work around these with existing tools.
US ETF and mutual fund holdings, which ETFs hold a stock, overlap, look-through. Free, no API key.
Performance, risk, comparisons, backtests and screening for US stocks and ETFs, with charts.
Daily end-of-day OHLCV stock data for U.S.-listed symbols, 15 years of history. Free API key.
Stocks, ETFs, crypto, commodities, forex: quotes, fundamentals, SEC filings, point-in-time history.
