Browser Automation Environment

Give agents real tools.
Keep the runtime honest.

Scout is where AI agents observe, understand, and operate real browsers. Drive a durable, capability-bounded window into the web from the client your agent already uses, or pair a platform adapter when a specific app is in scope.

agent.tsTYPESCRIPT
// Connect your agent to the browser runtime
const transport = new StreamableHTTPClientTransport(
  new URL("https://mcp.scout.i.ng/browser"),
);

await client.connect(transport);

const { tools } = await client.listTools();
// -> browser-navigate, browser-snapshot, browser-interact,
//   browser-extract, browser-screenshot, ...

await client.callTool({
  name: "browser-navigate",
  arguments: { action: "goto", url: "https://example.com/dashboard" },
});

const snapshot = await client.callTool({
  name: "browser-snapshot",
  arguments: {},
});
// -> Ref-backed snapshot of the live page

const content = await client.callTool({
  name: "browser-extract",
  arguments: { property: "text", selector: "#metrics-panel" },
});
// -> Text content from the selected element

Built for agent-driven browser automation

Scout gives AI agents direct, reliable access to browser capabilities across automation, canvas, extension, and payment surfaces.

⬡

Capability-owned surfaces

Scout keeps browser, canvas, extension, and payment tools in scoped groups inside the browser runtime instead of one overloaded surface. Platform adapters pair on their own boundary.

▸

Browser runtime

The browser runtime owns navigation, snapshots, interaction, extraction, network, storage, screenshots, crawling, media, tracing, and other page operations.

◈

Extension runtime bridge

The Chrome extension is the app path for real-browser workflows. It connects to Scout's runtime, uses its built-in tools, and routes model calls through the AI provider key you configure.

◉

Typed ref system

The browser runtime returns ref-backed snapshots, so agents can target tabs, sessions, elements, frames, network events, downloads, dialogs, files, and logs across tool calls.

◆

Identity and metering

Agent access is identity-aware. OAuth-capable clients use browser sign-in; explicit tokens exist for CI and non-interactive clients. Extension users provide an AI provider key for model routing.

◎

One environment, many surfaces

The browser runtime serves the capability surfaces you connect, and platform adapters pair through their own runtime. Configure one surface or compose several.

Runtime-first architecture

Scout is organized around two paths: agents connect to runtime surfaces directly, while the Chrome extension connects to the Mastra server and uses the user's AI provider key.

Agent client (Claude, Cursor, Cline, custom agents)
Streamable HTTP MCP
↓ connector URL
Selected Runtime Surface
Tool Catalog + Identity + Metering
↓ typed dispatch
Capability Runtime
Browser, canvas, extension, payment, platform adapters, Mastra extension path
↓ adapter boundary
Work Context
Clean session, real browser, host API, or service API
Capability-scoped surfacesOAuth, token, or provider keyRequest-scoped meteringDurable browser sessions

Runtime surfaces

Browser, canvas, extension, and payment share one hosted browser runtime with scoped tool groups, while platform adapters pair on their own boundary.

Shared agent runtime

Surfaces mount a standard agent interface, resolve bearer auth, check the caller's allowance, and invoke typed handlers.

Browser runtimes

Browser work can run in clean hosted sessions or through the extension path, where Mastra uses your provider key and real browser state.

Capability boundaries

Canvas, extension, and payment work stay in scoped groups rather than pretending to be generic page automation; platform adapters keep their own contract.

Four steps to browser automation

From setup to structured data extraction in minutes. No infrastructure setup, no browser farm configuration, no SDK integration.

01

Choose a surface

Choose the surface your agent needs. Most agent work starts with the browser runtime, which covers automation, canvas, extension, and payment surfaces; platform adapters pair separately.

02

Authenticate the agent

Point your agent at Scout and let OAuth discovery complete sign-in. Explicit tokens are reserved for CI, scheduled jobs, and clients that cannot open a browser auth flow. The Chrome extension uses provider-key setup instead.

03

Call typed tools

The runtime registers its tools, validates typed inputs, resolves request identity, checks the caller's allowance, and dispatches the call to the capability surface that owns the operation.

04

Run the automation loop

For browser workflows, the result is a stable loop: launch or attach, snapshot, act through refs, observe events, extract content, and close or detach when the work is complete.

Just ask your AI

You don't write code to use Scout. You tell your AI what you need, in Cursor, Claude, VS Code, or any agent client, and Scout handles the browser.

Extraction

“Go to techcrunch.com and extract the top 5 headlines with their URLs”

Scout navigates to the page, takes an accessibility snapshot, identifies article elements, and returns structured JSON.

Interaction

“Fill out the contact form on example.com with my name and email, then submit it”

Scout snapshots the form, locates input fields by their accessible names, fills each one, and clicks submit.

Testing

“Screenshot our pricing page at 375px, 768px, and 1440px widths”

Scout resizes the viewport three times, capturing a full-page screenshot at each breakpoint.

Debugging

“Open our staging site and tell me if there are any console errors or failed API calls”

Scout monitors the browser console and network activity, then reports any errors or failed requests.

Research

“Crawl docs.example.com and find every page that mentions "authentication"”

