I have two pieces of work open that both come down to reading things off the web and doing something useful with what comes back.
The first is my local wiki. I keep a structured copy of product documentation on disk, and most of what I write leans on it. When a page in that wiki falls behind the published version, everything I write off that page inherits the drift. Keeping the local copies current is what decides whether the content I put out is accurate.
The second is automation against Prism Central and Nutanix Cloud Manager. The shape I want is automated DR with hooks that add and remove nodes during a failover, so the cluster on the recovery side sizes itself to the workload rather than waiting on someone to click through it.
An MCP server called TinyFish showed up in my setup with three tools that map onto both jobs, so I pointed it at real work and watched what came back.
What the three tools do
search is free. Ranked web results with filters for recency, explicit date windows, a news mode, a research paper mode, and domain include or exclude lists.
fetch_content is free. It reads up to ten URLs per call in a real browser and returns clean markdown, JavaScript rendered.
run_web_automation spends credits. It clicks, fills forms, signs in, and navigates, and it can carry a saved browser profile with stored credentials. It takes a step budget and a duration limit, and it can return structured JSON against a schema you define.
Search and fetch stay free on every plan, not just during a trial. The credits meter the browser automation, which is the part doing the clicking and the signing in. Signing up puts 500 of them in the account with no credit card and no setup, which is enough runs to find out whether the automation half is worth building on before deciding anything.
The free layer, on the local wiki and content job
First real test was a technical question I already needed answered. search returned nine ranked results and all nine were relevant: official vendor documentation, an API reference, a cloud provider’s own docs. No SEO farms padding the list out to ten.
Then fetch_content pulled a full JavaScript-rendered cloud documentation page as clean markdown in 318 milliseconds.
That number is the whole case for the free tier. It renders JS, so single page app documentation comes back as readable text. It takes ten URLs in one call, so I read a cluster of sources in one round trip. And it costs a fraction of the tokens a generic fetch burns, because what comes back is markdown, not raw HTML with every nav element still attached.
Two things changed in how I work as a result.
The first is grounding. When I draft anything technical, I read the public sources directly instead of working from what I remember about them. Official vendor docs, API references, cloud provider documentation, public pricing and region pages, all of it reads cleanly and costs nothing. That small discipline change catches a surprising number of quiet errors.
The second is link checking before I publish. One fetch_content pass over every external URL in a draft catches dead links and, more usefully, claims that have drifted since I wrote them. I always knew I should do this. Ten URLs per call is what finally made it cheap enough to do every time.
I spent a run pointing the browser automation at a full product documentation page, mostly to see what a credited read looks like next to the PDF extraction I already had of the same content.
It came back better structured. Real markdown tables instead of flattened rows. Real hyperlink URLs instead of “see page 77” style cross references that go nowhere in a text file. And page metadata carrying a “Last Updated” date.
That date is the piece I care about for the wiki. A freshness check needs a signal that tells it which local copies have gone stale, and a PDF extraction does not surface that cleanly. Being able to read a published date off a live page turns wiki maintenance from a thing I do when I remember into a thing a job can decide for me.
Checking the API reference before I write the calls
The DR work is written against APIs. Adding nodes on the recovery side during a failover and taking them back out afterward is a sequence of calls, and getting the right call at the right version is the part that decides whether the rest of it works.
The Nutanix developer API reference is public and reads cleanly through fetch_content. One call returned the full reference, roughly 140,000 characters of it.
The payoff is version accuracy. The reference states that v4 is the recommended API and supersedes previous versions, and that v3 on Prism Central and v2.0 on Prism Element are both flagged for upcoming deprecation, with users told to migrate to v4 where possible. Version numbers are the quiet kind of detail. Nothing tells you one has moved on. Reading the reference before writing the calls is what puts the DR work on v4 from the first line.
Hope to try it with more workflows in the future.