I run an agency. For years, every new project began with the same hour of grunt work.
Find the logo. Not the favicon, the real one. Open dev tools, copy the hex codes, work out which of the four blues is the brand blue. Check what fonts the site loads. Copy the text of 80 pages into something editable. Decide what industry the client is in so we can file them correctly.
Each time, I wrote a script. Each time it worked on that site and broke on the next one. I ended up with a folder of scrapers, none of them good, none of them shared.
The decision
At some point the folder was embarrassing. So I wrote it once, properly, and put it behind an API.
AgentsRecon does six things: brand extraction, site-to-Markdown, crawling up to 5,000 pages, screenshots at several widths, NAICS and SIC classification and PDF text. Long jobs run async, with server-sent events or a webhook. There are TypeScript and Python SDKs.
Why agents
The second reason is the one that made it a product. AI agents are bad at the web by default. Hand one a URL and you get a wall of HTML, or a refusal. They need the same thing I did: a clean read of a site.
So the same calls are available as an MCP server, and they are designed for the way an agent uses tools.
What I will not do
I will not put fake testimonials on this site, or logos of companies that do not use it. This is a new product. The tool on the home page is the proof: paste a domain and see what comes back.
I will not hide the prices. They are on the pricing page, proposed for launch, and any change goes in the changelog.
I will also publish honest comparisons. Firecrawl, Brandfetch and Context.dev are good products, and sometimes the right answer is to use them. See how we line up on Firecrawl.
Try it
Run any domain through the tool. If the result is wrong, I want to hear about it: [email protected]. That is how this gets better.
What six calls looks like in practice
The product is intentionally small. Six calls is not a lot, and that is the point. Each one answers a question I used to answer with a throwaway script. What does this company look like? What does this page say? What is on the rest of this site? What does it look like on a phone? What industry is it in? What does that PDF say? If a question is not one of those, AgentsRecon is probably not the tool, and I would rather say so than stretch it.
I also kept the surface boring. One key works for every call. Long jobs are jobs, with progress you can follow and a webhook if you want one. The SDKs are thin. If you read the documentation once, you should be able to guess the rest. That sounds like a low bar, but most of the APIs I have used raise it by accident.
Pricing, and why it is in pages
I priced it in pages because that is the unit people understand. A page is a page whether you scrape it, crawl it or read it through an agent. Brand and styleguide calls cost more because they look at more than one asset, and I say so on the pricing page instead of burying it in a credits table. The prices are proposed launch prices. If they change, the change goes in the changelog before it takes effect.
I looked hard at the alternatives while setting the numbers. Firecrawl, Brandfetch and Context.dev each solve part of this problem and each has a pricing model that suits somebody. The comparison pages cite their public pricing with a date, and I will keep them current. If a competitor is the better fit for what you are doing, the comparison should help you see that.
What I do not know yet
This is a new product, and there are things I have not learned. I do not know yet which of the six calls people will use most. I suspect it is the Markdown scrape, because agents need it, but the brand call is what started the project. I do not know how the free tier will be used, or whether 100 pages a month is the right size. I will find out from real usage, and I will change things in public when I do.
What I do know is that the tool on the home page works the way I want it to feel: paste a domain, wait a few seconds, and get something you can use. Right now it returns clearly labelled sample data while the public endpoint is finished. The API behind the pricing page is real.
What comes next
The next things on my list are the MCP launch, the public documentation and the first batch of comparison and how-to posts. After that, whatever people ask for. If you have a use case that the six calls do not quite cover, write to me. A few good requests will shape the roadmap more than any plan I could draw today.