I connected 5 MCP servers to Claude Code in one afternoon. Two made the cut.
I connected Filesystem, Git, Memory, Fetch, and Playwright MCP servers to Claude Code, checked what each added, and kept only two. Real tool counts.
Automate
August 6, 2026 · 7 min read
An agent chain read one messy file of ours and told me the build cluster deserved our next 10 articles, with 770,720 monthly searches behind it. The real figure for build was 3,750, and it finished last of five. Same file, same question, one afternoon, $0 spent.
Here is what no roundup of the best AI agent for data analysis will tell you: the chain does not fail loudly. It hands you a confident number and a confident recommendation, and both are wrong in the same direction. If you make weekly calls off exported spreadsheets, this is the part you need to see before you trust one.
I did not catch it by reading the answer. I caught it by asking the same question twice.
I gave it one decision we really make: which of our five content clusters deserves the next 10 articles. Every planning round starts the same way, with five SE Ranking keyword exports, one Google Search Console pull, and a call that has to come out of them. By hand that is an afternoon of squinting at columns. Build it once, win every week, which is why I wanted a chain and not a chat.
A chat answers the question you typed. A chain cleans, calculates, and then commits to an answer, and each step trusts the one before it.
457 rows, 17 columns, 110 blank volume cells, and 20 keywords sitting in there twice. I built it from our own raw exports and left every bit of the mess in place: five SE Ranking seed pulls, five shortlist files, five discovery files and the Search Console pull, stacked into one CSV with the column names they each came with.
Most of the trouble lives in the column names. Two of the source files call keyword difficulty difficulty and the shortlist files call the same thing kd, so the merged file has difficulty in 329 rows, kd in 18, and neither in 110. The Search Console rows came out of our own fetch script with Dutch column names (kliks, impressies, positie) and carry no search volume at all, so 13 rows look like keywords with zero demand. And history_trend is a JSON object stuffed into a single cell, which means there are commas inside quotes all through the file.
When we fed a messy spreadsheet to NotebookLM's Data Tables, the whole story happened at the door: the file would not go in. This time the file went in without a complaint. That is the difference worth knowing about a chain. Nothing stops it, so a wrong turn in step two arrives at your desk looking like a finished answer in step four.
Three scripts, each handing its output to the next: one to clean, one to subtract what we already cover, one to count.
The cleaning script folded kd into difficulty so the two names became one column. It set aside every row with no volume instead of reading a blank as zero. Then it deduplicated on the lowercased keyword and kept the highest volume when the same keyword showed up twice.
The subtracting script pulled 40 published keywords out of our archive and 75 more out of the live backlog, then dropped any row matching one of them. That removed 30 keywords from the pile, because writing article 11 about a keyword we already rank for is not a plan.
The counting script kept only what a young site can realistically win, using our own shortlist rule of difficulty 35 or lower and volume of 100 or more, then summed volume per cluster. The trail across all three: 457 rows in, 110 set aside as unknown, 327 unique, 297 still open, 78 actually winnable.
The one instruction that made the difference is small enough to steal.
Before you calculate anything, do a counting pass only. Report: total rows, total columns, how many blanks there are in each column I named, and how many values in my key column appear more than once. Do not fill, guess, or drop anything yet. Then tell me which of those blanks you plan to treat as zero and which as unknown, and wait for me to confirm.
The first pass said build, with 770,720 monthly searches behind it, and four separate errors were baked into that single figure. The 20 duplicate rows double-counted 18,560 monthly searches, and 12,830 of those landed in build alone. The 110 blank volume cells quietly became zero. Nothing was subtracted, so 40 keywords we have already published were still propping up the total. And nothing was filtered, so one head term, "ai video generator" at 246,000 searches and difficulty 94, was carrying a whole cluster we have no chance in this year.
The blank-as-zero one is the sneakiest, because whether you get a warning depends on which language the agent reached for:
$ awk 'BEGIN{x=""; print "\"\" + 5 =", x+5}'
"" + 5 = 5
$ python3 -c "int('')"
ValueError: invalid literal for int() with base 10: ''Same blank cell. One path stops and tells you. The other agrees with you and moves on.
Then there were the two side rankings I asked for, which is where the type handling really showed itself. Sorted by volume without converting the column to numbers, the highest volume in the file came back as 9900. The real maximum is 246,000. Sorted by difficulty the same way, my top 10 easiest keywords included four entries at difficulty 100, the hardest score the scale has, because as text 100 sorts before 13.
I ran the same question a second time with a discard log at every step, then put the two answers side by side. Build fell from 770,720 to 3,750, a factor of 205, and dropped from first place to last. The winner became tools, with 9,890 monthly searches spread over 24 open keywords, followed by automate with 6,270 over 17.
Look at what survived the filter and the plan changes shape completely. Three of the top eight winnable keywords sit in automate: "integromat" at 760 searches and difficulty 13, "zapier vs make" at 590 and difficulty 23, "n8n vs make" at 590 and difficulty 21. Small and reachable. That is a different quarter than "write 10 more build articles", and the naive answer would have cost us ten articles to find out.
None of this needed a framework. It is the same shape as the agent we built in one day from idea to working agent, with a comparison pass bolted on the end, and it fits in an afternoon if your exports are already sitting in a folder.
One of the three I looked at builds the cross-check in by name, and the other two either hide it behind a toggle or admit the risk in a caption. I did not run any of them: my chain was three Python scripts on this laptop, without pandas installed, and I do not open accounts to test things. What follows is what each one documents about itself, plus one independent test.
Powerdrill is the interesting one, because it calls its setup a multi-agent framework and gives the missing step an actual job title. A "Data Engineer Agent" cleans and transforms the upload, and a "Data Verifier Agent" cross-checks figures and calculations before showing them to you. That verifier is precisely what my chain did not have.
Julius AI is more careful about the word than its own marketing is. The tagline says "AI-powered Data Agents", while its FAQ describes an "AI assistant... [that] writes code to analyze your data based on your prompt". The multi-step version that, in Julius' words, "checks its own work as it goes" ships behind an opt-in Reasoning toggle, and setting the reasoning level is paid-plan only. Free gives you 25 credits a day, 2 GB of sandbox RAM, and only .csv, .xlsx and .sav uploads. Paid starts at $20 a month.
Google's Data Science Agent inside Colab is free and the most honest of the three, because Google's own caption on it reads "Data Science Agent may make mistakes". An independent hands-on test at Towards Data Science watched it genuinely self-correct while running: it hit a DTypePromotionError, dropped the offending column, hit a follow-up ValueError, and added a SimpleImputer on its own to get the step working. The same test also watched it fill missing values with the column mean without mentioning that this distorts skewed data, and found the autonomy only in the first pass, since every follow-up "stays in the chat, just like ChatGPT".
Yes, with one change: the discard log gets written before the analysis runs, not after the answer looks wrong. The agent was never bad at code. Every script ran on the first try, the merge was clean, the sums added up to exactly what I asked for. What it was bad at was doubt.
Trust me on this one, because it is the cheapest habit in the whole workflow: make the chain report what it threw away, in numbers, before it reports what it found. If a tool never tells you it is unsure, that is not extra capability. It is just a quieter version of the same guess.
The number I nearly shipped was 770,720. The number I acted on was 3,750. Both came out of the same file on the same day, and only one of them had a receipt.
I connected Filesystem, Git, Memory, Fetch, and Playwright MCP servers to Claude Code, checked what each added, and kept only two. Real tool counts.
Automating your work with AI starts with one boring task, not your whole job. How to pick it, choose a tool, and set it up in an afternoon.
I moved an MCP server and three clients to the 2026-07-28 spec. Three methods vanished, one tool call failed with HTTP 200, and 35 lines went in the bin.