Hosted MCP Connectors

Give agents real tools.
Keep the runtime honest.

Scout is a connector platform for AI agents. Install or configure the MCP server your workflow needs: browser automation, extension state, Node, system, Figma, payment, and orchestration each stay in their own connector.

agent.tsTYPESCRIPT
// Connect an MCP client to the browser connector
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 browser automation at protocol level

Scout combines the Model Context Protocol with Chrome DevTools Protocol to give AI agents direct, reliable access to browser capabilities.

Hosted MCP connectors

Scout exposes capability-owned MCP servers instead of one overloaded server. Browser, Node, system, Figma, canvas, payment, agent, extension, and orchestration each have a clear boundary.

Browser MCP server

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

Extension runtime bridge

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

Typed ref system

The browser connector 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

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

Composable MCP servers

Each connector can run as its own hosted MCP server or local server entrypoint. Users configure the servers they need for browser automation, runtime debugging, host tools, design tools, and payments.

Connector-first architecture

Scout is organized around two setup paths: MCP clients configure the connector servers they need, while the Chrome extension connects to the Mastra server and uses the user's AI provider key.

MCP Client (Claude, Cursor, Cline, custom agents)
Streamable HTTP MCP
↓ connector URL
Selected Connector MCP Server
Tool Catalog + Identity + Metering
↓ typed dispatch
Capability Runtime
Browser, Node, system, Figma, payment, Mastra extension path
↓ adapter boundary
Work Context
Clean session, real browser, host API, or service API
Separate MCP serversMCP auth or provider keyRequest-scoped meteringDurable browser sessions

Connector MCP servers

Each public capability has its own connector MCP server, hosted endpoint, tool catalog, and runtime boundary.

Shared MCP runtime

Connector servers mount streamable HTTP MCP, resolve bearer auth, hydrate credits, and invoke typed handlers.

Browser runtimes

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

Capability boundaries

Node, system, Figma, canvas, payment, agent, and orchestration work do not pretend to be browser tools; each keeps its own contract.

Four steps to browser automation

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

01

Choose a connector

Pick the MCP server your agent needs. Most browser automation starts with the browser connector; Node debugging, host machine actions, Figma, payment, and orchestration each use their own connector server.

02

Authenticate the client

Point an MCP-compatible client at the connector URL and let OAuth discovery complete sign-in. Scout access 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 connector registers its tools, validates typed inputs, resolves request identity, hydrates credits, and dispatches the call to the capability runtime 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 MCP 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+

MCP tools

12

Tool categories

<5 min

Setup time

0

External dependencies

8+

Compatible MCP 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 connectors

Scout keeps browser, Node, system, Figma, canvas, payment, agent, extension, and orchestration tools in separate MCP servers.

Others

One large generic tool server

Scout

Remote and real-browser paths

The browser MCP server 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 MCP servers

Each connector server exposes MCP tool schemas, validates inputs, and returns structured results. Clients integrate through the standard protocol without learning internal runtime details.

Others

Custom API wrappers

Scout

Path-specific credentials

OAuth is the normal path for MCP clients, Scout access tokens are explicit fallback credentials, and extension users configure their AI provider key for Mastra 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 MCP server 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.

Runtime debugging

Expose Node inspector capabilities, source inspection, breakpoints, console, profiling, memory, and runtime evaluation through a dedicated connector.

Local and design-tool automation

Give agents controlled access to local files, process/system utilities, canvas inspection, Figma documents, and other non-browser capabilities without mixing those tools into the browser connector.

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: {},
});

Engineering guarantees

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

Connector ownership

Every connector is its own MCP server with typed tool inputs and structured outputs. A browser server does not borrow system-tool semantics, and a payment server does not hide inside browser automation.

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

Identity boundary

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

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

Metered execution

Credit hydration happens inside the shared connector runtime, close to the tool call. Usage is metered per request instead of as an afterthought in the UI.

-Tool-cost lookup
-Request-scoped credit balance
-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 connector
-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 exposes runtime-specific power as separate MCP servers instead of collapsing everything into browser automation. MCP users configure the servers they need; extension users configure their AI provider key.

-Dedicated MCP servers
-No accidental cross-server API
-Path-specific setup

Connect an agent to Scout

Start with the hosted browser connector, then add the extension or specialized connectors when your workflow needs real-browser state, local runtime access, Figma, or payment tools.

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

See our Privacy Policy and Terms of Service for details.