Scout crawls the documentation site, extracts each page's content, and filters for mentions of the keyword.

Workflow

“Log into the admin panel, go to settings, and export the user list as CSV”

Scout chains navigation, form interaction, and data extraction across multiple pages in a single session.

70+

Typed tools

12

Capability categories

<5 min

Setup time

0

External dependencies

8+

Supported agent clients

10

Browser actions per batch

Why Scout is different

Most browser automation tools require you to run browsers somewhere else. Scout runs in the browser you already have.

Scout

Capability-owned surfaces

Scout keeps browser, canvas, extension, and payment tools in scoped groups inside the browser runtime, with platform adapters pairing on their own boundary.

Others

One large generic tool server

Scout

Remote and real-browser paths

The browser runtime is the default for clean automation, while the extension path exists for real-browser state. The user chooses the browser context instead of being forced into one runtime.

Others

Remote-only or extension-only

Scout

Standard agent interface

Each surface exposes typed tool schemas, validates inputs, and returns structured results. Agents integrate through the protocol they already use without learning internal runtime details.

Others

Custom API wrappers

Scout

Path-specific credentials

OAuth is the normal path for agent clients, explicit tokens are fallback credentials, and extension users configure their AI provider key for model routing.

Others

Static shared API keys

Scout

Durable session transport

The extension uses durable session streams and explicit registration rather than assuming a server can directly reach into a user's browser.

Others

Hidden browser bridge

What you can build

Scout provides the primitives. You decide the application. From testing to research, monitoring to extraction.

Agentic browser work

Give coding assistants and operators a browser runtime they can call directly from chat, with typed tools for page state, actions, screenshots, network, storage, and extraction.

Isolated automation

Run clean browser sessions for scraping, research, QA, and CI without borrowing your personal browser cookies or tabs.

Real-browser delegation

Use the extension path when the agent must operate the real browser you are already using, including existing tabs and authenticated sessions.

Local and design-tool automation

Give agents access to canvas inspection, WebGL surfaces, and platform adapters as scoped capability surfaces of the Scout runtime.

Payment-capable agent flows

Let payment-aware workflows inspect balances, challenges, commerce data, transfers, and wallet-backed actions through a separate payment capability boundary.

Developer-first connector interface

Connect to the capability surface you need, authenticate once, and call typed tools through standard MCP transports.

SnippetTYPESCRIPT
import { Client } from "@modelcontextprotocol/sdk/client";
import { StreamableHTTPClientTransport } from "@modelcontextprotocol/sdk/client/streamableHttp.js";

const client = new Client({
  name: "my-agent",
  version: "1.0.0",
});

await client.connect(
  new StreamableHTTPClientTransport(
    new URL("https://mcp.scout.i.ng/browser"),
  ),
);

// Discover available browser tools
const { tools } = await client.listTools();
// -> browser-navigate, browser-snapshot, browser-interact,
//   browser-extract, browser-screenshot, ...

// Navigate to a page
await client.callTool({
  name: "browser-navigate",
  arguments: { action: "goto", url: "https://app.example.com" },
});

// Get structured page content
const snapshot = await client.callTool({
  name: "browser-snapshot",
  arguments: {},
});
API Reference →Tool Catalog →Connector Setup →Examples →

Engineering guarantees

Scout is built around explicit capability ownership, request identity, and runtime boundaries that survive real agent workflows.

Surface ownership

Scout's browser runtime is one environment with typed tool inputs and structured outputs, but its tool catalog is capability-owned: canvas, extension, and payment tools stay in scoped groups instead of leaking into generic page automation. Platform adapters pair on their own boundary.

-Capability-owned tool catalogs
-Schema-backed inputs and outputs
-Explicit runtime boundaries

Identity boundary

Hosted requests resolve a bearer identity before execution. OAuth-capable clients use sign-in; explicit tokens are available for non-interactive clients.

-Firebase ID token path
-Scout MCP token fallback
-userId and workerId segmented at auth boundary

Metered execution

Active work is metered against the caller's Agent Hour allowance inside the shared connector runtime, close to the tool call, instead of as an afterthought in the UI.

-Agent Hours tracked per request
-Request-scoped allowance check
-Budget-aware execution

Browser context control

Browser automation has two honest paths: clean connector-managed sessions for MCP clients, and the Chrome extension path through the Mastra server when the agent must operate a real user browser.

-Hosted browser runtime
-Mastra extension path
-Durable session registration

Durable sessions

Long-lived browser work is modeled as durable session state and streaming transport, so server and runtime coordination has a real lifecycle.

-POST /v1/sessions registration
-HTTP/SSE-style tail streams
-Explicit cleanup boundaries

Runtime clarity

Scout keeps runtime-specific power in scoped groups inside the browser runtime instead of collapsing everything into one page-automation surface. Agents configure the browser runtime; extension users configure their AI provider key.

-Dedicated capability surfaces
-No accidental cross-group API
-Path-specific setup

Connect an agent to Scout

Start with the browser runtime, then add the extension or specialized surfaces when your workflow needs real-browser state, local runtime access, or a specific platform adapter.

Scout uses analytics to understand which pages are useful and where visitors drop off.

See our Privacy Policy and Terms of Service for details.