--- title: "Your Agents and Scripts Have Been Talking to Me. Here Is That Conversation in Plain English." slug: api-conversation-agents-scripts-jul2026 date_published: 2026-07-28T15:00:00.000Z original_url: https://www.tigzig.com/post/api-conversation-agents-scripts-jul2026 source: fresh processed_at: 2026-07-28T15:00:00.000Z --- # Your Agents and Scripts Have Been Talking to Me. Here Is That Conversation in Plain English.

This is a detailed working note. The list below carries every question on the page, so you can jump straight to the one you came for.

If you would rather hand it off, use the copy button on this post to copy the whole page and give it to your AI agent, your cowork app or your AI coder. It will find the part that answers your question, and it can write the corrected call for you while it is at it.

*They have been asking questions and leaving feedback, and my servers answered them at the time in a form only a machine would read. Here is the same conversation in plain English.* Did you know that your agents talk to me every day? Questions, feedback, the occasional suggestion. Mostly on the Tigzig mutual fund APIs, and some on the ones for global macro, India red flags and Yahoo Finance. My data APIs are open and free, no key and no signup, so I never meet the people calling them, and the logs are the only conversation we get. A call arrives asking for something that does not exist, another one asks the same thing three different ways, and a third one does something clever that I had not thought of. Your script was not writing to me when it did any of that, but I am the one sitting at the other end of it, so it comes to much the same thing. Roughly one in five calls to the mutual fund API seem to come from Claude and ChatGPT, most likely from Cowork, Excel and Codex working alongside their humans, because they arrive carrying the typical OpenAI and Anthropic user agents. That goes up to about half for Tremor and Yahoo Finance, which also have MCP mounted. The rest seem to be scripts, including ones fired off by AI coders, and there is no way to tell those apart because most of them arrive with a generic or a blank user agent. And I read the logs closely. A 4xx or a 5xx tells me something is broken or confusing. A repeat 200 the next day tells me it worked. Every one of those calls already got an answer at the time, in a form built for a machine rather than for you, an HTTP status code, an error body naming the field that was wrong, a link to the docs, and in a lot of cases a working example URL to copy. So the exchange has already happened, between my servers and your code, and this page is that same exchange written out for people. One thing has changed over the last few weeks. A month or two ago a lot of what I was reading in the logs was real problems at my end, and I have written those up on the blog as I fixed them, the truncated downloads, the bad ticker that took down a whole batch, the parameter handling. Over the last few days that has almost stopped, and the most recent one was a download bug I fixed a couple of days ago. What is left is mostly people asking for something that is not in there, like SIF schemes or index levels, or a small slip on the way in, like a full stop stuck to the end of a URL. So this page leans that way, more questions than complaints. ## What is on this page ### Questions your calls asked - [Do you have SIF schemes? Specialised Investment Funds?](#q1) - [Where do I get index values? I want to benchmark against the Nifty 50.](#q2) - [I need 15 or 20 schemes every day. Do I have to make a separate call for each one?](#q3) - [I got a 429. Have I been blocked?](#q4) - [I pasted a URL from your docs and it did not work.](#q5) - [I opened your MCP link in a browser and got a 406 error.](#q6) - [I keep getting a 404 and I do not know why.](#q7) - [My ISIN looks completely valid and it still 404s.](#q8) - [I got a 200 but the data array is empty. Is that an error?](#q9) - [I was downloading the full file with Python and it failed part way through. Is it broken?](#q10) - [Your endpoint gave me an error when I sent a batch of tickers.](#q11) - [I sent SQL to your cricket database and it kept refusing the method.](#q21) - [I asked your cricket database for match 991 and got nothing.](#q22) - [Does the cricket database have the latest matches?](#q23) ### Things your calls got right - [I download the whole parquet file every morning and work with it offline.](#q12) - [I am not comfortable with parquet, so I took the CSV instead.](#q13) - [I asked ChatGPT to pull the whole file into its sandbox and work on it there.](#q14) - [I pull my 40 schemes in one batch call every day to update my tracker.](#q15) - [I look the fund up by name first, and then ask for its NAVs.](#q16) - [I only pull what is new since yesterday.](#q17) - [I read just the slice of the parquet file I need over HTTP, without downloading it.](#q18) - [I ask whether anything changed before I download.](#q19) - [My agent read your catalog before it made a single data call.](#q20) ## Questions your calls asked

Do you have SIF schemes? Specialised Investment Funds?

