Pomerado's Self-Healing API Layer: MCP Adapters Turn Brittle Web Scraping Into Deterministic Agent Tools

Agents need to book flights, pay bills, and check order status. Most of those systems don't expose APIs. Browser automation works but breaks constantly when sites change their DOM. Pomerado (YC F26) builds a self-healing adapter layer that converts arbitrary websites into Model Context Protocol servers with deterministic tool interfaces.

The core problem is contract stability. An agent calling search_flights(origin, destination, date) expects the same schema tomorrow even if United redesigns their search page tonight. Traditional scrapers fail silently or throw cryptic XPath errors. Pomerado claims to detect DOM changes and rewrite extraction logic without human intervention.

The security angle matters because this architecture introduces credential delegation, session hijacking risks, and a new attack surface between agents and sensitive web portals. You're proxying bank logins and payment flows through a third-party adapter layer.

Architecture: Web to MCP Tool Pipeline

Pomerado sits between the agent framework and the target website. The flow:

1. Tool definition phase: User points Pomerado at a website and describes the desired action ("search flights"). The system records a session, extracts the interaction pattern, and generates an MCP tool schema.
2. Selector generation: Instead of brittle CSS selectors, Pomerado builds a multi-signal extraction strategy (semantic labels, ARIA attributes, positional heuristics, visual bounding boxes).
3. Execution runtime: When an agent calls the tool, Pomerado fetches the page, applies the extraction logic, and returns structured JSON matching the MCP tool schema.
4. Self-healing loop: On extraction failure, the system re-analyzes the page structure, compares against the original recording, and attempts to infer the new selector path. If successful, it updates the tool definition and retries.

The MCP integration means agents see a standard tool interface:

{
  "name": "search_flights",
  "description": "Search for flights on United Airlines",
  "inputSchema": {
    "type": "object",
    "properties": {
      "origin": {"type": "string"},
      "destination": {"type": "string"},
      "date": {"type": "string", "format": "date"}
    },
    "required": ["origin", "destination", "date"]
  }
}

The agent doesn't know or care that this tool is backed by a web scraper. It calls the function, gets structured data back, and continues reasoning.

Self-Healing Selectors: Detection and Rewrite Logic

The self-healing claim rests on two mechanisms:

Redundant extraction signals: Pomerado doesn't rely on a single CSS selector. It builds a weighted ensemble:

• Semantic HTML (form labels, button text, heading hierarchy)
• ARIA attributes and accessibility tree structure
• Visual layout (element position relative to stable landmarks)
• Text content and pattern matching

When one signal fails, the others provide fallback paths.

Diff-based selector repair: When extraction fails, Pomerado fetches the current page and compares its structure to the recorded baseline. It looks for:

• Renamed CSS classes or IDs
• Moved elements with similar semantic content
• New wrapper divs that shifted the DOM depth
• Changed attribute names but identical functionality

If it finds a plausible match (high semantic similarity, same interaction type), it updates the selector and retries. If the match confidence is low, it flags the tool as degraded and notifies the user.

When sites make cosmetic changes (CSS refactors, layout tweaks), the ensemble approach succeeds. When sites fundamentally change their interaction model (switching from a form to a chat interface, moving functionality behind a login wall), the adapter fails. For example, if an airline moves flight search from a multi-field form to a natural language input box, Pomerado cannot automatically infer the new extraction pattern because the semantic structure has changed, not just the selectors.

Determinism Guarantees and Failure Modes

"Deterministic API" is a strong claim when the data source is a live website. Here's what Pomerado can and cannot guarantee:

The determinism is at the interface layer, not the execution layer. The agent gets predictable tool signatures, but the underlying operation can still fail due to network issues, bot detection, or site downtime.

Mid-session redesign scenario: If a site deploys a breaking change while an agent is executing a multi-step workflow, Pomerado's self-healing runs per tool call. If step 1 succeeds and step 2 encounters the new layout, the healing logic attempts to adapt. If it can't, the tool call fails with a structured error. The agent sees a standard MCP error response and can retry or escalate.

State reconciliation: Pomerado doesn't maintain cross-call state. Each tool invocation is stateless from the adapter's perspective. If an agent needs to maintain session context (like a shopping cart), it must either:

• Use a single long-running tool call that completes the entire flow
• Store intermediate state in the agent's own memory and pass it as parameters to subsequent calls

Authentication and Session Management: The Security Boundary

The hard part of turning websites into APIs is handling logged-in sessions. Pomerado's approach introduces a credential delegation model with specific security implications:

1. Keyless mode for public data: Read-only tools (search flights, check prices) work without authentication. The adapter makes anonymous requests.
2. User-delegated sessions: For authenticated actions (book a flight, pay a bill), the user logs in once through Pomerado's browser. The adapter captures session cookies and reuses them for subsequent tool calls.
3. Session refresh: When cookies expire, the tool call fails with an auth error. The agent can request a new login link, send it to the user, and retry after re-authentication.

Personal automation works well with this model (your agent acting on your behalf with your credentials). Multi-tenant scenarios where agents need to act on behalf of many users without manual login flows do not.

Security boundary: The user's credentials and session tokens live in Pomerado's infrastructure. Unlike Plaid (which uses OAuth and token vaults) or Stripe (which uses API keys with scoped permissions), Pomerado stores session cookies in unencrypted form. The risk surface includes:

