Three steps, and a boundary
Fetch, extract, render. Then the part that matters when the URL comes from a stranger.
Deciding which subtree is the article is the hard problem, and it is the one this solves. You get the content and what the page says about itself, without the chrome around it.
Most pages are a fetch and a parse. Headless Chromium is a separate service it escalates to for the ones that genuinely need rendering, so you do not pay browser cost for a documentation page.
Headings stay headings and links keep their targets, resolved against the page they came from. Title, description and canonical URL come back alongside — including the URL after redirects, which is the one worth citing.
The caller supplies the URL, which makes any crawler a request-forgery primitive. Loopback, link-local and multicast are refused — including the cloud metadata endpoint on 169.254.169.254 that hands out credentials.
Blocking the first address is not enough, because a public URL can redirect to a private one. The guard sits on the dialer, so a 302 toward metadata is refused at the hop that matters.
It answers on MCP as well as over HTTP, so a model can read a page mid-conversation without you building the plumbing for it.
How it works
Fetch, extract, render
Each step is its own file and can be tested without the other two.
- Step 01
Fetch
One guarded HTTP request. The dialer refuses private and link-local addresses on every hop, so a URL that redirects somewhere it should not reach is stopped there rather than after the fact.
- Step 02
Extract
The document is reduced to the subtree a reader would call the content, plus the title, description and canonical URL the page claims for itself. If the HTML alone is not enough, this is where a headless browser gets involved.
- Step 03
Render
That subtree becomes Markdown with its structure intact — headings, lists, code and links, with relative URLs resolved against the page. It is the format a model reads best and a person can still diff.
- Two ways to call it
Over HTTP at /v1/crawl when your code is doing the asking, or over MCP when a model is.
- Reads
- Static Sites
- SPAs
- Documentation
- E-Commerce
- Forums
- REST API
- Returns
JSFull rendering
ParallelHigh throughput
LLMStructured extraction
MDClean Markdown
Pricing
You are paying for the hosted API and the browsers behind it, not for the code.
Which plan covers it
50,000pages/month
Build · $49/mo · 5 concurrent crawlers
Build
$49mo
- 50,000 pages/month
- 5 concurrent crawlers
- JavaScript rendering
- Markdown + structured output
- REST API access
Scale
$499mo
- 500,000 pages/month
- 25 concurrent crawlers
- Priority JS rendering
- LLM-based extraction
- Direct Search + Vector integration
Enterprise
Custom
- Unlimited pages
- Unlimited concurrent crawlers
- Dedicated rendering pool
- Custom extraction schemas
- Dedicated support + SLA
The crawler is open source, and so is the headless-browser image it escalates to. Run both yourself for nothing. The plans buy you somebody else operating them.
Send it a URL
One call, and the page comes back as Markdown.
From your code over HTTP, or from a model over MCP.
deploy the gateway to staging
hanzo
reading the project
gateway is on staging
Example project. Every name in it is one you would give your own.
Related capabilities
Get Crawl
Crawl, scrape, and embed
Paste and ship
Paste this into any agent. It reads the skill manifest and calls Crawl from there.
api /v1/crawl
Read https://hanzo.ai/skill.md and use Hanzo Crawl in my project. Start with: hanzo crawl create