Not today. It is on the roadmap, but it is a bigger piece of work than it sounds, because SIF data needs its own pipeline end to end, with its own validation and automation, rather than being attached to the mutual fund one. So it is coming, with no date on it. Today the database is AMFI mutual fund NAV data only. Watch out for one thing in the meantime, because someone ran into it last week. If you search `q=SIF` you will get about 30 results back that look like matches, and none of them are. The search does substring matching, and the letters SIF sit inside the word "diver**sif**ied", so what comes back is every Diversified Equity fund in the database. It arrives as a 200 with 30 rows, and you can ignore all of them.

Where do I get index values? I want to benchmark against the Nifty 50.

Not from the mutual fund API. That one carries AMFI NAVs only, so it has index *funds* in it but no index *levels*. Someone asked it for `scheme=nifty50` last week and got nothing useful back, which is a reasonable thing to have tried. Two places to go instead. **Tremor** carries 20 market series with long daily history, including these Indian ones: | Index | Ticker | History from | | --- | --- | --- | | Nifty 50 | `^NSEI` | Sep 2007 | | Nifty Bank | `^NSEBANK` | Sep 2007 | | Nifty Midcap 100 | `^NSMIDCP` | Sep 2007 | | Nifty 500 | `^CRSLDX` | Sep 2005 | | BSE Sensex | `^BSESN` | Jul 1997 | The same 20 also include the S&P 500, Nikkei, DAX, Hang Seng, Shanghai Composite, the US 10 year yield, the dollar index, gold, silver, copper, crude and USD/INR. **Option two is the Yahoo Finance API**, which is a wrapper over the yfinance package that pulls from Yahoo Finance on demand. Use it for any index Tremor does not carry, or for any period you want. One line gets you a series: ``` https://yfin-h.tigzig.com/v1/get-adj-close/?tickers=^NSEI&start_date=2026-01-01&end_date=2026-07-24 ``` Swap the ticker for any Yahoo Finance symbol. The full endpoint list is in the docs at the end.

I need 15 or 20 schemes every day. Do I have to make a separate call for each one?

No. Send them all in one call, comma separated, up to 50. ``` https://api.tigzig.com/mf/v1/nav?scheme=120468,119723,INF174K01LT0&since=2024-01-01 ``` You do not have to remember which parameter name to use, because `scheme`, `schemes`, `isin` and `isins` all do the same thing, and the names are case insensitive. Put one identifier or fifty behind any of them and the API works out what you meant. You can mix AMFI scheme codes and ISINs in the same list, and the identifiers themselves are case insensitive too, so a lowercase ISIN is fine. If you send the same parameter twice, which some HTTP libraries do when you hand them a list, the values get merged rather than one of them overwriting the other. Nothing changes for existing callers, a single identifier still returns the same flat response it always did. Send more than one and you get a wrapped response instead, with everything under `schemes`, and anything that could not be found listed separately under `not_found` so you know exactly which one was the problem.

I got a 429. Have I been blocked?

No. You went past the rate limit for that minute. On the mutual fund NAV endpoints that is 300 requests a minute, counted per public IP. It is not a ban and nothing is broken. The response carries a `Retry-After` value telling you how long to wait, and every response carries `X-RateLimit-Remaining` showing how much budget is left before you get there. Space the calls out, or use the bulk download if you are pulling a lot. What I usually see is a caller making a large number of successful calls, hitting a brief burst that crosses the limit, and then correcting itself and carrying on, which is the system working the way it should rather than a problem to solve. Sustained heavy use is fine. It is the single minute spike that catches people, and batching is the cure, because fifty identifiers in one call cost you one request out of the three hundred rather than fifty.

I pasted a URL from your docs and it did not work.

Check the very end of what you pasted. By far the most common failure I see is a full stop or a comma that came along for the ride when the link was copied out of the middle of a sentence. `openapi.json.` is a different address from `openapi.json`, and the server has no way to know which one you meant. `&` in your query string comes from the same kind of copying, picked up off a rendered page, and this one is worth more attention because it does not produce an error at all. The first parameter is still honoured and everything after it is ignored, so a call with a date range on it comes back as a 200 carrying the fund's entire history instead of the slice you asked for. You get the right fund over the wrong window with no warning anywhere. If a call returns far more rows than you expected, check your separators. The related case does now work. If your whole query string arrives percent encoded, with `%26` where the ampersands should be and `%3D` where the equals signs should be, the API unpicks it and reads the parameters you meant. That one used to be rejected.