• Credential exposure: If Pomerado's systems are compromised, attackers gain session tokens for banking portals, airline accounts, and e-commerce sites.
• Session hijacking: Pomerado stores and reuses cookies. A malicious insider or compromised adapter could replay those sessions to perform unauthorized actions.
• Audit trail gaps: The target website sees requests coming from Pomerado's infrastructure, not the end user. This breaks attribution and makes fraud detection harder.
• No end-to-end encryption: Pomerado sees all request and response data in clear text. Sensitive information (account numbers, transaction details) passes through their infrastructure.

For high-security environments (healthcare, financial services), this architecture requires careful threat modeling. You're introducing a new party into the trust chain.

Versioning and Contract Drift

MCP tools have schemas. Websites don't. When a site adds a new required field or removes an optional one, the tool definition drifts out of sync.

Pomerado's versioning strategy:

• Automatic schema updates: If the self-healing logic detects a new field with high confidence, it adds it to the tool schema as optional. Existing agent code continues to work.
• Breaking changes: If a required field is removed or renamed, Pomerado marks the tool version as deprecated and creates a new version with the updated schema. Agents must explicitly migrate to the new version.
• Testing and validation: Pomerado runs periodic health checks against live sites. If a tool starts failing consistently, it alerts the user before agents encounter errors in production.

There's no formal contract between Pomerado and the target website. The adapter is always playing catch-up.

Performance: Why This Beats Browser Agents

Pomerado claims 7x speedup over browser-based automation as of November 2026. The architectural difference:

Browser agents (like Anthropic's Computer Use):

• Spin up a full browser instance
• Render JavaScript, load images, execute tracking scripts
• LLM reasons through each page, deciding where to click
• High token cost per interaction, high latency per step

Pomerado adapters:

• Fetch raw HTML (or minimal JavaScript execution if required)
• Apply pre-computed extraction logic
• Return structured data in one round trip
• No per-page reasoning, just deterministic parsing

The benchmark data shows Pomerado completing an employee onboarding task across multiple systems in 8 minutes for $0.03, versus 21 minutes and $41 for Codex Computer Use (November 2026 version). The cost difference is mostly token usage. The speed difference is eliminating the LLM reasoning loop on every page.

The trade-off: Pomerado requires upfront tool definition. Browser agents can handle novel sites with zero setup. Pomerado is faster for repeated tasks on known sites. Browser agents are more flexible for one-off explorations.

Code Example: MCP Tool Invocation

Here's what an agent sees when calling a Pomerado-backed tool:

# Example using Anthropic's MCP SDK for Claude
# Actual implementation depends on your MCP client library

response = mcp_client.call_tool(
    name="search_flights",
    arguments={
        "origin": "SFO",
        "destination": "JFK",
        "date": "2026-12-15"
    }
)

# Pomerado adapter:
# 1. Fetches https://united.com/search
# 2. Applies extraction logic to find flight results
# 3. Returns structured JSON

# Agent receives:
{
    "flights": [
        {
            "flight_number": "UA123",
            "departure": "2026-12-15T08:00:00Z",
            "arrival": "2026-12-15T16:30:00Z",
            "price_usd": 342
        },
        # ... more results
    ]
}

The agent doesn't handle HTTP, selectors, or parsing. It just calls a function and gets typed data back.

Observability and Debugging

When a tool call fails, the agent needs actionable error information. Pomerado's error taxonomy:

• Extraction failure: "Could not find element matching selector for departure_date field"
• Authentication required: "Session expired, re-authentication needed"
• Site unavailable: "Target site returned 503, retry in 60 seconds"
• Rate limit hit: "Too many requests, backoff until 2026-11-11T21:00:00Z"

Each error includes a correlation ID that links to Pomerado's internal logs. For debugging, users can replay the exact request that failed and see the page state at failure time through the Pomerado dashboard interface.

Monitoring: Pomerado tracks per-tool success rates, latency percentiles, and schema drift events. If a tool's success rate drops below 95%, it triggers an alert.

Technical Verdict

Use Pomerado if:

• Task frequency exceeds 10 invocations per day (tool definition setup cost amortizes quickly)
• Target sites have DOM stability above 90% (self-healing handles cosmetic changes, not fundamental redesigns)
• You control user authentication and accept the credential delegation model (personal automation, internal tools)
• Cost and speed matter (7x faster, 100x cheaper than browser agents for repeated workflows)
• You need deterministic tool interfaces for agent orchestration (MCP schema stability is critical)

Avoid Pomerado if:

Critical risk (do not use)

• Security policy prohibits third-party credential storage (banking, healthcare, regulated industries)
• Multi-tenant credential model required (no secure way to proxy sessions for arbitrary users at scale)
• Target sites deploy breaking redesigns more than once per quarter (self-healing success rate drops below 80%)

High risk (requires additional safeguards)

• CAPTCHA or bot detection rate exceeds 5% (adapter can't solve interactive challenges)
• Visual reasoning needed (comparing product images, reading charts, interpreting layouts)

Medium risk (acceptable with monitoring)

• One-off tasks on novel websites (browser agents have lower setup overhead, but Pomerado can work if tool reuse is planned)

Security decision criteria:

• Accept this architecture only if you trust Pomerado with unencrypted session tokens for all integrated sites
• Implement additional monitoring for unauthorized actions (compare agent logs against site activity)
• Rotate credentials frequently and revoke Pomerado sessions when not in active use
• Avoid using Pomerado for sites with irreversible financial transactions unless you have rollback mechanisms

The adapter layer solves a real infrastructure gap but introduces a new trust boundary. Treat Pomerado like a credential aggregator: useful for personal automation and read-heavy workflows, risky for high-stakes transactions without additional safeguards.

Source Links

• Pomerado
• Hacker News Discussion
• Model Context Protocol Specification