Launching AgentRender — agent-native screenshot/PDF/extract API (MCP + REST), waitlist open
Hey IH —
AgentRender is live for early access: a public demo API that turns a public URL into a screenshot, PDF, or structured extract, with MCP tools so agents can call it without custom HTTP glue.
Links
- Site / waitlist: https://agentrenderapi.com
- Public demo API: https://api.agentrenderapi.com
Why this exists
AI agents keep growing, but babysitting Playwright/Puppeteer clusters still sucks. Category pricing is public (e.g. ScreenshotOne lists $17/$79/$259) — not claiming their revenue. Wedge: MCP + extract + render receipts.
What's available now
- Waitlist on the site
- Public demo API: screenshot/pdf/extract/healthz
- Real Chromium screenshots via Playwright
- Live pricing: Free 150, Starter $17, Growth $79, Scale $259 — Live Stripe checkout on the site; waitlist for free keys
Not ready: geo/stealth/video
Also posted a writeup on Dev.to for builders — looking for IH feedback + “would you pay $17 or $79?”
— Corbin
The rendering itself is becoming commoditized. Have early users shown that MCP + structured extraction actually removes enough integration/maintenance work to justify $17–$79/month over existing browser APIs?
Fair question. The $17–$79 ladder is for teams that want screenshot/PDF/extract as a hosted tool (REST + MCP) instead of running Chromium themselves — receipts/hash for agent audit trails are part of that. Free waitlist key is there if you want to poke before paying. Happy to hear what price point would feel right for your use case.
That hosted + audit-trail angle is interesting. If you’re open to it, what’s the best email to reach you on?
Thanks — corbinaiemail@gmail.com works. Send over a short note about your workflow or edge cases, and I’ll follow up.
Thanks! I’ve just sent it over.
Looking forward to hearing your thoughts whenever you have a chance.
If you’re building an agent that needs to hand off a visual artifact, I’d love to hear where screenshot/PDF/extract breaks down today. Those edge cases are exactly what we’re testing in early access.
"Render receipts" is the phrase I'd lead with instead of MCP — screenshot APIs are commodity at this point (you said so yourself with the competitor pricing), but a receipt that proves what was actually rendered, when, and against what state of the page is a different category of value entirely, especially for agents. What's actually in a receipt — a hash of the rendered output, a timestamp, the exact URL and any params that affected rendering (viewport, wait conditions, JS execution state)? That's the part I'd want spelled out before answering pricing, because if the receipt is genuinely verifiable (not just "we say this was rendered at time X"), that's worth more than the screenshot itself for an agent that needs to prove it acted on real, current state rather than a stale cache.
On $17 vs $79 — depends entirely on whether receipts are a Free/Starter feature or gated to Growth. If verifiable receipts are the actual differentiator, I'd gate them higher and let plain screenshots compete on the commodity price the other providers already set.
This is a fair read. The first receipt version is intentionally simple: URL + timestamp + viewport/wait settings + a content hash, with the rendered artifact available to inspect. I don’t want to overclaim tamper-proof provenance yet—we’re testing what agents actually need.
And yes, receipts are likely the differentiator we’ll gate carefully, not basic screenshots. Really useful framing—thank you.
"I don't want to overclaim tamper-proof provenance yet" is the right instinct, and it's a more disciplined answer than most people give at this stage — a content hash without a trust anchor (signed by something the agent didn't have to trust the API itself for) is a checksum, not proof, and saying so plainly instead of implying otherwise is worth more than the feature itself early on.
If it's helpful: the honest label for what you have right now is closer to "self-reported receipt" than "verified receipt" — real, useful, but the agent is still trusting your service's word that the hash matches what was actually rendered. True tamper-evidence would need something like a signature the agent could verify independently of trusting AgentRender's own claim. Not saying you need that for v1, just that the distinction is worth keeping explicit in the docs once this ships, so nobody mistakes "we computed a hash" for "this can't have been faked."
Good luck with the gating — sounds like the right instinct.