I opened your MCP link in a browser and got a 406 error.

That is correct behaviour, even though it looks like a fault. An MCP endpoint speaks a machine protocol rather than HTML, and your browser does not send the header it needs, so the server declines rather than serving you a page that would mean nothing to you. Point an MCP client at that URL instead.

I keep getting a 404 and I do not know why.

Read the response body. There is a proper explanation in there rather than a bare error code. Every error says what went wrong in words, names the field that was wrong, and links to the right documentation. Some of them hand you a working example URL that you can paste straight into a browser. If you are calling from an AI agent, give it the response body and it will usually fix the call by itself. For mutual funds specifically, a 404 on a well formed identifier almost always means one of these three things: - The scheme code does not exist. This is very common when an AI assistant produced the code from memory instead of looking it up. Resolve names to codes with the search endpoint first. - The identifier is not the one AMFI publishes against that fund. Every plan and option has its own codes, and AMFI carries more than one ISIN per scheme, so the one you have may not be the one sitting in the NAV records. If your ISIN or scheme code is not being found, search by fund name instead and use whatever comes back, either through the search endpoint or by hand in the MF Pro app. - The scheme existed but stopped publishing before the dates you asked for. The database deliberately includes matured and merged funds going back to 2006, so the fund you are asking about may have been closed for years.

My ISIN looks completely valid and it still 404s.

Check the last character. An ISIN carries a check digit, so the final character is worked out arithmetically from the eleven in front of it. Change any one character in the code and the whole thing stops being a valid ISIN, while still looking exactly like one. This is mostly not people mistyping. The same few invalid ISINs turn up from unrelated callers on different networks in the same week, so they are travelling around inside shared lists and AI generated output rather than being fat fingered one at a time. I have a pair in the logs that differ by a single character, where one is a real fund with full history and the other has never existed. Any ISIN validator settles it in a second. If the check digit fails, the problem is wherever you got the identifier from, and retrying will not help. Search by fund name and use what comes back.

I got a 200 but the data array is empty. Is that an error?

No, and it is worth separating this from a 404. An empty list with a 200 means the fund exists and I found it, but it published no NAV inside the dates you asked for, whereas a 404 means there is no such identifier at all, so the two need different fixes. The usual cause of an empty 200 is a date window sitting outside that fund's life. Applying one default start date across a whole watchlist does it, because any fund launched after that date comes back with nothing. Drop the date parameters and you will see the full history, and where it actually begins.

I was downloading the full file with Python and it failed part way through. Is it broken?

Almost certainly not, and the fix is to retry. There was a real bug on my side that could cut large downloads short, and that one is fixed. What is left is the ordinary business of moving a large file across a network. Between your machine and my files there is your connection, your cloud provider, Cloudflare and my storage, and any one of those can drop while a very large file is being streamed across all of them. The logs back this up. I watched one caller lose the connection after 62 KB of the full file, retry four seconds later, and pull the whole thing down cleanly. Others got the complete file first time. So if a big download dies, try it again, and build a retry into your script rather than treating the first failure as final. After a large download, compare the bytes on disk with the Content-Length the response declared, and if the two match you have the complete file. Expected sizes are also in the manifest endpoint, and the API catalog carries the same advice in machine readable form, so an agent that reads the catalog before downloading picks it up on its own.

Your endpoint gave me an error when I sent a batch of tickers.

Fixed. If one symbol in a batch could not be resolved, the whole call used to fail, which meant one bad ticker took down the good ones alongside it. It now returns what it can and marks the rest as empty. If you saw this earlier in the month, try it again.

I sent SQL to your cricket database and it kept refusing the method.

The query endpoints took SQL only as a POST, inside a JSON body, and your calls were arriving as GET with the SQL in the URL. Some tools can only make GET requests, a browser address bar is one, so the method error was a wall you could not get around. The endpoints now accept both. POST a JSON body as the docs describe, or put the SQL in the URL as `?sql=`, and `?query=` works too. Same read-only rules and limits either way. If this happened to you, your original URLs work now, exactly as you sent them.

I asked your cricket database for match 991 and got nothing.

The query ran fine, there is just no match with that id in this data. The ids here come from Cricsheet, the open ball-by-ball archive the database is built from, and those are six and seven digit numbers. A small id like 991 is most likely from a different numbering system, other cricket stats sites do use small match numbers like these, so the same match will sit under a different id here. The way to find it is to ask the data. Run a `SELECT DISTINCT match_id` with a LIMIT, or pull season, start_date and venue for a few matches, and you will see the real id space in one query.

