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.tsTYPESCRIPTBuilt 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.
Streamable HTTP MCPTool Catalog + Identity + MeteringBrowser, Node, system, Figma, payment, Mastra extension pathClean session, real browser, host API, or service APIConnector 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.
01Choose 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.
02Authenticate 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.
03Call 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.
04Run 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.
“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.
“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.
“Screenshot our pricing page at 375px, 768px, and 1440px widths”
Scout resizes the viewport three times, capturing a full-page screenshot at each breakpoint.
“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.
“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.
“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.
ScoutCapability-owned connectors
Scout keeps browser, Node, system, Figma, canvas, payment, agent, extension, and orchestration tools in separate MCP servers.
OthersOne large generic tool server
ScoutRemote 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.
OthersRemote-only or extension-only
ScoutStandard 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.
OthersCustom API wrappers
ScoutPath-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.
OthersStatic shared API keys
ScoutDurable session transport
The extension uses durable session streams and explicit registration rather than assuming a server can directly reach into a user's browser.
OthersHidden 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.
SnippetTYPESCRIPTEngineering 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 catalogsSchema-backed inputs and outputsExplicit MCP server boundariesIdentity 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 pathScout access token fallbackuserId and workerId segmented at auth boundaryMetered 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 lookupRequest-scoped credit balanceBudget-aware executionBrowser 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 connectorMastra extension pathDurable session registrationDurable 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 registrationHTTP/SSE-style tail streamsExplicit cleanup boundariesRuntime 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 serversNo accidental cross-server APIPath-specific setup