APIs & MCP Servers from Tigzig

Serve structured datasets. Hit the query endpoints, or download the whole database in one file (CSV / TSV / Parquet / SQLite / DuckDB).

Send inputs (tickers, a portfolio) and get a computed report or dataset back. Each is open source and also runs as an MCP server over the same backend.

MCP tools and utility services over the same infrastructure.

The pages above are the reference - what each API is and how to call it. These are the long-form guides: worked examples, the mistakes real callers actually make, and what to do when something returns an error. Each is a plain page with a Markdown twin, so you can hand the URL straight to an agent.

• 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.
• Free AMFI mutual fund NAV API for India - what the data is, how to pull one scheme, and how to take the whole dataset in a single call.
• Search filters across 12 fields on a scheme - the full walkthrough of the browse filters on this page: how they combine, what a wrong call looks like, and the limits worth knowing before you rely on a result.

Published limits are per IP, so a well-behaved client can plan around them. Cross one and you get HTTP 429 with Retry-After and a JSON body naming the limit hit and what to do instead (typically: batch, or use the bulk download rather than paginating). Honor the header for clean back-off. These figures are current at build time - the numbers that cannot go stale are the X-RateLimit-* headers on your own successful responses and each API's discovery endpoint, both linked from the per-API page.

Legacy: an earlier Tremor V1 surface is still served at /tremor/v1/* (REST) and /tremor/v1/mcp/http (MCP). It is frozen - response shape stable, data still refreshed daily - and stays mounted for existing integrations (limits 10-30 req/min per IP). New work should use the unified /v1/* surface above.

Sample 429 response

HTTP/1.1 429 Too Many Requests
Retry-After: 60

{
  "detail": "Rate limit exceeded",
  "limit": "60 per 1 minute",
  "retry_after_seconds": 60,
  "suggestion": "For multi-indicator or long-history pulls use the bulk download endpoints instead of paginating: GET /v1/download/all (sqlite | duckdb) for the full dataset, or /v1/download/{table}?format= for one table. One request vs many.",
  "limits_doc": "https://api.tigzig.com/v1/"
}

Per-call caps (unified /v1 series + indicators endpoints)

• Max 10 indicators per /v1/series call - pass more by chunking, or hit /v1/download/{table} for the whole table in one file
• Max 10,000 rows per response - reduce the date range, or use a bulk download for full history
• TSV output carries a # meta: count=N unknown=[...] empty=[...] comment line so the agent can detect typo'd ids in the body

Heavy pulls: use bulk downloads, not pagination

If you need many indicators or long history, do not paginate /v1/series - use bulk downloads instead. One bulk request avoids rate limits entirely and serves you a single file you can query locally.

• GET /v1/download/all?format=sqlite (or duckdb) - every public table in one file
• GET /v1/download/{table_name}?format=parquet - one table (macro_indicators, stock_prices, or indicator_config)
• GET /v1/downloads/manifest - file sizes + last-refresh timestamp

Programmatic consumers: the live numbers are also available at GET https://api.tigzig.com/v1/ under the limits block (per_ip_per_minute, per_ip_downloads_per_minute, max_ids_per_series_call, max_rows_per_response). Read it once at startup; do not hard-code.