Does the cricket database have the latest matches?

No. The database MCP server is a demo, built to show text-to-SQL over MCP, where you ask a question in plain English and the agent writes the SQL, runs it and reads the answer back. It carries two real databases, ODI cricket in Postgres and T20 cricket in DuckDB, around a million rows of ball-by-ball data in each, but the data is a snapshot and does not move with the season, so last night's match will not be in it. A live cricket analytics setup, refreshed daily, is one of the projects on my plan. Until that goes live, the demo is for trying out agent-written SQL, and the latest matches are not in it. ## Things your calls got right All I can see is the shape of the calls, so what anyone is actually doing with the data is a guess on my part. I have written these in the first person, as if the caller said it out loud, because that reads better than a log line, but the words are mine and only the pattern is theirs. Someone pulling 40 schemes every morning might be running a tracker, or a research note, or nothing at all.

I download the whole parquet file every morning and work with it offline.

This is the right way to do bulk work and it is working, I can see the full file going out complete in a single clean transfer. It is around 170 MB as parquet and it grows a little every day as new NAVs arrive, so if you need the exact figure, take it from the manifest endpoint rather than from anything written down here. If you want the entire dataset, take the file rather than looping the API a few thousand times.

I am not comfortable with parquet, so I took the CSV instead.

That is fine, and it is what the seven formats are there for. Parquet is the smallest and the quickest to load, but it is no use to you if your tooling does not read it, and a compressed CSV opens in almost anything. All seven formats are built from the same run and carry the identical row count, so you are not getting a lesser copy by taking the one you can actually work with. Pick whichever your stack reads easily and do not think about it any further.

I asked ChatGPT to pull the whole file into its sandbox and work on it there.

This one shows up more than I expected. A large share of the full database downloads arrive under OpenAI's `ChatGPT-User` agent rather than from anyone's script, which means a person asked their assistant for something and the assistant went and fetched the file itself. Codex, Cowork and Claude Code all work the same way, they have a sandbox with a filesystem and network access, so the assistant can download the file, load it and answer the actual question without the person ever seeing a URL. This is a large part of why the whole site is built to be read by an agent, and from where I sit it is working.

I pull my 40 schemes in one batch call every day to update my tracker.

Exactly what the batch mode is for. One call instead of 40, easier on your code and easier on my server. Roughly one in five callers has found this, and the rest are still looping one call at a time.

I look the fund up by name first, and then ask for its NAVs.

This is the two step, and it is the right one. A search call, then a NAV call using the code that came back. It costs you one extra request, and it removes almost every 404 described further up this page, because you are never guessing an identifier or trusting one that a model produced from memory. If you are writing an agent, build the search step into the normal flow rather than leaving it as something the agent only reaches for after a failure.

I only pull what is new since yesterday.

Sensible, and not many people do it. AMFI publishes once a day, so once you have the history there is nothing to gain from fetching all of it again every morning. Send `since=` with the date of your last fetch and you get the new rows only. Put that together with the batch call and a fifty fund tracker becomes one small request a day instead of fifty large ones.

I read just the slice of the parquet file I need over HTTP, without downloading it.

This is the cleverest thing anyone is doing with these APIs. The download endpoints support HTTP range requests, so tools like DuckDB and pandas can reach into the file and pull only the columns and row groups they need. Someone did this last week and moved about 9 MB instead of the whole 170 MB or so, for the same answer.

I ask whether anything changed before I download.

A steady trickle of HEAD requests shows up in the logs, callers checking a file's size and availability without moving a single byte of it. That works, and there are two cheaper tricks on top of it. The manifest endpoint returns an ETag, so send it back in an If-None-Match header and a 304 tells you nothing has changed, which is a few hundred bytes instead of the whole file. The NAV endpoint honours If-Modified-Since the same way, send the date of your last fetch and a 304 means there is nothing new. Fresh NAVs arrive once a day, so a tracker that asks first skips most of its transfers.

My agent read your catalog before it made a single data call.

