FinSight is a serverless, institutional-grade multi-asset portfolio analytics API that operates via pay-per-call USDC micropayments on the Tempo network — no account, subscription, or API key required.
Core Analytics Capabilities:
Risk Analysis ($0.01): Calculate Sharpe, Sortino, and Calmar ratios, market beta, per-asset risk scores, and portfolio-level risk tier (low / moderate / high / very high).
Rebalancing Recommendations ($0.02): Get target allocations via four methods — profile-based, risk parity, minimum variance, or equal weight — with per-asset actions (increase / reduce / hold) and deltas.
Diversification Scoring ($0.01): Evaluate portfolio concentration via the Herfindahl-Hirschman Index (HHI), with grades (excellent → critical) and breakdowns by asset class, region, and sector.
Macro Stress Testing ($0.03): Simulate performance across 10 macro scenarios (market crash, crypto winter, rate hike shock, recession, stagflation, geopolitical shock, dollar rally, etc.) with per-scenario worst/best asset identification.
Value-at-Risk & CVaR ($0.02): Compute parametric VaR and Conditional VaR (Expected Shortfall) at 95% and 99% confidence, including daily/annualized figures and worst-case dollar loss on $1M AUM.
Factor Exposure Analysis ($0.02): Analyze market beta, region/sector breakdowns, portfolio duration, weighted dividend yield, and currency exposure.
Correlation Matrix ($0.02): Generate a full cross-asset correlation matrix, average pairwise correlation, and diversification ratio.
Market Regime Detection ($0.02): Detect the current regime (risk_on / stable_growth / recovery / high_volatility / risk_off / crisis) from macro indicators and portfolio signals, with confidence levels and suggested adjustments.
Full Institutional Report ($0.10): Run all 8 modules in a single call, producing an executive summary with an overall score (0–100), grade (A–F), key strengths, risks, and top recommendations.
Portfolio Comparison ($0.05): Compare two portfolios side-by-side across 9 key metrics (Sharpe, Sortino, Calmar, VaR, CVaR, etc.) with a winner determination and recommendation.
Additional Features:
Dry-run mode: Append ?dry_run=true to any endpoint for free request validation without payment.
MCP compatibility: Works as an MCP stdio server for AI assistants like Claude and Cursor.
Global edge deployment: Built on Cloudflare Workers for low-latency serverless infrastructure.
FinSight is a pay-per-use financial portfolio analytics API designed to be consumed autonomously by AI agents (Claude, Cursor, Cline, and others) — no registration, no API key per user, just a USDC balance.
It combines two core technologies:
MCP (Model Context Protocol) — the standard for integrating AI agents with external tools and APIs
MPP (Machine Payment Protocol) + Tempo Blockchain — infrastructure for automated machine-to-machine micropayments
The result: an AI agent can analyze investment portfolios in real-time, pay per request on its own, and return quantitative results to the user — all without human intervention.
Live API: https://finsight-mpp.finsight-mpp.workers.dev
MPP is an HTTP standard for automated micropayments between machines. It works like HTTP auth but for payment challenge-response:
Server returns HTTP 402 Payment Required with a payment challenge
Client (AI agent) reads the challenge, pays on-chain, and attaches the payment proof
Server verifies the proof and serves the request
MPP enables a registrationless paid API — anyone with a wallet and USDC can use it immediately.
Tempo is an L2 blockchain (chainId: 4217) used as the USDC payment rails. Chosen for:
~500ms transaction confirmation — fast enough for per-request payments
~$0.001 gas fee — cheap enough for micropayments
Native TIP-20 token support (USDC) for stablecoin settlement
AI Agent / Client FinSight Worker Tempo Blockchain
│ │ │
├─── POST /analyze/risk ──────────►│ │
│ │ │
│◄── HTTP 402 + challenge ─────────┤ │
│ (amount, recipient, chainId) │ │
│ │ │
├─── Send USDC ───────────────────────────────────────────────────►│
│◄── TX Hash / Receipt ───────────────────────────────────────────┤
│ │ │
├─── POST /analyze/risk ──────────►│ │
│ Authorization: Bearer <hash> ├─── Verify TX ────────────────►│
│ │◄── Valid ─────────────────────┤
│◄── HTTP 200 + Analysis Result ───┤ │Component | Location | Purpose |
| Server (Cloudflare Worker) | Validates payment tokens from clients |
| Client (MCP Server) | Signs and generates payment tokens |
| Server | USDC recipient wallet address |
MPP_SECRET_KEY(server) andMPPX_SECRET_KEY(client) must share the same value.
Test without any on-chain transaction:
curl -X POST https://finsight-mpp.finsight-mpp.workers.dev/analyze/risk?dry_run=true \
-H "Authorization: Bearer <DRY_RUN_TOKEN>" \
-H "Content-Type: application/json" \
-d '{"holdings":[{"asset":"BTC","ticker":"BTC","weight":0.6},{"asset":"ETH","ticker":"ETH","weight":0.4}]}'Quantitative multi-asset portfolio analytics delivered as a Cloudflare Worker with micropayment gating via Tempo chain (USDC). Supports 70+ crypto tickers, 60+ US equity/ETF tickers, 30+ IDX Indonesia stocks, and macro indicators from FRED.
Source | Coverage | Cache TTL |
CoinGecko | 70+ crypto tickers, 365-day daily history | 5 min |
Twelve Data | 60+ US equity/ETF, 252-day daily history | 1 hr |
Yahoo Finance | 30+ IDX Indonesia stocks (.JK suffix) | 1 hr |
FRED | VIX, yield curve, CPI, GDP, unemployment, M2 | 1 hr |
Alternative.me | Fear & Greed Index (0-100) | 1 hr |
Computes real Pearson correlation rho(X,Y) = Cov(X,Y) / (sigma_X * sigma_Y) from daily log returns when price history is available for both assets. Falls back to asset-class heuristic estimates when no price data exists.
Uses the full covariance matrix formula sigma_p = sqrt(w^T * Sigma * w) where Sigma_ij = rho_ij * sigma_i * sigma_j. This correctly accounts for cross-asset correlations rather than assuming a single average correlation for all pairs.
Computed via OLS regression against SPY benchmark: beta = Cov(r_asset, r_SPY) / Var(r_SPY) from aligned daily log returns. SPY is always fetched as benchmark even when not in the portfolio. Falls back to asset-class defaults when insufficient data.
10 scenario simulations with beta-adjusted impacts. Market-wide scenarios (crash, recovery, recession) scale each asset's impact by its effective beta rather than using hardcoded constants. Sector-specific adjustments apply where relevant.
Scores portfolios on a 0-100 scale across 4 components (Sharpe, diversification, drawdown, profile alignment). Produces 5+ items per category (strengths, risks, recommendations) with quantitative backing — e.g., specific ratios, percentages, and thresholds.
VaR/CVaR — Parametric Value-at-Risk at 95% and 99% confidence
Monte Carlo — 10,000-path Geometric Brownian Motion simulation (Box-Muller RNG)
Diversification — HHI, effective asset count, asset-class/region/sector breakdown
Factor Exposure — Market beta, duration, dividend yield, currency exposure
Market Regime — Detection from macro indicators (VIX, yield curve, credit spreads)
Rebalancing — Risk parity, minimum variance, equal weight, profile-based
Portfolio Comparison — Side-by-side delta across 9 metrics
Endpoint | Method | Price | Description |
| GET | Free | API info and supported assets |
| GET | Free (2/day/IP) | Live demo with BTC+ETH+SPY+GLD |
| GET | Free | Full pricing table |
| GET | Free | Health check |
| GET | Free | MCP integration docs |
| POST | $0.005 | Sharpe, Sortino, Calmar, beta, risk tier |
| POST | $0.01 | Target weights by method |
| POST | $0.005 | HHI, breakdown, warnings |
| POST | $0.01 | 10 beta-adjusted scenarios |
| POST | $0.01 | VaR/CVaR at 95% and 99% |
| POST | $0.01 | Factor exposure analysis |
| POST | $0.01 | Pearson correlation matrix |
| POST | $0.01 | Market regime detection |
| POST | $0.02 | 10,000-path Monte Carlo |
| POST | $0.05 | Full report: all modules + executive summary |
| POST | $0.03 | Compare two portfolios |
All paid endpoints require USDC payment on Tempo chain (chainId: 4217) via the Machine Payment Protocol (MPP). Settlement is ~500ms with ~$0.001 gas.
Dry-run mode is available for development only when DRY_RUN_TOKEN is configured as a Wrangler secret. Requires Authorization: Bearer <token> header. Not publicly accessible.
{
"holdings": [
{ "asset": "BTC", "weight": 0.4, "assetClass": "crypto" },
{ "asset": "ETH", "weight": 0.3, "assetClass": "crypto" },
{ "asset": "SPY", "weight": 0.2, "assetClass": "equity" },
{ "asset": "GLD", "weight": 0.1, "assetClass": "commodity" }
],
"profile": "balanced",
"benchmarkReturn": 0.08,
"riskFreeRate": 0.05,
"rebalanceMethod": "risk_parity"
}Fields like avgReturn, volatility, and maxDrawdown are auto-populated from live data when the ticker is recognized. User-provided non-default values always take precedence.
BTC, ETH, SOL, BNB, XRP, ADA, AVAX, DOGE, DOT, TRX, TON, HBAR, ALGO, FTM, ICP, VET, XMR, BCH, KAS, FIL, FLOW, STX, ROSE, MATIC/POL, ARB, OP, STRK, IMX, MANTA, LINK, UNI, AAVE, MKR, CRV, LDO, SNX, COMP, GMX, DYDX, 1INCH, CAKE, ATOM, NEAR, APT, SUI, SEI, TIA, LTC, ETC, XLM, INJ, JUP, PYTH, RNDR, GRT, OCEAN, ENS, WLD, HYPE, ZRO, LIT, EIGEN, VIRTUAL, PEPE, WIF, BONK, TRUMP, SHIB, FLOKI, POPCAT, USDC, USDT, DAI, FRAX, USDS
SPY, QQQ, IWM, DIA, VTI, VOO, VEA, VWO, ARKK, GLD, SLV, TLT, IEF, BND, AGG, HYG, XLK, XLF, XLE, XLV, SOXX, SMH, AAPL, MSFT, GOOGL, AMZN, NVDA, TSLA, META, AMD, CRM, PLTR, COIN, MSTR, JPM, BAC, GS, V, MA, XOM, CVX, JNJ, UNH, LLY, WMT, COST, VNQ, O, AMT, BIL, SGOV, and more
BBCA, BBRI, BMRI, BBNI, TLKM, ASII, ADRO, PTBA, ANTM, GOTO, BUKA, KLBF, SIDO, BSDE, SMGR, and more
FinSight works as an MCP (Model Context Protocol) server for AI agents like Claude, Cursor, and Cline. See /llms.txt for setup instructions.
# Install dependencies
npm install
# Local development
npx wrangler dev
# Set secrets
wrangler secret put MPP_SECRET_KEY
wrangler secret put COINGECKO_API_KEY
wrangler secret put TWELVE_DATA_API_KEY
wrangler secret put FRED_API_KEY
wrangler secret put DRY_RUN_TOKEN
# Deploy
npx wrangler deployRATE_LIMITS — IP-based rate limiting (60 req/min)
CACHE — Report result cache (30s TTL)
MARKET_DATA — Price data and macro indicator cache
Runtime: Cloudflare Workers (edge deployment)
Framework: Hono (TypeScript)
Payment: MPP via Tempo chain (USDC)
Validation: Zod schemas with weight-sum verification
Caching: Cloudflare KV with versioned keys
v3.1.0 — Twelve Data equity provider, lower pricing, demo rate limiting (2/day/IP), real Pearson correlation, OLS beta, beta-adjusted stress tests.
Side-by-side comparison of two portfolios across 9 key metrics: Sharpe ratio, Sortino ratio, VaR, CVaR, max drawdown, diversification score, stress test loss, market beta, and overall risk tier. Returns winner per metric and delta values. Useful for A/B testing portfolio strategies or comparing current vs. rebalanced allocation. Costs $0.05 USDC.
| Name | Required | Description | Default |
|---|---|---|---|
| portfolio_a | Yes | First portfolio to compare. | |
| portfolio_b | Yes | Second portfolio to compare against portfolio_a. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the cost ($0.05 USDC) and implies a read-only operation (no mention of modification). However, it lacks explicit statement about non-destructive nature or any side effects. Score is adequate but not exceptional.
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 three sentences covering purpose, return value, and use cases/cost. Very concise with no redundant information. Front-loaded with key points.
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 complexity (nested portfolio objects, 9 metrics, cost), the description provides a good summary. It lacks details on parameter structure, but the comprehensive input schema covers that. The output (winner per metric and delta) is stated. Could mention required fields but schema already does.
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 baseline is 3. The description adds no parameter-specific details beyond what the schema already provides. It focuses on the output (metrics and delta values) rather than input parameters.
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 the tool performs a side-by-side comparison of two portfolios across 9 specific metrics, matching the tool name 'analyze_compare'. It also distinguishes from sibling tools (correlation, diversification, etc.) by focusing on direct comparison.
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 provides concrete use cases: 'A/B testing portfolio strategies' and 'comparing current vs. rebalanced allocation'. However, it does not explicitly mention when not to use this tool or suggest alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cross-asset correlation matrix and diversification ratio. Returns the full N×N correlation matrix, average pairwise correlation, diversification ratio (DR>1 = benefit), and asset-class pair correlations. Payment: $0.02 USDC on Tempo chain.
| Name | Required | Description | Default |
|---|---|---|---|
| holdings | Yes | ||
| profile | No | Risk profile — affects rebalance targets and scoring. Default: balanced. | |
| benchmarkReturn | No | Annual benchmark return for Sharpe calculation, e.g. 0.08 = 8%. Default: 0.08. | |
| riskFreeRate | No | Annual risk-free rate for Sortino and VaR excess return, e.g. 0.05 = 5%. Default: 0.05. | |
| rebalanceMethod | No | Portfolio construction method for rebalance recommendations. Default: profile. | |
| marketIndicators | No | Optional macro indicators — improves market regime detection confidence to HIGH when 3+ provided. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes outputs but discloses no behavioral traits such as read-only nature, rate limits, authentication needs, or error handling. Payment is mentioned but not behavioral.
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 efficient in stating purpose and outputs. Payment line is unconventional but informative. Could be slightly more structured, but it's concise and front-loaded.
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?
No output schema, so description explains return values (correlation matrix, avg pairwise correlation, diversification ratio, asset-class pair correlations). It covers core outputs and the payment caveat. Could clarify how data is fetched (schema covers this), but sufficient for basic understanding.
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 83%, with detailed parameter descriptions in the schema. The description adds no new parameter meaning beyond summarizing outputs. Baseline of 3 applies as schema does most of the work.
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?
Description clearly states it returns a correlation matrix and diversification ratio, specifying exact outputs (N×N matrix, avg pairwise correlation, DR>1 benefit, asset-class pair correlations). Distinguishes from sibling tools like analyze_diversification by focusing on correlation-specific 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?
No explicit guidance on when to use vs. alternatives like analyze_factors or analyze_compare. Does not mention prerequisites or scenarios where this tool is preferred. The payment mention hints at cost but does not guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Portfolio diversification analysis using Herfindahl-Hirschman Index (HHI). Returns concentration grade (excellent/good/moderate/poor/critical), effective number of assets, breakdown by asset class / region / sector, and concentration warnings. Payment: $0.01 USDC on Tempo chain.
| Name | Required | Description | Default |
|---|---|---|---|
| holdings | Yes | ||
| profile | No | Risk profile — affects rebalance targets and scoring. Default: balanced. | |
| benchmarkReturn | No | Annual benchmark return for Sharpe calculation, e.g. 0.08 = 8%. Default: 0.08. | |
| riskFreeRate | No | Annual risk-free rate for Sortino and VaR excess return, e.g. 0.05 = 5%. Default: 0.05. | |
| rebalanceMethod | No | Portfolio construction method for rebalance recommendations. Default: profile. | |
| marketIndicators | No | Optional macro indicators — improves market regime detection confidence to HIGH when 3+ provided. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden. It discloses the key behavioral aspects: returns specific outputs, auto-fetches data for known tickers, and requires a payment. No contradictory or missing critical disclosures.
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?
Three sentences, no wasted words. Key information (HHI analysis, outputs) is front-loaded, followed by payment detail. Efficient and well-structured.
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 complexity (6 parameters, nested objects, no output schema), the description covers the main outputs and payment. It lacks details on interpreting results (e.g., grade meanings) but is adequate for a well-named tool with high schema coverage.
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 high (83%), so baseline is 3. The description adds value with the payment note and auto-fetch hint but does not elaborate on each parameter beyond what the schema provides.
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 it performs portfolio diversification analysis using HHI, listing specific outputs like concentration grade, effective number of assets, and breakdowns. It distinguishes itself from sibling tools (e.g., analyze_risk, analyze_correlation) by focusing on diversification.
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 implies usage for diversification analysis but does not explicitly state when to use it versus alternatives or provide exclusions. The sibling tools cover other aspects, but no direct guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Factor exposure analysis: portfolio market beta, asset-class contributions, region/sector breakdown, interest-rate sensitivity (duration), dividend yield, currency exposure. Payment: $0.02 USDC on Tempo chain.
| Name | Required | Description | Default |
|---|---|---|---|
| holdings | Yes | ||
| profile | No | Risk profile — affects rebalance targets and scoring. Default: balanced. | |
| benchmarkReturn | No | Annual benchmark return for Sharpe calculation, e.g. 0.08 = 8%. Default: 0.08. | |
| riskFreeRate | No | Annual risk-free rate for Sortino and VaR excess return, e.g. 0.05 = 5%. Default: 0.05. | |
| rebalanceMethod | No | Portfolio construction method for rebalance recommendations. Default: profile. | |
| marketIndicators | No | Optional macro indicators — improves market regime detection confidence to HIGH when 3+ provided. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a behavioral trait: the tool charges $0.02 USDC. It also explains auto-fetching of live data for known tickers. However, it does not specify whether the operation is read-only or any side effects, though analysis tools are typically read-only. With no annotations, the description provides useful context but could be more thorough.
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 a single sentence that lists key factors and the payment. It is fairly concise and front-loaded with the main purpose. However, it could benefit from clearer structure, such as bullet points for factors.
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 complex with many parameters, a nested object, and no output schema. The description does not explain what the tool returns (e.g., a report or scores). While it mentions the factors analyzed, missing output details reduces completeness. The payment note and auto-fetching help but are not enough.
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 input schema covers 83% of parameters with descriptions. The tool description does not add significant new meaning beyond what the schema already provides; it only mentions the auto-fetching behavior for holdings. Since schema coverage is high, a score 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 the tool performs factor exposure analysis, listing specific factors (beta, asset-class contributions, region/sector breakdown, duration, dividend yield, currency exposure). This distinguishes it from siblings like analyze_correlation or analyze_risk, which focus on different aspects.
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 implies usage for factor analysis but provides no explicit guidance on when to use this tool versus alternatives like analyze_risk or analyze_diversification. There is no mention of when not to use it or prerequisite conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Portfolio rebalancing recommendations with live market data. Four methods: profile (conservative/balanced/aggressive), risk_parity (inverse-vol weighting), min_variance (inverse-variance), equal_weight (1/N). Returns target weight, current weight, action (increase/reduce/hold), and delta per asset. Known crypto tickers auto-enriched with real volatility data. Payment: $0.02 USDC on Tempo.
| Name | Required | Description | Default |
|---|---|---|---|
| holdings | Yes | ||
| profile | No | Risk profile — affects rebalance targets and scoring. Default: balanced. | |
| benchmarkReturn | No | Annual benchmark return for Sharpe calculation, e.g. 0.08 = 8%. Default: 0.08. | |
| riskFreeRate | No | Annual risk-free rate for Sortino and VaR excess return, e.g. 0.05 = 5%. Default: 0.05. | |
| rebalanceMethod | No | Portfolio construction method for rebalance recommendations. Default: profile. | |
| marketIndicators | No | Optional macro indicators — improves market regime detection confidence to HIGH when 3+ provided. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must cover behavioral traits. It discloses auto-enrichment of tickers and a payment of $0.02 USDC, but does not explicitly state that the operation is non-destructive or mention data freshness, rate limits, or side effects. Adequate but not comprehensive.
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 extremely concise—three sentences capturing purpose, methods, output, and special features. No redundant or unnecessary information. Front-loaded with the core action.
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 complexity (nested objects, multiple optional parameters) and no output schema, the description covers the essential output fields (target weight, current weight, action, delta) and the auto-enrichment feature. It could mention how market indicators affect results, but overall it's sufficient for an agent to use 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?
Schema description coverage is 83%, so the schema already documents parameters well. The description adds context about live data and payment but does not enhance parameter meaning beyond what the schema provides. 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 the tool provides portfolio rebalancing recommendations using live market data, lists four distinct methods, and describes the output structure. This is highly specific and easily distinguishes it from sibling tools like analyze_correlation or analyze_risk.
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 specifies four rebalancing methods and notes that known crypto tickers are auto-enriched, giving context for when to use the tool. It doesn't explicitly state when not to use it or mention alternatives, but the sibling names make the choice clear. Lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Market regime detection from macro indicators + portfolio signals. Regimes: risk_on | stable_growth | recovery | high_volatility | risk_off | crisis. Returns regime, confidence (low/medium/high), individual signals, portfolio-fit score (0-100), and suggested adjustments. Provide marketIndicators for higher confidence. Costs $0.02 USDC.
| Name | Required | Description | Default |
|---|---|---|---|
| holdings | Yes | ||
| profile | No | Risk profile — affects rebalance targets and scoring. Default: balanced. | |
| benchmarkReturn | No | Annual benchmark return for Sharpe calculation, e.g. 0.08 = 8%. Default: 0.08. | |
| riskFreeRate | No | Annual risk-free rate for Sortino and VaR excess return, e.g. 0.05 = 5%. Default: 0.05. | |
| rebalanceMethod | No | Portfolio construction method for rebalance recommendations. Default: profile. | |
| marketIndicators | No | Optional macro indicators — improves market regime detection confidence to HIGH when 3+ provided. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It lists the outputs (regime, confidence, signals, portfolio-fit score, suggested adjustments) and cost, but it does not disclose data sources, processing details, or any side effects. The behavioral transparency is adequate but not thorough.
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 concise with four sentences, front-loading the purpose and outputs. It is clear and free of extraneous information, though it could be slightly restructured for better readability.
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 tool with 6 parameters, nested objects, and no output schema, the description explains the returned items and cost but lacks details on interpretation or examples. It is moderately complete given the schema's good param descriptions.
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 high (83%), so the schema already documents most parameters. The description adds value by noting that marketIndicators improve confidence, but it does not provide additional meaning beyond the schema for other parameters.
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 it performs market regime detection from macro indicators and portfolio signals, listing the possible regimes and the outputs. It distinguishes itself from sibling tools like analyze_correlation or analyze_risk by focusing specifically on regime detection.
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 advises providing marketIndicators for higher confidence and mentions the cost, but it does not explicitly state when to use this tool versus alternatives or when not to use it. It lacks comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full report — all 8 modules in one call: risk + rebalance + diversification + stress_test (10 scenarios) + var_cvar + factor_exposure + correlation + market_regime. Includes ExecutiveSummary: overall score (0-100), grade (A-F), key strengths, key risks, top recommendations. Most cost-effective option for comprehensive analysis. Costs $0.10 USDC.
| Name | Required | Description | Default |
|---|---|---|---|
| holdings | Yes | ||
| profile | No | Risk profile — affects rebalance targets and scoring. Default: balanced. | |
| benchmarkReturn | No | Annual benchmark return for Sharpe calculation, e.g. 0.08 = 8%. Default: 0.08. | |
| riskFreeRate | No | Annual risk-free rate for Sortino and VaR excess return, e.g. 0.05 = 5%. Default: 0.05. | |
| rebalanceMethod | No | Portfolio construction method for rebalance recommendations. Default: profile. | |
| marketIndicators | No | Optional macro indicators — improves market regime detection confidence to HIGH when 3+ provided. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions cost and includes 8 modules, but lacks disclosure of side effects, authentication needs, rate limits, or error behaviors. Without annotations, more detail on behavioral traits is needed.
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 two sentences, concise and front-loaded with the core functionality and list of modules. No wasted words.
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 complexity (6 params, nested objects), the description provides a good overview of the output (executive summary) but does not explain score interpretation, error handling, or constraints beyond cost.
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 83%, so most parameters are already described. The tool description does not add significant value beyond what the schema provides.
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 the tool runs all 8 analysis modules in one call and provides an executive summary with score and grade. It distinguishes itself from sibling tools that only offer individual modules.
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 implies usage contexts by labeling itself as the 'most cost-effective option for comprehensive analysis,' but does not explicitly state when to avoid it or when to use siblings instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Crypto portfolio risk profiling using live CoinGecko market data. For known tickers (BTC, ETH, SOL, AVAX, ARB, etc.) you only need { asset, weight } — volatility, returns, and drawdown are auto-fetched from 365-day real price history. Returns Sharpe ratio, Sortino ratio, Calmar ratio, market beta, risk tier (low/moderate/high/very high), and per-asset risk scores. Payment: $0.01 USDC on Tempo chain (~500ms).
| Name | Required | Description | Default |
|---|---|---|---|
| holdings | Yes | ||
| profile | No | Risk profile — affects rebalance targets and scoring. Default: balanced. | |
| benchmarkReturn | No | Annual benchmark return for Sharpe calculation, e.g. 0.08 = 8%. Default: 0.08. | |
| riskFreeRate | No | Annual risk-free rate for Sortino and VaR excess return, e.g. 0.05 = 5%. Default: 0.05. | |
| rebalanceMethod | No | Portfolio construction method for rebalance recommendations. Default: profile. | |
| marketIndicators | No | Optional macro indicators — improves market regime detection confidence to HIGH when 3+ provided. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must itself disclose behavior. It covers key aspects: auto-fetches live data, computes specific ratios, and notes payment ($0.01 USDC, ~500ms). No contradictions, though it could mention potential side effects or auth needs.
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 concise (6 sentences), well-structured, and front-loaded with the core purpose. Every sentence adds essential 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?
For a tool with nested objects, 6 parameters, and no output schema, the description covers inputs, required vs optional, auto-fetched fields, return values (ratios and risk scores), and payment. Missing explicit output structure details but adequate overall.
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 83%, high, so baseline 3. The description adds value by clarifying that for known tickers only asset and weight are required, while others are auto-fetched. This goes beyond the schema's distinction of optional vs required.
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 the tool's purpose: 'Crypto portfolio risk profiling using live CoinGecko market data.' It specifies the verb (analyze/profiling), resource (portfolio risk), and distinguishes from siblings (e.g., analyze_factors, analyze_regime) by focusing on risk ratios and per-asset scores.
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 provides clear context on when to use: for portfolio risk profiling with known tickers, auto-fetching data. It explains inputs needed (asset, weight) but does not explicitly exclude when not to use or mention sibling tools as alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stress test across 10 macro scenarios using real portfolio volatility data: market_crash (-40%), crypto_winter (-70%), stablecoin_depeg, high_volatility, recovery_bull (+50%), rate_hike_shock, recession, stagflation, geopolitical_shock, dollar_rally. All shocks are asset-class and sector-aware. Returns P&L per scenario with worst/best asset. Payment: $0.03 USDC on Tempo chain.
| Name | Required | Description | Default |
|---|---|---|---|
| holdings | Yes | ||
| profile | No | Risk profile — affects rebalance targets and scoring. Default: balanced. | |
| benchmarkReturn | No | Annual benchmark return for Sharpe calculation, e.g. 0.08 = 8%. Default: 0.08. | |
| riskFreeRate | No | Annual risk-free rate for Sortino and VaR excess return, e.g. 0.05 = 5%. Default: 0.05. | |
| rebalanceMethod | No | Portfolio construction method for rebalance recommendations. Default: profile. | |
| marketIndicators | No | Optional macro indicators — improves market regime detection confidence to HIGH when 3+ provided. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that real portfolio volatility data is used, scenarios are sector-aware, and payment is required. It does not cover error handling, data freshness, or authentication, but for a stress test tool, the behavioral context is robust.
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 a single, well-structured paragraph that front-loads the core function. Every sentence adds information (scenarios, data source, output, payment) 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 tool's complexity (6 parameters, nested objects), the description explains the scenarios and output format adequately. It could elaborate on the return structure (e.g., data types) since no output schema is provided, but it gives sufficient context for an agent.
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 83%, so the schema already documents parameters well. The description adds value by listing the 10 scenarios and noting that known tickers auto-fetch data, which aids parameter understanding beyond the schema.
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 it performs stress testing across 10 named macro scenarios with specific impacts, and specifies the output (P&L per scenario with worst/best asset). This distinguishes it from sibling tools like analyze_risk (general risk) or analyze_regime (market regime detection).
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 provides context on when to use (portfolio stress testing) but does not explicitly state when not to use or compare to alternatives. The detailed scenario list and output description imply its purpose, yet exclusion criteria are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Value-at-Risk (VaR) and CVaR (Expected Shortfall) at 95% and 99% confidence. Uses real volatility auto-fetched from CoinGecko for known crypto tickers. Returns daily and annualised VaR/CVaR, worst-case dollar loss on $1M AUM, and interpretation. Payment: $0.02 USDC on Tempo chain.
| Name | Required | Description | Default |
|---|---|---|---|
| profile | No | Risk profile — affects rebalance targets and scoring. Default: balanced. | |
| holdings | Yes | ||
| riskFreeRate | No | Annual risk-free rate for Sortino and VaR excess return, e.g. 0.05 = 5%. Default: 0.05. | |
| benchmarkReturn | No | Annual benchmark return for Sharpe calculation, e.g. 0.08 = 8%. Default: 0.08. | |
| rebalanceMethod | No | Portfolio construction method for rebalance recommendations. Default: profile. | |
| marketIndicators | No | Optional macro indicators — improves market regime detection confidence to HIGH when 3+ provided. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses live data fetching from CoinGecko, auto-population for known tickers, and a payment cost of $0.02 USDC. However, it omits potential side-effects like error handling, rate limits, or required permissions, preventing a perfect score.
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 concise (3 sentences) and front-loaded with the core purpose. Every sentence adds value, including payment details, with no redundancy or filler. Excellent structure for quick comprehension.
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 moderately complex tool with no output schema, the description covers key outputs (VaR/CVaR, worst-case loss, interpretation) and essential behavior (auto-fetch). It misses details on parameter interactions (e.g., profile, rebalanceMethod), but overall provides sufficient context for basic usage.
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 high (83%), so the baseline is 3. The description adds context about auto-fetching for known tickers, which is already in the schema. It doesn't add significant new meaning beyond what the input schema provides, resulting in a neutral score.
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 the tool computes VaR and CVaR at specific confidence levels, auto-fetches data for crypto tickers, and returns key metrics including daily/annual values and interpretation. This distinguishes it from sibling tools like analyze_risk or analyze_stress which cover broader or different risk aspects.
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 provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or contextual suggestions, leaving the agent without decision support for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct analytical dimension (risk, correlation, diversification, factors, etc.), with no overlap in purpose. Clear descriptions ensure agents can differentiate them easily.
All tools follow a consistent 'analyze_<topic>' pattern, making it predictable for agents to infer functionality from names alone.
Nine tools cover a comprehensive range of portfolio analysis tasks without being excessive. Each tool addresses a clear need, and the count is well-scoped for the domain.
The tool set covers major analysis areas (risk, correlation, diversification, factors, rebalancing, regime, stress). Minor gaps like performance attribution or transaction cost analysis are absent but do not significantly hinder core workflows.
Portfolio and strategy stress diagnostics with hedge-break detection and regime outlook. Free tier.
Portfolio-aware finance tools: drift, risk, earnings, benchmarks, news, tax harvesting
Portfolio risk analytics — VaR, Monte Carlo, optimization, options Greeks, stress testing.
Portfolio X-Ray with ETF look-through, file analysis, and website analytics in plain English.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/dun999/finsight-mpp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
