Fatsearch MCP tokens is a free search-and-read MCP server for AI agents that returns compressed page content instead of raw HTML, so a research task that would burn a large context window costs a fraction of the tokens. The project describes its own claim as reading the web at 99% fewer tokens, and it ships as a CLI plus an MCP server.
RAW FETCH (today)
agent --> fetch page --> 60k tokens of HTML, nav, ads
|
+-- most of it is thrown away
FATSEARCH (read step)
agent --> search query --> ranked results
--> read URL --> compressed page text
|
+-- small block, same facts
Same research answer. Smaller bill. Room left for the next step.What Is Fatsearch MCP and Why Does It Cut Tokens 99%
Fatsearch is a search-and-read layer for AI agents: the agent runs a query, gets ranked results, then reads a single URL and receives compact text rather than a full page dump.
The saving does not come from a magic summarizer. It comes from not shipping the parts of a page an agent never needed. A raw web fetch hands your model the entire document: script tags, cookie banners, nav menus, footer links, tracking parameters, repeated boilerplate, inline styles. On a content page, the sentence you actually wanted is often a small slice of that payload. Fatsearch returns the readable content, so the same fact arrives in fewer tokens.
Why that matters for social work: an agent doing trend spotting, competitor reply drafting or link sourcing makes many reads in one session. Each read that arrives compressed leaves context free for the next step. The 99% figure is the project’s own headline claim about the read step, not a promise about your whole workflow. Treat it as the direction of the saving, then measure on your own pages. The launch source is the fatsearch/fatsearch repository on GitHub.
Two things Fatsearch is not. It is not a browser, so it does not click through a logged-in dashboard for you. And it is not a model. It feeds whatever MCP-capable agent you already run: Claude, ChatGPT, Cursor, Codex, or your own harness.
How Fatsearch Search-and-Read Works Under the Hood
Think of it as two tools with one job split between them: search finds candidate pages, read turns one page into text your model can afford to keep.
Search takes a query and returns a short list of results, usually a title, a URL and a snippet. That list is cheap. The expensive part of research is always the read, because that is where a full document enters the context window. Fatsearch compresses at that step: it strips the page down to its main content, drops the chrome, and hands back a compact block.
A typical loop looks like this inside your agent session:
1. search("instagram reels reach drop 2026")
2. pick the two most relevant URLs from the results
3. read(url_1) -> compact page text
4. read(url_2) -> compact page text
5. write the answer, cite the URLs, stopCompare that with the naive version, where step 3 and step 4 each drag in a full page. Two raw fetches can fill a large share of a working context before your agent has written a single sentence. With compressed reads, the same two sources cost a sliver of that, and you can afford a third and fourth source.
How to Install the Free Fatsearch CLI and MCP Server
Fatsearch is free and installs in minutes: a CLI for terminal work and an MCP server for the AI app you already use.
Start with the repository, since that is the source of truth for the current install commands: github.com/fatsearch/fatsearch. Read the README before you copy anything, because install lines change faster than blog posts do.
Two paths, depending on where your agent lives:
| Setup | Use it when | What you do |
|---|---|---|
| CLI | You want to try search and read by hand, or script it in a shell step | Install the CLI from the repo, run a search, then read one URL and look at the output size |
| MCP server | Your agent should call search and read on its own during a task | Register the server in your MCP client config, restart the client, confirm the tools appear |
A first check that costs you nothing: run one search, read the top result, and count the tokens in the returned block. Do the same URL with a plain fetch. That gap is your actual saving on your actual sources, and it takes about two minutes to get. If you want the same habit for a hosted MCP server, the pattern is the one described in deploying MCP servers into an AI content stack.
Fatsearch vs Raw Web Fetching: A Token Cost Comparison
The comparison that matters is not Fatsearch against another tool. It is compressed reading against raw fetching, on the tasks your agent repeats every week.
Here is the arithmetic in plain terms, using made-up numbers to show the shape rather than a benchmark:
| Approach | What the context holds after one source | How many sources fit before you trim |
|---|---|---|
| Raw fetch | Whole page: markup, nav, ads, content | Few. Two or three reads and you are editing history |
| Fatsearch read | Main content only | Many more, with room left for the writing step |
The practical consequence: raw fetching forces your agent into short research bursts, then a context reset, then a re-brief. Compression lets one session carry a full research pass and the draft that follows. That is where the real cost sits, in the resets and the repeated briefing, not just in the per-token price. If you have ever watched an agent get vaguer as a task went on, you have seen context pressure, which is what context window optimization is about.
One honest caveat: compression can drop details. Tables, code blocks and captions sometimes survive in odd shapes. For research summaries that is usually fine. For pulling exact numbers out of a spec page, read the page in a browser too.
How to Let an AI Agent Research on Published Articles With Fatsearch
The strongest use case is researching your own published articles before you write the next one, because you already know the ground truth.
Suppose you have forty blog posts and want a post on comment-to-DM funnels. Give the agent a brief like this:
Using fatsearch, find my site's pages on comment funnels,
DMs and automations. Read each one. Then list:
- claims I already make (so I don't repeat them)
- claims I have never made
- the three internal links that best fit a new post
Cite each URL. Do not write the post yet.This is a two-stage workflow on purpose. Stage one is research and costs reads. Stage two is writing and costs little, because the findings are already compressed into a short list. The full method, including how to keep the agent honest about what is already published, is in how to let an AI agent research on published articles.
The same loop covers competitor reply research and link sourcing: search a topic, read three strong pages, note the angle nobody took, then draft. Each step stays cheap because the reads are compressed.
Using Fatsearch With Your AI Agent for Social Media Research
Research is the expensive half of social automation. Publishing is cheap and repeatable; finding the trend, the source and the wording is where context goes.
A workflow that stays lean:
- Fatsearch does the outside reading: trends, source articles, competitor announcements.
- Your publishing agent does the inside work: accounts, scheduling, replies, analytics.
- Only the findings cross between them, not the raw pages.
Creator OS covers step two. It has a hosted MCP server at https://mcp.creatoros.ca/mcp with nothing to install, and about 160 tools covering posts, analytics, comments, DMs, automations, blogs, Skool and the Ads add-on. An agent holding one workspace key can post to that workspace and no other, so a research agent and a publishing agent can be scoped separately. The install walkthroughs are on the KevBuildsApps YouTube channel, and the social-agent pattern is in working with the Skool API from an AI agent.
The split has a second benefit. A research agent that reads the open web is exposed to prompt injection in page text. Keep it read-only and outside your publishing credentials, and a hostile page cannot schedule a post. Creator OS read-only connections only see read tools, and the API refuses writes from them.
What to Watch For: Accuracy, Rate Limits, and Fallbacks
Treat Fatsearch as a fast first pass, not a citation machine. Check every claim that goes into a client’s post against the source page yourself.
- Accuracy. Compressed text is a lossy representation. Numbers, dates and quotes deserve a second look, especially when the post makes a factual claim.
- Rate limits. Public search services throttle. Read the repo for current limits rather than trusting a blog number.
- Paywalls and JavaScript apps. Some pages render their content in the browser only. Those reads come back thin, so fall back to a manual read or skip the source.
- Fallback rule. Tell your agent what to do when a read is empty: try the next result, never invent the missing detail. This one sentence prevents most hallucinated citations.
Build the habit of measuring. Once a week, run the same three-source research prompt and check the token count in your agent’s usage view. That turns a headline claim into a number you can defend to a client.
FAQ
fatsearch MCP tokens how does it save 99%
It compresses at the read step. Instead of handing your model raw HTML with navigation, ads and scripts, it returns the main page content, so the same fact arrives in far fewer tokens. The 99% figure is the project’s own claim about that read step, and your saving depends on how heavy the pages you read are.
how to let ai agent research on published articles
Give the agent two instructions: search your site for the relevant published pieces, read each one, then report what you already claim and what you have never covered, citing URLs. Keep writing as a separate step so the expensive reads happen once. The full workflow is in this guide.
what is the best free MCP for ai agent web search
Judge candidates on three things: what the read output looks like, whether the tools are small enough to keep your context clean, and whether the project is maintained. Fatsearch is free, ships a CLI and an MCP server, and is built specifically for the search-then-read loop. Test it on your own five sources before you commit.
ai agent for social media how do i keep token costs low
Compress reads, split research from publishing, and avoid context resets. Use a compression layer like Fatsearch for external research, and give the publishing side a scoped connector such as the Creator OS MCP server so it does not carry web pages it does not need. The token compression piece covers the same lever from a different angle.
can fatsearch mcp work with linkedin mcp and skool ai agent workflows
Yes, because MCP servers are independent. Your client can hold Fatsearch for web research, a publishing connector, and a Skool connector at the same time. Creator OS connects Skool communities read or read & write, and Skool tools like skool_create_post and skool_multi_post can publish to several communities at once.
Get Started With Creator OS
Pair a free research MCP with a publishing layer and your agent stops wasting context on page chrome. Creator OS plans start at $14.99/month for 11 platforms plus Skool, with the API, the MCP server and the CLI included.
Create your account, connect the socials you want an agent to run, then add the hosted MCP server and the Fatsearch tools beside it. If you build your own harness, the open-source Social Agents launch video shows the pattern end to end.
Get started for $0
Free trial for new subscribers. Cancel anytime.