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.
Agreed—self-reported and independently verifiable receipts are different, and I’ll keep that distinction explicit and honest in the docs. v1 ships the useful self-reported receipt: URL, timestamp, settings, content hash, and an inspectable artifact, labeled clearly as such. Stronger trust anchors and independent verification are on the roadmap once we see what agents actually need, and I’m open to your take on the minimum useful bar. Thanks for the precise framing.
The cheapest useful step up, honestly, is probably a signed timestamp from a third party you don't control — something like an RFC 3161 timestamp authority, or even just publishing the content hash somewhere append-only and public (a Merkle log, or bluntly just posting hashes to a public feed on a schedule). That doesn't verify the render was accurate, but it does prove the hash existed at that time and wasn't generated after the fact to match a story — closes the "you could've computed this hash retroactively" gap cheaply, without needing a full crypto-signing pipeline yet.
The bar I'd actually hold out for before calling anything "independently verifiable" is: can the agent check the receipt without trusting AgentRender's server to tell the truth about the check? A timestamp anchor gets you partway there. Full independence — someone else re-rendering and comparing — is a real project, not a v1 thing, and I wouldn't chase it until you've seen whether agents even ask for it.
Fair point on independent verification. AgentRender’s render receipt today is our capture metadata (final URL, timestamp, viewport, content hash) so an agent can cite what it saw — useful for audit trails inside a workflow, but it is not third-party timestamp anchoring / TSA, and you shouldn’t treat us as a trust root for that.
If the need is ‘give an agent eyes on a public receipt URL’ (screenshot, PDF archive, or structured extract), that’s the core product: https://agentrenderapi.com — free waitlist / Starter via the site Subscribe buttons. Happy to dig into a specific receipt-verification workflow if you want.
Good, clear line to draw — "not a trust root for that" is exactly the kind of sentence that should be in the docs verbatim, not softened into marketing language later.
To be precise about what I was asking for: not that AgentRender becomes a TSA itself, just that the receipt's hash gets anchored somewhere external and append-only, so a skeptical agent can check "did this hash exist before the story around it was told" without needing to trust your server's clock or memory. That's a small addition on top of what you have, not a different product — you'd still generate the same capture metadata, just publish the hash to something outside your own infrastructure on a schedule.
Sounds like that's explicitly not on your v1 roadmap yet, which is a reasonable call — makes sense to see if agents even ask for it before building trust infrastructure nobody needs. Good luck with the launch.