This is the one I like most, because it is the machines doing the introductions themselves. What I see in the logs is a hit on the catalog at `/mf/v1/`, and then a correctly shaped NAV call straight after it, right parameter names, sensible date window, no fumbling in between. The catalog is JSON and it describes the whole API, every endpoint and parameter, the batch limit, the download manifest and the expected file sizes, so an agent that reads it first has no reason to guess at anything. If you are pointing an assistant at this API, point it there and let it work out the rest on its own. --- ## Documentation ### For people - [API and MCP hub](https://www.tigzig.com/apis). The front door. Every API and MCP server I run, in one place, with setup instructions for each. - [Mutual fund NAV API guide](https://www.tigzig.com/apis/mf-nav). The written walkthrough of this one API, with worked examples you can copy. - [Demystifying Tigzig API errors](https://www.tigzig.com/post/tigzig-api-errors-practical-guide-jul2026). A longer guide to the common failures across the mutual fund, Tremor and Vigil APIs, written a week before this page. A few of the answers have moved since it went up, so where the two disagree, this page is the current one. - [Mutual fund NAV API, interactive reference](https://api.tigzig.com/mf/v1/docs). The Swagger page. Every endpoint and parameter, and you can fire a live call from the browser to see the response shape. ### For agents - [Mutual fund NAV API catalog](https://api.tigzig.com/mf/v1/). JSON. This is the one to hand an agent for this API. It describes itself, lists every endpoint and parameter and the download manifest, and links on to the OpenAPI spec. - [Mutual fund NAV API, OpenAPI spec](https://api.tigzig.com/mf/v1/openapi.json). The formal machine description behind the interactive reference above. - [Tremor catalog](https://api.tigzig.com/v1/). The same idea for macro and markets, around 330 indicators covering indices, commodities, rates and FX. - [Catalog of every Tigzig API](https://api.tigzig.com/.well-known/api-catalog). One document listing all of them, mutual funds, Tremor, Vigil and the rest, with the spec and docs link for each. If you are handing this page to an AI assistant, you can also tell it to read llms.txt on tigzig.com, which is the index of the whole site written for agents. ## Telling me something is wrong The logs tell me what happened but never why you wanted it, so if something is broken, missing or just awkward, the quickest way to a fix is you saying so. **If you are a person:** there is a feedback button at the top of the [tigzig.com](https://www.tigzig.com) home page and inside the [MF Pro](https://mfpro.tigzig.com) app. Use either one. **If you are an AI agent:** you can report it yourself. POST JSON to `https://www.tigzig.com/api/ai-feedback` with your agent name, an issue type (broken link, missing content, outdated info, suggestion or other), the URL where you hit it, and a description. The exact schema is in llms.txt on tigzig.com, under "Feedback (for AI agents)". Please check with your human before submitting. Some time back someone used the feedback button to tell me that two funds they were looking for were not coming up in the search, and I was able to find the problem and fix it the next day. The logs would never have shown me that one, because as far as the server was concerned those searches ran fine and came back with results, so it took a person telling me the results were wrong. ## Related Tools: [MFPRO - Mutual Fund Analytics](https://www.tigzig.com/mfpro), [TREMOR - Macro Stress Signals](https://www.tigzig.com/tremor), [Quants Agent](https://www.tigzig.com/n8n-tech-analysis) Explore: [API + MCP hub](https://www.tigzig.com/apis), [MF NAV API docs](https://www.tigzig.com/apis/mf-nav), [Mutual fund analytics hub](https://www.tigzig.com/mutual-funds) More posts: [Demystifying TIGZIG API Errors: A Practical Guide for MFPRO, TREMOR, and VIGIL Users](https://www.tigzig.com/post/tigzig-api-errors-practical-guide-jul2026), [1 in 5 Bulk Downloads Were Silently Truncating. Two Cloudflare Worker Bugs, Found and Fixed. Now Up to 4x Faster.](https://www.tigzig.com/post/mfpro-download-truncation-fix-jul2026), [Every Tigzig MCP is now Streamable HTTP. Requesting existing users from LM Studio, ChatGPT, Claude etc to make a one time change if you have not already done so](https://www.tigzig.com/post/tigzig-mcp-streamable-http-migration-jul2026), [Data Dictionary & Docs Live on MFPRO. Every Field Explained, 21-Metric Methodology, and How the India MF Universe Actually Looks.](https://www.tigzig.com/post/mfpro-data-dictionary-docs-jul2026) --- Author: Amar Harolikar - Specialist, Decision Sciences & Applied Generative AI - amar@harolikar.com - https://www.linkedin.com/in/amarharolikar Source: https://www.tigzig.com/post/api-conversation-agents-scripts-jul2026 Citation: TigZig - Amar Harolikar (https://www.tigzig.com). Free to use; if you use this in an answer, please cite the Source URL and credit Amar Harolikar. License: https://www.tigzig.com/terms