Architecture

How Scout works

A technical deep-dive into Scout's connector platform: individual MCP servers, identity-aware request handling, browser runtime paths, and capability boundaries that stay separated by design.

The connector stack

Scout is organized as a clean separation of concerns. Each layer has a single responsibility and communicates through well-defined protocols.

01

Agent client

MCP over HTTP

Any MCP-compatible AI client. It installs or configures the connector MCP server whose capability boundary matches the task and sends typed tool calls.

The client does not need to know whether a capability is backed by a browser session, Node inspector, host machine bridge, Figma plugin runtime, or payment adapter. It sees a standard MCP server with declared tools and schemas.

Claude DesktopCursorClineCustom agentsCustom MCP clients

02

Connector servers

Streamable HTTP MCP

Connector MCP servers. Each connector owns a product capability, its tool catalog, its runtime boundary, and its streamable HTTP transport.

Connector servers are built from the shared create-connector runtime. They register MCP tools, mount identity-aware bearer auth, hydrate credits, and dispatch tool calls into the runtime that owns the capability.

browsernodesystemfigmapaymentorchestration

03

Identity and metering

Bearer auth

Shared request boundary for MCP connector servers. Every hosted connector resolves the caller, establishes the worker identity, and meters capability usage before execution.

OAuth-capable MCP clients can use Firebase-backed auth. Scout access tokens support clients and automation environments that cannot complete browser OAuth. Chrome extension model calls use the user's configured AI provider key through the Mastra server.

Firebase ID tokensScout access tokensworker identitycredit balancetool cost lookup

04

Capability runtimes

CDP, native APIs, service adapters

Execution runtimes. MCP clients call connector servers for clean hosted sessions; the Chrome extension connects to the Mastra server when an agent needs the user's real browser state.

The extension is no longer the whole architecture. It is the app runtime for real-browser workflows. Durable session transports keep Mastra server and browser state coordinated without making every public connector an extension bridge.

clean Chromium sessionsextension-owned sessionsCDP adaptersdurable streamscapability handlers

Browser connector coverage

Browser automation is Scout's broadest connector server. These groups map to browser/runtime operations exposed through MCP tools.

Page

Core page lifecycle. Navigate URLs, capture screenshots, generate PDFs, manage navigation history.

navigate()reload()captureScreenshot()printToPDF()getNavigationHistory()

Runtime

JavaScript execution context. Run code in the page, capture console output, handle exceptions.

evaluate()callFunctionOn()consoleAPICalled eventexceptionThrown event

Network

Full network stack access. Intercept requests, capture responses, manage cookies at protocol level.

requestIntercepted eventsetCookies()getCookies()getResponseBody()

DOM

Direct DOM access. Query nodes, read and modify attributes, extract HTML without JavaScript evaluation.

querySelector()getAttributes()getOuterHTML()setAttributeValue()

Accessibility

Accessibility tree snapshot. The foundation of Scout's snapshot tool — provides structured semantic content without parsing HTML.

getFullAXTree()queryAXTree()

Input

Programmatic input injection. Simulate clicks, keystrokes, and touch gestures at the protocol level.

dispatchMouseEvent()dispatchKeyEvent()dispatchTouchEvent()synthesizePinchGesture()

Emulation

Device and environment overrides. Emulate mobile devices, spoof geolocation, override timezone.

setDeviceMetricsOverride()setGeolocationOverride()setTimezoneOverride()

Target

Tab management. Attach sessions, list targets, create new tabs, manage the CDP session lifecycle.

attachToTarget()detachFromTarget()getTargets()createTarget()

Browser execution lifecycle

What happens between an MCP client connecting to the browser connector and Scout returning a browser result.

01

Client connects

The MCP client connects to the hosted browser connector over streamable HTTP and completes OAuth or presents a Scout access token for non-interactive use.

02

Identity is resolved

The shared connector runtime resolves firebaseBearerAuth, establishes the worker identity, hydrates the credit balance, and prepares the request context.

03

Tool is dispatched

The connector looks up the browser tool, validates its schema-backed arguments, and dispatches the call to the browser handler that owns that behavior.

04

Runtime executes

The browser runtime launches or attaches to the requested session. Hosted sessions provide clean automation; extension-backed sessions preserve a user's real tabs and authenticated browser state.

05

Result returns

The handler returns a structured MCP result. Subsequent calls can use returned refs for tabs, frames, elements, files, downloads, dialogs, network events, and session state.