- at 'minting' time, uses OpenAI API keys, instead of coding agent subscription
- tries to solve for a particular use case, instead of all the site provides
am03 1 days ago [-]
Printing Press is a great project! At a philosophical level, Pomerado is meant to be more autonomous - it's a standalone harness that you can run, and it's meant to require as little review as possible after the first request. If there are questions about the site or intent, we have coding agents with application context answer those questions.
We find this integrates into automated software development workflows a lot better, and my Openclaw can basically create new MCPs for me with little supervision required.
In terms of mechanisms, Pomerado uses a mix of HTTP requests and generated Playwright code. Printing Press has a far greater emphasis on making HTTP requests to the site's backend. We've found for some sites this latter approach can create issues around triggering anti-bot and can fail for more complicated forms and writes, so we use Playwright for those instances.
Pomerado's approach to researching the website is also a bit different - we solely focus on exploring the website itself, while Printing Press has your agent explore the web for documentation, SDKs, etc. There's a tradeoff of prompt injection security vs convenience there. Because we try to emphasize autonomous builds we limit the agent to the website for security.
A big pain point for us with existing approaches was using them for cloud agents (e.g., my Openclaw on my VPS). Cloud starts running into a lot of issues around hosting, authentication, and anti-bot, which is why we started offering a free hosted version of the open source, where we handle cloud browsers, proxy rotation, credential storage, CAPTCHAs, etc.
We're planning to roll out support for CLIs down the line! And the PR for non-OpenAI models + codex exec is in the works :)
bshafiq 1 days ago [-]
Congrats on the launch! The approach of turning unstructured sites into deterministic MCPs is really interesting, especially the self-healing maintenance jobs.
Curious about the failure mode: what happens when a browser action fails or times out? The agent will often just blindly retry the exact same MCP tool call with the exact same arguments. Since the tool call itself returns a 200 OK, standard retry counters miss it, and you just burn tokens while the browser keeps timing out in the background.
Are you doing any payload/state validation at the runtime layer to hard-stop those cyclic failures before the next call, or does the Guardian model handle that?
alanjm23 1 days ago [-]
Thanks! When a browser action fails or times out, the repair agent should step in to fix the integration and prevent retries from looping. There are also a few conditions where we automatically kick off a repair without a failing job, such as a streak of rejected inputs or site errors. This is to try and prevent silent failures.
bshafiq 13 hours ago [-]
Makes sense. But what happens if the repair agent itself gets stuck looping?
If the MCP call returns a 200 OK while the underlying browser times out silently, you're just burning tokens. Are you using a deterministic state hash to hard-kill the run, or relying entirely on the repair agent?
shipsafestack 1 days ago [-]
How do you handle credentials and sessions for sites behind a login, like the bank and insurance portals you mention? Is the user's password or session cookie stored on your side, or does the generated MCP run against a session the user keeps locally?
Related: page content is untrusted input that now flows straight into an agent's context. Do the deterministic tools return only structured fields you've extracted, or can arbitrary page text (reviews, messages, product descriptions) pass through? That seems like the main prompt-injection surface for anything that can also perform actions like checkout.
alanjm23 1 days ago [-]
For our hosted version, the session runs in our hosted browser. For the open source, it runs on a local browser.
In the hosted version, users can choose to pass logins at runtime or store them in our vault. Once a user logs in, we keep their session as a Chrome profile and attach it to a sticky IP, so that they stay logged in for longer.
Deterministic tools return only the structured fields, and don't parse the whole browser DOM. Since tools are deterministic, we also reduce the risk of prompt injections.
nightmoose 11 hours ago [-]
Interesting approach. Curious how you handle silent drift: the site changes, your API still returns 200, but a field goes null or gets renamed. Do you validate every response against the published schema before it reaches the agent, or only re-generate when something hard-fails? In my pipelines the scary failures are the ones that still return 200 and look fine.
hank2000 9 hours ago [-]
MCPs are already often wildly inefficient. One thing I saw said the agent had to process 8x tokens just to read the instructions vs the actual tool calls it made.
I would imagine this makes wildly inefficient instructions? Yes usable. But at what cost? Or am I wrong?
jeroenhd 23 hours ago [-]
Do you respect the wishes of sites and services that do not want the extra load? How does one opt their online service out?
vkchap2 16 hours ago [-]
Congrats on the launch. One question from our own work (we build a tool that finds hidden text in documents before an agent reads them): when you turn a page into an API, what happens to text the page hides from people? Think display:none, zero-size fonts, off-screen elements and HTML comments. Some sites now put instructions aimed at agents in exactly those places.
Does the generated API pass that text through to the agent, or only what a person would see on the page?
turbogen_app 18 hours ago [-]
How do you handle actions that take minutes rather than seconds? When I wrapped a slow job API as MCP tools, the first version blocked until the job finished, and some clients gave up long before that. What worked better was having the tool wait for a bounded time and, if the job isn't finished, return a job id plus a separate status tool the agent can call later. Do your generated tools do something similar for slow portal flows like a booking confirmation, or is everything expected to finish inside one call?
jrecyclebin 1 days ago [-]
Site must be slammed - but I'm interested bc I'm working on a similar thing. But my project (one aspect at least) is for expressing HTTP calls as MCP tools.
The format looks like this:
---
[add-list-item] Add a new item to a list.
# Adjust the fields object to match your list's actual columns.
$fields is object
POST https://graph.microsoft.com/v1.0/sites/$site_id/lists/$list_id/items
Authorization: Bearer $token
Content-Type: application/json
{
"fields": $fields
}
HTTP 201
Been having a lot of fun with this, as I can pile up these integrations and make detailed MCPs quickly.
alanjm23 23 hours ago [-]
Makes sense, how do you manage sites with Akamai / DataDome / other vendors? Would love to learn more
KallowayThayer 1 days ago [-]
Curious how this handles session isolation and rate-limiting when converting dynamic DOM heavy pages into MCPs.
If an agent hits a heavy SPA with infinite scroll or aggressive bot protection, does Pomerado handle edge-caching or proxy-level deduplication, or is it parsing raw DOM on every tool call?
alanjm23 1 days ago [-]
Hi! Unlike traditional scrapers we don't parse the entire DOM on every tool call. Because we build custom integrations for every site, we can be more targeted in our approach, like only checking specific fields.
We don't edge-cache or deduplicate calls, to give users live data.
For session isolation, we give each worker its own browser, cookies, and IP to isolate user sessions and prevent rate limiting.
hkalbert71 1 days ago [-]
One distinction worth measuring is transport success versus actual operation success.
A tool can return HTTP 200 while making no useful progress. The agent may then repeat the same call with identical arguments.
We're exploring this from an observability angle with KORA Doctor. It can flag repeated tool calls using privacy-preserving fingerprints, but it doesn't block live retries or determine whether caching is safe.
Do your generated MCP tools expose operation-level status or state-change evidence so external tools can distinguish a successful repair from another no-op retry?
alanjm23 23 hours ago [-]
Hi! We have our tools try to confirm every write before they end. This can be quite difficult in reality, so we do have a "can't tell" state as well that we're trying to cut down on.
hkalbert71 21 hours ago [-]
Thanks, that makes sense. Treating "can't tell" as an explicit outcome seems important, rather than counting an unconfirmed write as success.
Does that state get returned to the calling agent as structured output, or does it stay inside your repair workflow?
If it's exposed, trace-based diagnostics could distinguish verified writes, failed writes, and uncertain writes without assuming HTTP 200 means success.
yunuserturk 17 hours ago [-]
Hosting providers and cloudflare already block bots using bot lists. What user-agent does their agent identify itself as? Does it follow robots.txt, or is there a separate signal? What happens when it gets caught by cf's bot protection?
dogscatstrees 1 days ago [-]
> We’re ex-McKinsey
I see this often, qualifying ex-big consulting firm. What does it imply? Could it be more specific?
alanjm23 1 days ago [-]
Hi! I was an ex-agent / digital strategy consultant at McKinsey. Before that I studied math and did classical ML research
dionnam 9 hours ago [-]
hahaha it really is interesting approach.
Basically, you guys are making crawler for all the websites.
But still, it might not be that useful if we need to log in again all the time when we wanna use the api.
gvieira 1 days ago [-]
I built a self-healing scraper for arbitrary car dealership sites. Layout changes were the easy part to heal; anti-bot was where it got hard. Curious how your repair agent handles that.
am03 1 days ago [-]
We have a lot of car dealership users actually! We have a custom stealth stack in our free hosted version that addresses some of the more complex anti-bot elements, including in-house CAPTCHA solvers, custom Chromium adjustments, etc. Generally when we have repairs those have to do with site changes moreso than anti-bot itself.
Curious if there are any particular sites you've had trouble with!
passive 1 days ago [-]
Hmm, I've also built a self healing system for agents to get data from various services. Do you have any sort of dashboard showing integration maintenance?
alanjm23 1 days ago [-]
Great that you're building as well, we think it's a really interesting space.
We don't have a maintenance-specific dashboard. We do maintenance at execution time, so the dashboard paradigm doesn't apply as well. Instead of proactively checking for site changes, we check at execution time and repair integrations on-the-fly, when necessary.
passive 1 days ago [-]
I would still be interested to see metrics around the process. Overall throughput, what's the error rate, how many errors get turned into fixes, are certain types of websites less stable?
My self healing project is very experimental, so tracking and displaying these kinds of metrics are important to judging the success of the experiment.
am03 1 days ago [-]
We're seeing about a 2.2% error rate on runs, and 82% of those errors get automatically resolved by our repair agents currently. The highest failure rates seem to come on travel and automotive marketplaces, as they tend to have more complex interfaces. By contrast we have near-zero error rates on retail.
passive 1 days ago [-]
Cool!
Thanks for sharing, I'll definitely keep an eye on the project, and maybe even explore relying on Pomerado to connect to certain data. :)
theturtletalks 1 days ago [-]
I want to slap this on LinkedIn Sales Navigator, but some say it gets your account banned if they detect using using the DOM or accessibility.
am03 1 days ago [-]
Yep Linkedin is very touchy. We don't have support yet, but something we're thinking about! Our top priority is making sure people don't get banned.
alanjm23 1 days ago [-]
Hi! We don't recommend using this on LinkedIn, we're confident in our tech but don't want anyone to get banned. You could try Ploid?
a_c 1 days ago [-]
What does self healing mean here? And are you guys trying to be a more general version of webMCP? Looks promising, congratulations on the launch!
alanjm23 1 days ago [-]
Thanks! We self-heal integrations on-the-fly. So when an execution fails or identifies a large site change, we have a repair agent that steps in and fixes the deterministic tool.
Yep, I think the primary difference between us and WebMCP is that Pomerado doesn't require participation from the website owner. So for WebMCP the site has to opt in, while Pomerado works on any site.
thefourthchime 1 days ago [-]
How do you get around bot detection? For example, if I pointed this at Amazon, I don't expect it would work.
But does it magically somehow?
am03 1 days ago [-]
Amazon does work! It's actually one of our most used tools. We have a custom stealth stack consisting of things like in-house CAPTCHA solvers, cloud browsers, custom IPs, and adjustments to playwright that help us with matching normal web traffic.
Would recommend you try it out, seeing is believing
thefourthchime 1 days ago [-]
wow nice!
matt3210 1 days ago [-]
Too bad MCP server calls dont click ads
alanwreath 1 days ago [-]
The weight of this statement affects me directly.
trash_cat 1 days ago [-]
This is useful but im asking myself what would stop OpenAI and Anthropic to implement this natively tomorrow.
am03 1 days ago [-]
Of course, there's nothing preventing anyone from trying this idea as well, but to us it's a fairly different approach to browser use. There's some additional infrastructure around managing anti-bot and things like that which bigger companies seem more hesitant to do. The token savings also cut fairly strongly into their existing margins.
nswizzle31 1 days ago [-]
Legal risk, right? For instance, Muse seemed so good because it just blatantly disregarded anything the website owners tried to do to stop agents. Clearly they didn’t care. I’m using whatever gets stuck the least.
We have some provisional support for signing into Google oauth on sites if that's what you mean! Still in beta though. Our MCPs themselves also have an oauth option.
SevenIsNorth 22 hours ago [-]
[dead]
hyperionultra 1 days ago [-]
A wall of text. Just post video with a link to that wall of text for someone who is on to read gened strings.
The obvious differences I can see are:
- generates an MCP server instead of a CLI
- at 'minting' time, uses OpenAI API keys, instead of coding agent subscription
- tries to solve for a particular use case, instead of all the site provides
We find this integrates into automated software development workflows a lot better, and my Openclaw can basically create new MCPs for me with little supervision required.
In terms of mechanisms, Pomerado uses a mix of HTTP requests and generated Playwright code. Printing Press has a far greater emphasis on making HTTP requests to the site's backend. We've found for some sites this latter approach can create issues around triggering anti-bot and can fail for more complicated forms and writes, so we use Playwright for those instances.
Pomerado's approach to researching the website is also a bit different - we solely focus on exploring the website itself, while Printing Press has your agent explore the web for documentation, SDKs, etc. There's a tradeoff of prompt injection security vs convenience there. Because we try to emphasize autonomous builds we limit the agent to the website for security.
A big pain point for us with existing approaches was using them for cloud agents (e.g., my Openclaw on my VPS). Cloud starts running into a lot of issues around hosting, authentication, and anti-bot, which is why we started offering a free hosted version of the open source, where we handle cloud browsers, proxy rotation, credential storage, CAPTCHAs, etc.
We're planning to roll out support for CLIs down the line! And the PR for non-OpenAI models + codex exec is in the works :)
Curious about the failure mode: what happens when a browser action fails or times out? The agent will often just blindly retry the exact same MCP tool call with the exact same arguments. Since the tool call itself returns a 200 OK, standard retry counters miss it, and you just burn tokens while the browser keeps timing out in the background.
Are you doing any payload/state validation at the runtime layer to hard-stop those cyclic failures before the next call, or does the Guardian model handle that?
If the MCP call returns a 200 OK while the underlying browser times out silently, you're just burning tokens. Are you using a deterministic state hash to hard-kill the run, or relying entirely on the repair agent?
Related: page content is untrusted input that now flows straight into an agent's context. Do the deterministic tools return only structured fields you've extracted, or can arbitrary page text (reviews, messages, product descriptions) pass through? That seems like the main prompt-injection surface for anything that can also perform actions like checkout.
In the hosted version, users can choose to pass logins at runtime or store them in our vault. Once a user logs in, we keep their session as a Chrome profile and attach it to a sticky IP, so that they stay logged in for longer.
Deterministic tools return only the structured fields, and don't parse the whole browser DOM. Since tools are deterministic, we also reduce the risk of prompt injections.
I would imagine this makes wildly inefficient instructions? Yes usable. But at what cost? Or am I wrong?
Does the generated API pass that text through to the agent, or only what a person would see on the page?
The format looks like this:
Been having a lot of fun with this, as I can pile up these integrations and make detailed MCPs quickly.If an agent hits a heavy SPA with infinite scroll or aggressive bot protection, does Pomerado handle edge-caching or proxy-level deduplication, or is it parsing raw DOM on every tool call?
We don't edge-cache or deduplicate calls, to give users live data.
For session isolation, we give each worker its own browser, cookies, and IP to isolate user sessions and prevent rate limiting.
A tool can return HTTP 200 while making no useful progress. The agent may then repeat the same call with identical arguments.
We're exploring this from an observability angle with KORA Doctor. It can flag repeated tool calls using privacy-preserving fingerprints, but it doesn't block live retries or determine whether caching is safe.
Do your generated MCP tools expose operation-level status or state-change evidence so external tools can distinguish a successful repair from another no-op retry?
Does that state get returned to the calling agent as structured output, or does it stay inside your repair workflow?
If it's exposed, trace-based diagnostics could distinguish verified writes, failed writes, and uncertain writes without assuming HTTP 200 means success.
I see this often, qualifying ex-big consulting firm. What does it imply? Could it be more specific?
Curious if there are any particular sites you've had trouble with!
We don't have a maintenance-specific dashboard. We do maintenance at execution time, so the dashboard paradigm doesn't apply as well. Instead of proactively checking for site changes, we check at execution time and repair integrations on-the-fly, when necessary.
My self healing project is very experimental, so tracking and displaying these kinds of metrics are important to judging the success of the experiment.
Thanks for sharing, I'll definitely keep an eye on the project, and maybe even explore relying on Pomerado to connect to certain data. :)
Yep, I think the primary difference between us and WebMCP is that Pomerado doesn't require participation from the website owner. So for WebMCP the site has to opt in, while Pomerado works on any site.
But does it magically somehow?
Would recommend you try it out, seeing is believing