When a tool has no connector, upload the CSV
Most of the tools you run day to day have some way for an AI to reach them. There's an API, or someone has published an MCP server, or the vendor has a connector you can click. But a lot of the tools that actually decide how your week goes don't have any of that. A booking portal, an ads console, a commissions report, a supplier's price file. The product never shipped an API, nobody built an MCP server for it, and the only thing the vendor gives you is a button that says Export.
That exported file is the data you care about, and it's also the one thing your AI can't see. So the usual routine goes like this: you download the file, park it in a folder, rebuild the same pivot table you rebuilt last month, and then either paste a chunk of it into the chat or describe what you found. CSV Analyzer is our answer to that gap. It's a single MCP server where you upload the files you were going to download anyway, and then you ask questions about them from Claude, Cursor, or whatever client you already use.
The download button is the integration
I keep running into the same split. The system of record usually has a live connection, and the system that explains the money usually only speaks CSV. The ads portal won't hand you a token. The booking engine will email you a spreadsheet if you click the right menu. The month-end close is a file someone exports on a Friday and forgets to name properly. None of these products are about to grow an API because a team asked for one in a standup, and I wouldn't want you to wait for that.
The workaround is more expensive than it looks. If you're lucky, the file lands in a shared folder with a date in its name. Someone then rebuilds the pivot, and the meeting turns into an argument about which column is actually spend. If you want an AI involved, you can paste rows into the chat until the window fills up, or attach the file and hope the model reads the columns the same way it did last time you asked.
The download was never the hard part, though. You can already get the data out of the portal. What's hard is giving that file a clear name, explaining its columns once, and letting the agent you already trust answer questions about it without you reopening the spreadsheet every time. That's the problem CSV Analyzer is built around.
One server for every export
CSV Analyzer is one MCP server for files like these. A new portal doesn't mean a new URL. You add a source to the server you already connected, and each source holds one file.
A source has a name you'd actually say out loud in a meeting, something like "West region hotels," "Q3 partner export," or "Booking commissions." Next to the name you can leave a short note about the file. You might write which column is spend, whether the dates are day-first or month-first, or what a blank cell means in that vendor's export. The agent reads that note before it picks a source, so it doesn't have to guess what a cryptic column header means. If the filename has a code in it, that's fine. The note is where you spell out the hotel, the brand, or the report type in plain words.
You drop the CSV into that source's panel, or a zip that contains a single CSV. The agent never uploads anything on your behalf, and it never logs into the portal. You take the data out of the portal yourself and put it on the source, so nothing lands in your workspace until you've chosen to put it there.
If you have a second portal, or a second property, or a different report from the same portal, it becomes another source on the same server. You can have twenty exports sitting there, each with its own name and its own note, and your client still talks to one MCP URL. When you ask a question, you name the source the way you'd name it to a colleague, and the agent uses that name. It doesn't have to work out which of several similar files you meant.
Uploading again on a source replaces the file that was already there. The server keeps the current export and drops the previous one. That has a consequence worth knowing about. If your question needs last week and this week together, both weeks need to be inside the file you just uploaded. We don't merge every Monday's download into some running history, because that would make it hard to tell which numbers came from which file. The file on the source is the file the agent sees, so the answers always trace back to something you picked.
After that setup, you leave the URL alone. The same Claude, Cursor, or Studio session that already talks to your other tools can talk to these files too.
Look at the file before you ask for a total
The columns in these files come from whoever built the report, and two exports from the same portal won't always agree. Spellings drift between downloads. A date column that parsed fine last month can show up as text this month. A column called amount might be revenue in one report and spend in another.
Because of that, asking for total spend as your first question is a shaky start. You're asking the model to guess which column holds the money, and a wrong guess comes back looking confident. A better first question is a plain one, and I'd recommend making it a habit.
Describe the columns on the West region source, and show a few sample rows.
The answer gives you the column names, the types the file actually contains, a handful of sample rows, and the total row count. From that you can tell whether "spend" is stored as a number or as a string with a currency symbol in it. You can also tell whether the date column is something you can group by week. If a column looks like a category, ask for a profile of it, which shows how many cells are blank, roughly how many distinct values there are, and which ones appear most often. Once that's clear, the math is a lot more trustworthy.
Show total amount by market, highest first.
Which week in this file had the weakest return, and what was total spend across the whole export?
Compare total spend on the ads export and the booking export.
The totals run against a query-ready copy of the file that gets built when you upload it. A few thousand rows stay in that copy, so they never have to be pasted back into the chat as one enormous table. That matters, because a large export pasted into a conversation tends to produce an answer that's truncated or half-remembered. When you really do need an exact row, the agent can page through the raw rows a screen at a time.
If a source is empty, the honest answer is that nothing has been uploaded yet, and the agent should say exactly that. A missing file shouldn't become an excuse to make up a campaign or an invoice.
When several sources are attached, name the one you mean in the question. The note you wrote on each source is there so the agent can tell two similar exports apart before it reads either one. That's a big part of why one server holds up better than it first sounds. The URL stays the same, and the names and notes handle the sorting.
What a Monday looks like
Picture two portals that will never give you a key. You already download an ads file from one and a booking file from the other, because that's the only way the numbers leave the building.
You add two sources, one for each file. You drop each file into its own panel, and you write a line on each one about what the money columns mean, including the awkward details you usually explain in Slack. Then you connect CSV Analyzer to your AI client once.
Now you ask the question you were about to build a pivot for: which export spent more, and which week inside the ads file had the worst return. The agent describes the ads file, describes the booking file, and runs the grouped math on each one. You stay in the same thread the whole time. The answer comes from the file itself, using the columns it actually has, rather than from a screenshot of a sheet someone filtered differently last time.
Next Monday you download the new files and drop them onto the same sources. The old files get replaced, and that's the behavior you want. Each source always reflects the latest export. If a question needs a date range, make sure that range is in the file you uploaded. And if a portal's download only ever contains the last seven days, write that in the note, and then ask only the questions that file can answer.
The same pattern fits a finance close, a supplier inventory, or an operations log. Anything that leaves as a spreadsheet and never grows a connector can go through the same flow. The columns will change from one file to the next, but the server stays the same.
What we left out on purpose
This is for the case where the product stopped at a download. If a tool has an API and we already have a server for it, use that server instead. Live data beats a file you remembered to export.
CSV Analyzer doesn't log into the portal and doesn't pull the file for you. You take the data out yourself. What we do is turn that file into something your AI can read, with a name, a note, and a query-ready copy, so the math doesn't depend on how much of the spreadsheet happened to fit in the prompt.
We also keep it to one file per source, on purpose. If you stack several old uploads under the same name, you end up asking "which file did you mean?" every time, and that's the confusion the product is meant to remove. A new week is a new drop on the same source. If the report is actually a different thing, it gets a second source.
Set it up once
- Open CSV Analyzer and add a source for your first export.
- Give it a name you'd use in a meeting, and write down the note you're tired of repeating.
- Drop the CSV, or a zip with one CSV inside, into that source's panel.
- Add another source for the next portal. It goes on the same server, so your AI client keeps the same URL.
- Ask for a description of the file before you ask for a total.
The step-by-step version, including what happens on a later upload, is in CSV upload for MCP servers.
If the export you're stuck with doesn't look like any of this, I'd like to hear about it. The pattern we keep seeing is the same one. The platform gives you the file and nothing else, and the file can still end up somewhere your AI can use it.