Security Performance Report API (SPR) - Portfolio Analytics

1 endpoint. Request bodies, every field and every enforced limit are in the full reference.

Connect the MCP server below to generate a report as a tool call.

SPR (Security Performance Report) is a multi-symbol portfolio reporting tool. Pass a set of Yahoo Finance symbols and a date range, and it returns a professional HTML report with matplotlib charts plus six CSV files (price data, returns, correlations, statistics). Two access shapes over one backend:

• REST - POST /v1/analyze with a JSON body: symbols, start_date, end_date, optional risk_free_rate.
• MCP - the same report as an agent tool call (see below).

Related: for a 6-security metric comparison see QREP - Compare Securities.

Connect an AI agent and let it generate a portfolio report directly. No auth. One endpoint:

• https://ffn.tigzig.com/mcp - Streamable HTTP, the recommended transport (MCP spec 2025-03-26).

Example prompt: "Generate an SPR report for AAPL, MSFT and GOOG from 2020-01-01 to 2024-12-31."

Add to Claude.ai: Settings -> Connectors -> Add custom connector -> paste the Streamable HTTP URL -> approve. The same URL works for Cursor, n8n, and any MCP client.

Dual calculation methodology. Core performance metrics (Total Return, CAGR, Sharpe, Sortino) use custom implementations based on QuantStats methodology; additional analytics (drawdowns, monthly returns, statistics) are powered by the open-source FFN library. Price data is from Yahoo Finance with preprocessing (zero/NaN removal, date alignment).

Validation. Total Return, CAGR, Sharpe and Sortino all match QuantStats. Sharpe and Sortino previously ran about 20% high because they were annualised by the square root of 365 while the input is daily closes on roughly 252 trading days a year; corrected on 4 August 2026. Reports generated before that date overstate both ratios. For multi-security analysis, date mismatches from differing exchange calendars are forward-filled up to five days (an industry-accepted practice with minimal impact). Full details: SPR vs QuantStats methodology comparison.

Informational only, not investment advice. Always validate outputs.

This page is the reference - what the endpoints are and how to call them. The guides below are the long-form versions, with worked examples and the edges you only meet in real use:

• Demystifying the API errors - what each error actually means and what to do about it, instead of guessing from a status code. Covers every TigZig API, not just this one.
• Your agents and scripts have been talking to me - what real callers actually do, read out of the server logs: the common mistakes, what works, and the patterns worth copying.

Each is a plain page with a Markdown twin, so you can hand a URL straight to an agent. Come back to this page when you want parameter-level detail.

Published so a well-behaved client can plan around them. These are per-IP limits:

• Per IP: 60 requests / minute.
• At most 4 concurrent requests per IP.

You get a 429 with Retry-After and a body telling you to batch to the cap and run batches sequentially.

Avoiding 429s: The concurrency cap bites before the rate limit does. Each analysis takes 10-30 seconds and report generation is serialised, so parallel calls queue rather than finish faster - send several symbols in ONE request and run batches sequentially.

Every successful response carries X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset (Unix epoch seconds), read straight from the running limiter, and Retry-After is set on 429. The current numbers are also published as machine-readable JSON at https://ffn.tigzig.com/v1/, derived from live config. Read those at runtime rather than hard-coding the figures above - limits change, and these channels change with them.

This API publishes no example in its spec, so there is nothing to copy here yet. The interactive console runs a real call against any endpoint, with the request filled in for you, without leaving the page.

There is an open-source edition of this analytics API - an earlier release you can run as your own service or borrow components from. Treat it as a reference implementation rather than a mirror of what is running here: the hosted service has moved on since.

github.com/amararun/shared-fastapi-mcp-ffn

Built on FastAPI, fastapi-mcp, FFN, yfinance.