Provides tools for retrieving 2FA codes from Twilio SMS, enabling automated OTP entry during browser automation.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@scout-mcp-server Scout the homepage of github.com"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for browser automation with anti-detection. Scout pages, find elements, interact with websites, and monitor network traffic — from any AI client that supports the Model Context Protocol.
Built on botasaurus-driver for automatic fingerprint evasion and stealth browsing. Sites that block Playwright and Selenium see a normal browser session.
Scout reads the page structure, then acts — the same way you'd inspect a page in DevTools before clicking anything:
Scout — compact structural overview (~200 tokens, not a raw DOM dump)
Find — search for elements by text, type, or selector
Act — click, type, select, navigate
Scout again — see what changed
Most browser-automation tools for AI take full-page screenshots and have the model interpret pixels. A single Playwright MCP screenshot adds ~124,000 tokens to the conversation context — and the model still has to guess at selectors from what it sees. Scout reads the DOM directly and returns a compact report (~200 tokens) with exact CSS selectors. An entire multi-step task with Scout uses fewer tokens than a single Playwright page snapshot.
Related MCP server: Scout
Real-world scenarios demonstrating Claude Code + Scout working together on live websites — checking docs, researching errors, filling forms, downloading files, and more.
fill_secret reads credentials from .env server-side and types them directly into form fields. The AI client only sees "chars_typed": 22 — never the actual value. Exported scripts use ${ENV_VAR} references. Authorization and Cookie headers are scrubbed from network logs before they reach the conversation.
get_2fa_code polls Twilio's SMS API for OTP codes — the AI clicks "Send Code" in the browser, the tool watches for the SMS, extracts the code, and types it in. Requires a Twilio account with an SMS number set as the 2FA recipient.
Scout uses Botasaurus under the hood, which handles browser fingerprinting and detection evasion automatically. Sites that block Selenium and Playwright see a normal browser session.
By default, Scout launches its own browser. Extension mode connects to your existing Chrome instead — preserving your logged-in sessions, cookies, and browser state.
launch_session(connection_mode="extension")Quick setup:
Open chrome://extensions, enable Developer mode, click "Load unpacked", select the extension/ directory from the Scout repo
Click the Scout MCP Bridge toolbar icon and toggle it Active
Call launch_session(connection_mode="extension") from your AI client
Scenario | Recommended Mode |
Sites where you're already logged in |
|
Anti-detection scraping or CI/CD |
|
Sites requiring 2FA/SSO you've already passed |
|
Parallel sessions or headless automation |
|
Extension mode sets no automation flags — your browser fingerprint stays identical to normal browsing. All 17 Scout tools work the same in both modes.
Full setup guide and troubleshooting: docs/chrome-extension.md
Scout | Playwright MCP | Chrome Extension MCP | Selenium / scripts | |
Works on sites you don't control | Yes | Limited — your own app | Limited — your active session | Blocked by detection |
Context footprint | Compact scout (~200 tokens per call) | Full screenshot (~124k tokens per call) | You provide selectors | You provide selectors |
Credential safety | Never in conversation | Plaintext in context | Plaintext in context | In your script |
Anti-detection | Built-in | None | None | None |
2FA | Built-in | No | No | You build it |
Export to script | One command | No | No | You write it |
Cross-platform scheduling | One command | No | No | You configure it |
Task | Scout context | Playwright MCP context | Reduction | Wall-clock | Success |
Fact lookup (Wikipedia) | ~1,264 tokens | ~124,000 tokens | 98% fewer | 15.8s | 3/3 |
Form fill + verify (httpbin) | ~3,799 tokens | ~124,000 tokens | 97% fewer | 52.5s | 3/3 |
Claude Opus 4.6, 3 runs each. Full results: v0.4 | v0.2 (Sonnet)
What these numbers measure: Both columns show context window footprint — how many tokens the task adds to your conversation. Playwright MCP returns a full-page accessibility snapshot in a single tool call (~124k tokens). Scout spreads the work across multiple small calls (~200 tokens each), so an entire multi-step task consumes less context than one Playwright snapshot. Less context means more room for follow-up work in the same conversation and lower per-turn API costs, since every subsequent API call re-sends the full conversation.
Wall-clock measures browser time only (session_duration_seconds from close_session). This excludes model reasoning between tool calls — add ~1–3 seconds per tool call for realistic end-to-end latency.
Prerequisites: Python 3.11+, Google Chrome
pip install scout-mcp-serverOr run without installing:
uvx scout-mcp-servernpx -y @stemado/scout-mcpYou configure Scout once. After that, your AI client starts and stops the server automatically — you never run it manually.
claude mcp add scout -- npx -y @stemado/scout-mcpRestart Claude Code. Scout's 17 tools are now available in every session.
Add to your claude_desktop_config.json:
{
"mcpServers": {
"scout": {
"command": "npx",
"args": ["-y", "@stemado/scout-mcp"],
"cwd": "C:\\Users\\YourUsername"
}
}
}Important: The
cwdfield sets the working directory for the Scout server. Without it, Claude Desktop may launch Scout from a system directory (e.g.C:\Windows\System32on Windows), causing downloads and file operations to fail with permission errors. Set it to your home directory or any folder where Scout should have write access.
In Cursor Settings > MCP Servers, add:
{
"mcpServers": {
"scout": {
"command": "npx",
"args": ["-y", "@stemado/scout-mcp"]
}
}
}Use the same JSON configuration above — it works with any MCP-compatible client.
Scout loads variables from a .env file using this search order:
Explicit env_file path passed to fill_secret
SCOUT_ENV_FILE environment variable
.env in the current working directory
Variable | Description |
| Set to |
| Twilio account SID for 2FA code retrieval |
| Twilio auth token |
| Twilio phone number receiving 2FA SMS codes |
| Override the default Chrome extension ID for Native Messaging auth (only needed for custom extension builds) |
| Override NM host manifest directory for non-Chrome browsers (Brave, Chromium, Edge) |
Credential isolation — fill_secret reads from .env server-side; passwords never enter the conversation
Header redaction — Authorization, Cookie, and API key headers scrubbed from network logs
Export scrubbing — credentials parameterized as environment variable references
URL scheme allowlist — only http and https schemes permitted; all others rejected
SSRF protection — IP addresses normalized via ipaddress module to catch IPv6-mapped IPv4 bypasses; blocks cloud metadata endpoints (AWS, GCP, Alibaba), loopback, and link-local addresses
Safe XML parsing — uses defusedxml to prevent XXE attacks when processing SpreadsheetML files
JS execution timeout — 2-minute cap on execute_javascript with graceful error response
Scheduler name validation — regex pattern prevents path traversal in task scheduler namespaces
Path traversal protection — validates all file paths
Invisible character stripping — removes zero-width Unicode that could hide prompt injection
Content boundary markers — wraps web-sourced data to distinguish data from instructions
Localhost navigation is blocked by default. Set SCOUT_ALLOW_LOCALHOST=1 to enable it for local development.
Tool | Description |
| Open a browser (headed or headless, optional proxy) or connect to an existing Chrome via extension mode |
| Check Chrome extension connection status |
| Structural page overview: iframes, shadow DOM, element counts |
| Search for elements by text, type, or CSS selector |
| Click, type, select, navigate, scroll, hover, wait |
| Type credentials from |
| Retrieve a 2FA OTP code from Twilio SMS |
| Run arbitrary JS in the page context |
| Capture the page as PNG or JPEG |
| Deep-inspect visibility, overlays, shadow DOM, ARIA |
| Convert and move downloaded files |
| Export the full session as a structured workflow log |
| Watch HTTP traffic to discover API endpoints under the UI |
| Record the browser session as MP4 |
| Close the browser and release resources |
| Create an OS-level scheduled task |
| List scheduled tasks |
| Remove a scheduled task |
Walk through a workflow conversationally, then export it as a standalone Python script:
workflows/<name>/
├── <name>.py # Standalone replay script
├── <name>.json # Portable workflow definition
├── requirements.txt
└── .env.example # Credential templateSchedule exported workflows with the schedule_create tool — works on Windows (Task Scheduler), macOS (launchd), and Linux (cron).
# Clone and install
git clone https://github.com/stemado/scout-mcp.git
cd scout
uv sync
# Run tests (no browser needed)
uv run pytest tests/ -m "not integration" -v
# Run integration tests (needs Chrome)
uv run pytest tests/ -v
# Run the MCP server locally
uv run scout-mcp-serverMIT
Fetch a web page and extract its content as clean markdown.
Lightweight alternative to the full Scout session flow. One tool call, content out. Uses HTTP by default with automatic stealth browser fallback for bot-protected pages.
Args: url: The page URL to fetch. query: Optional — extract only content relevant to this query. max_length: Optional — cap response length in characters. 0 = unlimited.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| query | No | ||
| max_length | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses HTTP default with stealth browser fallback, but does not mention rate limits, auth requirements, or handling of dynamic content. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: two lines for purpose/context, then bulleted arg descriptions. No wasted words, easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and 0% schema coverage, description covers core functionality and parameter usage. Output schema exists to handle return values, so omission of response format is acceptable. Could mention supported content types or limitations, but overall complete for a simple fetch tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but description explains all three parameters clearly: url (target), query (filter), max_length (character cap). Adds value beyond schema titles and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Fetch a web page and extract its content as clean markdown.' Differentiates itself from sibling 'scout_page_tool' by calling itself a 'Lightweight alternative to the full Scout session flow.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context for when to use (lightweight single call vs full session) and describes fallback behavior for bot-protected pages. Lacks explicit exclusions but covers key usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the status of the Scout Chrome extension connection.
Returns the extension connection status: whether the relay server is running, whether the extension is connected, and installation instructions if needed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It describes the return value but does not explicitly state that the tool is read-only or has no side effects. Mention of 'installation instructions' hints at non-modifying behavior, but it could be more transparent about safety and prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no fluff. Each sentence adds value: the first states the purpose, the second details the return information. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has zero parameters, no output schema, and no annotations, the description is fairly complete. It covers what the tool does and what it returns. However, it could mention prerequisites (e.g., the extension must be installed) or error conditions for slightly better completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to add parameter info. According to guidelines, baseline for 0 parameters is 4, which is appropriate here as the description adds no parameter semantics but doesn't need to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly and specifically states the tool checks the status of the Scout Chrome extension connection, and lists what it returns (relay server status, connection status, installation instructions). It is distinct from sibling tools which focus on browsing and automation tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. While it is implied that it should be used to verify extension connectivity before other actions, no explicit usage context or exclusions are provided. This is adequate but lacks guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Close the browser session and release all resources.
Always call this when automation exploration is complete.
Args: session_id: Session ID to close.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
States it releases all resources, implying cleanup and side effects. With no annotations, it adequately conveys the behavioral impact, though could mention irreversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise with a clear structure: action instruction, usage note, and parameter listing. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers action and usage for a simple close operation. Could add details about session persistence but is sufficient for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description merely repeats the parameter name and basic purpose from the schema. With 0% schema coverage, no additional context like format or source is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool closes the browser session and releases resources. It distinguishes from sibling tools like 'launch_session' which is the opposite action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call when automation exploration is complete, providing clear context of use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform a single interaction in the live browser session.
Supports clicking, typing, selecting, navigating, scrolling, and waiting. Always scout after executing an action to observe the result.
Args: session_id: Active session ID. action: The action to perform. selector: CSS selector of the target element. Required for click, type, select, hover, clear, upload_file. value: Text to type, option to select, URL to navigate to, key to press, wait duration, or file path to upload. frame_context: Iframe selector path for the target element. Use 'main' or omit for top-level. wait_after: Milliseconds to wait after action completes. Default: 500.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | ||
| action | Yes | ||
| selector | No | ||
| value | No | ||
| frame_context | No | ||
| wait_after | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description itself must cover behavior. It mentions 'single interaction,' scouting, and parameter roles, but does not disclose potential side effects (e.g., page navigation, state changes) or error handling. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-sentence purpose, a crucial usage tip, then a bulleted argument list. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no output schema, and no annotations, the description covers parameter usage and required conditions well. It lacks return value or error details, but for an action tool, the outcome is observable via scout. Slightly incomplete but acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description fully compensates. It explains each parameter: session_id, action enum, selector requirement, value meanings, frame_context, and wait_after default. This adds critical meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Perform a single interaction in the live browser session' and lists supported actions (click, type, select, navigate, scroll, wait, etc.), distinguishing it from sibling tools like `scout_page_tool` or `execute_javascript`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises 'Always scout after executing an action to observe the result,' providing explicit post-action guidance. It implies when to use (single interactions) but does not explicitly contrast with alternatives like `fill_secret` or `execute_javascript`.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute arbitrary JavaScript in the page context and return the result.
Use this to debug click failures, read shadow DOM content, dispatch custom events, extract data, or perform any DOM operation not covered by other tools.
Args: session_id: Active session ID. script: JavaScript code to execute. The last expression is returned as the result. Scripts with explicit 'return' statements also work for backward compatibility. frame_context: Iframe selector path for execution context. Use 'main' or omit for top-level.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | ||
| script | Yes | ||
| frame_context | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains return value behavior (last expression returned, explicit return works) and the frame_context parameter. However, it lacks disclosure about potential side effects, security risks, or error handling for arbitrary script execution.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two short paragraphs plus an Args list. It front-loads the purpose and usage, then provides parameter details. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains the return value (last expression or explicit return). It covers the key parameters and usage context. However, it could mention error handling or prerequisites like a valid session.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% coverage, so the description must compensate. The 'Args' section explains each parameter: session_id (active session ID), script (code to execute with return semantics), and frame_context (iframe selector path). This adds significant meaning beyond the schema's types and required status.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes arbitrary JavaScript in the page context and returns the result. It lists specific use cases (debug click failures, read shadow DOM, etc.) and differentiates from siblings by noting it covers operations not handled by other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: for debugging clicks, reading shadow DOM, etc., and implies it's for operations not covered by other tools. However, it does not name specific sibling alternatives or provide explicit 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Type a secret value from .env into a form field without exposing it in the conversation.
The server reads the value from the .env file and types it directly into the target element. The actual value never appears in tool parameters or responses.
Args: session_id: Active session ID. env_var: Name of the environment variable in .env (e.g., 'APP_PASSWORD'). selector: CSS selector of the target input field. frame_context: Iframe selector path for the target element. Use 'main' or omit for top-level. clear_first: Clear the field before typing. Default: true. wait_after: Milliseconds to wait after typing. Default: 500.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | ||
| env_var | Yes | ||
| selector | Yes | ||
| frame_context | No | ||
| clear_first | No | ||
| wait_after | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description reveals critical behaviors: the server reads from .env, types directly into the element, and the secret never appears in parameters or responses. This is good transparency, though it could mention potential failure modes or idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-line summary, a brief mechanism paragraph, and a bulleted parameter list. Every sentence adds value, no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given six parameters and no output schema, the description covers purpose, mechanism, and all parameters adequately. It lacks explicit mention of the return value, but the output is likely a success indicator. Still, it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does so by explaining all six parameters in the Args section, including purposes and defaults (e.g., clear_first defaults to true, wait_after defaults to 500 ms). This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: type a secret value from .env into a form field without exposing it in the conversation. It specifies the action (type), resource (form field), and the key privacy feature, distinguishing it from sibling tools like get_2fa_code.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description implies usage for securely entering secrets but does not contrast with other tools like execute_javascript or fill_form. Missing when-not criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for specific interactive elements on the current page.
Returns matching elements with selectors, text, and attributes. Call scout_page_tool first to cache the page structure, then use this tool to find specific elements by text, type, or CSS selector.
Args: session_id: Active session ID. query: Text or selector to search for (case-insensitive substring match). Matches against element text, selector, id, name, aria-label, placeholder, href. element_types: Filter by tag name, e.g. ['button', 'input', 'a']. visible_only: Only return visible elements. Default: true. frame_context: Limit search to a specific iframe (use selector from scout report). max_results: Maximum elements to return. Default: 25.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | ||
| query | No | ||
| element_types | No | ||
| visible_only | No | ||
| frame_context | No | ||
| max_results | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the tool's behavior (search, return matching elements) and parameter details, but does not mention idempotence, performance implications, or lack of side effects. Without annotations, more transparency is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with a concise intro paragraph followed by parameter descriptions. Some redundancy (e.g., 'Args' section could be more list-like), but overall efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers prerequisite, all parameters with details and defaults, and briefly describes return values. Despite no output schema, the description is sufficient for a tool with 6 parameters and moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description fully compensates by explaining all 6 parameters: session_id required, query (case-insensitive substring match), element_types filter, visible_only default true, frame_context, max_results default 25. Adds meaning beyond types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search for specific interactive elements on the current page' and lists returned data (selectors, text, attributes). It is specific and distinct from siblings like scout_page_tool and inspect_element_tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to 'Call scout_page_tool first to cache the page structure, then use this tool to find specific elements', providing clear prerequisite context. However, it lacks explicit 'when not to use' or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a 2FA OTP code from Twilio SMS — call this AFTER clicking 'Send Code'.
Polls the Twilio Messages API until a new SMS matching app_keyword arrives, then extracts and returns the OTP code. Twilio credentials are read from .env and never exposed in tool responses.
Call this tool AFTER triggering the 2FA send in the browser. The baseline inbox state is captured at call time; Twilio delivery latency (2-10s) gives sufficient buffer before the first poll.
Args: app_keyword: Case-insensitive keyword to match in the SMS body. Use the site name, e.g. 'paycom', 'chase', 'google'. code_pattern: Regex to extract the OTP. Default: 6-digit number. Override for 8-digit or alphanumeric codes. timeout: Seconds to wait for the code before giving up. Default: 60.
Required .env entries: TWILIO_ACCOUNT_SID — Twilio Account SID TWILIO_AUTH_TOKEN — Twilio Auth Token TWILIO_PHONE_NUMBER — Digits-only recipient number (e.g. 14155551234)
| Name | Required | Description | Default |
|---|---|---|---|
| app_keyword | Yes | ||
| code_pattern | No | \d{6} | |
| timeout | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavior: it polls Twilio API, extracts the code, does not expose credentials, and explains timeout and baseline state. This is comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a bold lead sentence, clear sections, and no fluff. Every sentence adds value, and the length is appropriate for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool complexity (polling, Twilio, regex), the description is complete. It covers purpose, parameters, prerequisites, behavior, and return. Output schema exists but description still explains extraction. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description fully compensates. It explains 'app_keyword' with examples, 'code_pattern' with default and override, 'timeout' with default, and includes required .env entries. Adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Fetch', the resource '2FA OTP code', and the context 'AFTER clicking Send Code'. It is specific and distinguishes from any sibling tools, none of which handle 2FA.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to call the tool ('AFTER triggering the 2FA send') and explains the polling behavior with Twilio latency. It lacks a 'when not to use' statement or explicit alternatives, but given the specialization, this is minor.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return recent security events from the Scout security log.
Useful for auditing a session before exporting a workflow — if a session had injection attempts, that should inform whether the workflow is trustworthy.
Args: session_id: Filter to events from this session only. severity: Filter by severity level: 'info', 'warning', or 'critical'. limit: Maximum number of events to return. Default: 50.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | No | ||
| severity | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that the tool returns events but does not mention whether it is read-only, any side effects, authentication requirements, rate limits, or data freshness. The description is minimal and lacks transparency into the tool's behavior beyond the basic return.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: three short sentences plus a structured 'Args' section. Every sentence adds value (purpose, usage guidance, parameter details). There is no redundant or extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema, the description should describe the return value format or structure. It only says 'Return recent security events' without specifying what fields or structure each event has. For a simple tool, this is adequate but not fully complete. The parameter documentation is good, but the return type is underspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, meaning none of the parameters have descriptions in the schema itself. The tool's description compensates fully by documenting all three parameters (session_id, severity, limit) with their semantics, valid values, and defaults. This provides essential meaning that the schema alone does not convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns recent security events from the Scout security log, which is a specific verb and resource. It also provides a concrete use case (auditing sessions before workflow export), distinguishing it from sibling tools like 'get_session_history' which likely return different data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance on when to use the tool: for auditing a session before exporting a workflow, especially if there are injection attempts. This tells the agent the context of use. However, it does not indicate when not to use it or mention alternative tools, so it is not a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the complete structured history of a browser session.
Includes every action taken, every scout report (summarized), every network event captured, and the sequence of URLs visited. Use this data to compose botasaurus-driver scripts.
Args: session_id: Session ID (active or recently closed).
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must cover behavioral traits. It describes the output contents in detail but does not disclose whether the tool is read-only, requires authentication, or has side effects. The name implies retrieval, but explicit behavioral traits are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences plus a minimal args line. Front-loaded with purpose; every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one required parameter and no output schema, the description adequately explains the output contents. It could hint at the data format (e.g., JSON), but the listed contents provide enough context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but the description adds meaning: 'Session ID (active or recently closed).' This clarifies the parameter's scope beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Return' with a clear resource 'complete structured history of a browser session.' It lists detailed contents (actions, scout reports, network events, URLs), distinguishing it from sibling tools like close_session or launch_session.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
States a specific use case: 'Use this data to compose botasaurus-driver scripts.' However, it does not mention when to avoid using this tool or provide alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect a single DOM element in detail — visibility, position, shadow DOM, overlays, and more.
Use this to diagnose why a click didn't work, check if an element is obscured by an overlay, verify shadow DOM context, or examine element state before interacting.
Args: session_id: Active session ID. selector: CSS selector of the element to inspect. frame_context: Iframe selector path. Use 'main' or omit for top-level. include_listeners: Detect inline event handlers (onclick, etc.). Default: false. include_children: Include child element summary. Default: true.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | ||
| selector | Yes | ||
| frame_context | No | ||
| include_listeners | No | ||
| include_children | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must describe behavior. It mentions inspecting visibility, position, shadow DOM, overlays, etc., implying a read-only diagnostic tool, but it does not explicitly state that the tool does not modify the page or have side effects. The description is adequate but could be more transparent about safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two short paragraphs plus a list of parameters. The purpose is front-loaded ('Inspect a single DOM element in detail'), and every sentence adds value. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should hint at return values, but it does not mention what the tool returns (e.g., JSON with element properties). Also, it lacks details on error handling or performance. However, the main use cases and parameters are covered, making it mostly complete for the tool's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description explains all 5 parameters with concise semantics. For example, frame_context: 'Use 'main' or omit for top-level', and defaults for include_listeners and include_children are noted. This helps the AI agent understand parameter usage, though more detail on what include_children returns would improve it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Inspect' and the resource 'DOM element', and specifies the scope 'visibility, position, shadow DOM, overlays, and more'. It differentiates from sibling tools like 'find_elements' and 'scout_page_tool' by focusing on single element detailed inspection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit scenarios: 'diagnose why a click didn't work', 'check if an element is obscured by an overlay', 'verify shadow DOM context', or 'examine element state before interacting'. This gives clear usage guidance without needing to name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Launch a new browser session via Botasaurus with anti-detection enabled.
The browser stays alive across all subsequent tool calls until close_session is called. Optionally navigate to an initial URL.
Args:
url: Initial URL to navigate to after launch. If omitted, opens a blank page.
headless: Run browser in headless mode. Default: false (headed, for observation).
profile: Optional Chrome profile for session persistence.
A bare name (e.g., 'work-portal') creates a Scout-managed profile
at /.scout/profiles// that persists cookies, localStorage,
and all browser state across sessions.
An absolute path (e.g., 'C:\Users...\User Data') uses an
existing Chrome profile directory directly.
If omitted, a temporary profile is used and deleted on close.
proxy: Optional proxy URL (e.g., 'http://user:pass@host:port').
WARNING: Using a proxy triggers botasaurus-driver's proxy authentication
subsystem, which imports javascript-fixes — a package that runs
'npm install' at import time without a lockfile. Only use proxy in
trusted environments where Node.js is installed.
download_dir: Directory for downloaded files. Default: '/.scout/downloads'.
Relative paths are resolved from the server's working directory.
connection_mode: How to connect to Chrome. 'launch' (default) starts a new
browser instance. 'extension' connects to your existing
Chrome via the Scout extension, preserving logged-in sessions.
allowed_domains: Optional list of domains allowed for fill_secret credential
typing and cross-origin navigation (extension mode).
Example: ['example.com', 'login.example.com'].
If omitted, fill_secret works on any domain (with a warning).
allow_localhost_port: Optional port number (1-65535) to allow localhost/loopback
navigation on. Example: 3000 permits http://localhost:3000 only.
If omitted, localhost is blocked. The SCOUT_ALLOW_LOCALHOST env var
overrides this to allow all ports.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | ||
| headless | No | ||
| profile | No | ||
| proxy | No | ||
| download_dir | No | ||
| connection_mode | No | launch | |
| allowed_domains | No | ||
| allow_localhost_port | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, description fully discloses persistence, anti-detection, profile lifetimes, proxy npm install caveat, allowed_domains scope, and localhost blocking.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Structured with sections and bullet points, but verbose; could be slightly trimmed without losing key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive for a launch tool with 8 parameters and no output schema; covers lifecycle, security, and parameter interactions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, each of the 8 parameters is documented with defaults, valid formats, side effects (e.g., profile persistence, proxy warning), and usage context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool launches a browser session with anti-detection, and the sibling context includes close_session and browse, making its role distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states session persists until close_session, and provides guidance on connection modes and proxy risks. Lacks explicit when-to-avoid scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Control network monitoring for the current session.
Start monitoring before performing actions that trigger API calls or downloads, then query to see what was captured.
Args: session_id: Active session ID. command: start: begin capturing. stop: stop. query: return captured events. wait_for_download: block until download. url_pattern: Optional regex pattern to filter captured requests by URL. timeout_ms: For wait_for_download: maximum wait time. Default: 30000. capture_response_body: Whether to capture response bodies (adds overhead). Default: false. limit: Maximum number of events to return in a query response. Default: 100. offset: Number of matching events to skip before returning results. Default: 0.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | ||
| command | Yes | ||
| url_pattern | No | ||
| timeout_ms | No | ||
| capture_response_body | No | ||
| limit | No | ||
| offset | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full disclosure burden. It explains that 'wait_for_download' blocks, that 'capture_response_body' adds overhead, and the role of each command. However, it does not mention whether monitoring persists across page navigations or if there are side effects on session state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a two-sentence overview followed by a clear Args block. It is concise but could be slightly more structured (e.g., bullet points) for readability. No redundant sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 params, no output schema) the description covers usage context and parameter meanings well. It explains what 'query' returns ('captured events') and that 'wait_for_download' blocks, but does not detail the structure of returned events. This is adequate but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It provides thorough explanations for all 7 parameters, including defaults (e.g., timeout_ms=30000, capture_response_body=false) and functional descriptions (e.g., url_pattern as an optional regex filter). This adds significant value beyond the schema's type/title info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Control network monitoring for the current session.' It explains the four commands (start, stop, query, wait_for_download) and differentiates from sibling tools like 'scout_page_tool' and 'take_screenshot_tool' by focusing on network request capture rather than page inspection or visual capture.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Start monitoring before performing actions that trigger API calls or downloads, then query to see what was captured.' This tells the agent when to use the tool, but it does not explicitly state when not to use it or mention alternative tools for related tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Process a downloaded file: convert format, rename, and move to destination.
Call this after a download completes. Handles format conversion (e.g., SpreadsheetML 2003 XML to CSV), filename pattern application, and file delivery to a target directory.
Args: session_id: Active session ID. source_format: Source file format. Use "auto" to detect from file contents. Known formats: spreadsheetml_2003, xls_binary, xlsx, csv. target_format: Target format to convert to (e.g., "csv"). Default: "csv". target_filename: Filename pattern with tokens: {MM}, {dd}, {yyyy}, {HH}, {mm}, {suggested}. Example: "Complete Enrollments Report {MM}.{dd}.{yyyy}.csv" target_directory: Destination directory. UNC paths supported (e.g., \server\share\path). guid: Specific download GUID to process. If omitted, processes the most recent completed download.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | ||
| source_format | No | auto | |
| target_format | No | csv | |
| target_filename | No | ||
| target_directory | No | ||
| guid | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explains format conversion, filename patterns, and directory handling, but does not detail side effects like file overwrite or error handling. Still, it gives adequate behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (about 10 lines) with a clear top-level purpose, a usage instruction, and a well-organized parameter list. Every sentence adds value, and it is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers usage and parameters well, but lacks information about return values or error behavior. For a tool with no output schema, this is a minor gap. Overall, it is fairly complete given the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates fully by explaining each parameter in detail: session_id, source_format (with 'auto' and known formats), target_format, target_filename (with token examples), target_directory (UNC paths supported), and guid. This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Process a downloaded file: convert format, rename, and move to destination.' It uses specific verbs and resources, distinguishing it from sibling tools which are unrelated (e.g., browse, close_session).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Call this after a download completes,' providing clear context. It does not mention when not to use it or alternatives, but the context is sufficient for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Control video recording for the current browser session.
Records the browser screen using CDP screencast and encodes to MP4 or GIF. Requires ffmpeg for video encoding: install imageio-ffmpeg (pip install 'imageio-ffmpeg') or have ffmpeg on your system PATH. Without it, raw JPEG frames are saved instead.
Args: session_id: Active session ID. command: start: begin recording. stop: stop and encode video. status: check recording state. max_width: Maximum video width in pixels. Default: 1920. max_height: Maximum video height in pixels. Default: 1080. quality: JPEG frame quality (1-100). Default: 95. target_fps: Target frames per second (approximate). Default: 15. output_format: Output encoding format when stopping. "mp4" (default) or "gif". GIF uses palette-optimized encoding at 10fps/800px width for README-embeddable demos.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | ||
| command | Yes | ||
| max_width | No | ||
| max_height | No | ||
| quality | No | ||
| target_fps | No | ||
| output_format | No | mp4 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and does well: it explains the mechanism (CDP screencast), encoding options (MP4/GIF), fallback behavior if ffmpeg is missing, and the effect of each command. However, it omits edge cases like overlapping start/stop calls and does not describe the return value (e.g., status command output).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary line, a mechanism paragraph, and an Args list. It is appropriately sized for 7 parameters, but the prerequisites sentence could be integrated more concisely. No wasted words overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers purpose, parameters, and behavior well. It explains encoding details and defaults. However, it lacks return value descriptions for commands like 'status' and does not mention concurrency or error states, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates. Each parameter is explained with defaults and additional context (e.g., output_format details 'GIF uses palette-optimized encoding at 10fps/800px width'), adding significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Control video recording for the current browser session' with specific verb 'record' and resource 'video recording'. It distinguishes from sibling tools like take_screenshot_tool by focusing on video rather than static images, and further details the commands (start, stop, status).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the commands and mentions prerequisites (ffmpeg), but lacks explicit guidance on when to use this tool over alternatives (e.g., take_screenshot_tool). It does not provide 'when not to use' or direct comparisons, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create or update a scheduled task for an exported SCOUT workflow.
Generates a platform-appropriate run script and registers the schedule with the OS task scheduler (Windows Task Scheduler, macOS launchd, or Linux cron).
Args: name: Workflow name. Must match .py inside workflow_dir. workflow_dir: Absolute path to the workflow directory (e.g., 'D:/Projects/app/workflows/enrollment'). schedule: Frequency — one of DAILY, WEEKLY, ONCE. time: Time to run in HH:MM 24-hour format (e.g., '06:45', '14:00'). days: Comma-separated day names for WEEKLY schedules (e.g., 'MON,WED,FRI'). Required when schedule is WEEKLY.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| workflow_dir | Yes | ||
| schedule | Yes | ||
| time | Yes | ||
| days | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses key behaviors: generating platform-specific run scripts, registering with OS schedulers, and parameter formatting rules. It does not detail error conditions or side effects like overwriting, but covers the core behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement followed by an Args section. It is slightly verbose but every sentence adds value. Could be more concise, but remains effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
All 5 parameters are described with usage details. There is no output schema, so the description is adequate. It could mention success/failure behavior, but given the parameter count and complexity, it covers the necessary information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description fully bears the burden. It explains each parameter's purpose, constraints (e.g., 'weekday names for WEEKLY', 'HH:MM 24-hour format'), and required conditions (days mandatory when schedule=WEEKLY). This adds substantial meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Create or update a scheduled task for an exported SCOUT workflow.' It also describes the specific actions (generating a run script, registering with OS scheduler). This distinguishes it from siblings like schedule_delete and schedule_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides parameter constraints (e.g., days required for WEEKLY, time format) but does not explicitly guide when to use this tool versus alternatives. No when-not or comparative usage context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a scheduled task from the OS task scheduler.
Removes the task from Windows Task Scheduler, macOS launchd, or Linux cron. Does not delete the workflow files — only the schedule.
Args: name: Name of the scheduled task to delete.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral transparency. It correctly states that the tool deletes the schedule but leaves workflow files untouched. However, it omits details on required permissions, side effects, or error handling, which limits transparency for a deletion action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is remarkably concise and well-structured. It starts with a clear verb+resource statement, then breaks into specific OS support and a crucial caveat, followed by a simple parameter listing. Every sentence serves a purpose without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, no output schema, no annotations), the description covers the essential aspects: purpose, scope, and what it does not do. It lacks details on return values or error states, but for a straightforward deletion tool, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% schema description coverage for the 'name' parameter. The description's Args section adds minimal value by restating 'Name of the scheduled task to delete.' While this clarifies the parameter's purpose, it does not provide additional semantics like format, constraints, or examples, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Delete a scheduled task from the OS task scheduler.' It specifies the OS-specific schedulers (Windows Task Scheduler, macOS launchd, Linux cron) and emphasizes it does not delete workflow files, distinguishing it from related sibling tools like schedule_create and schedule_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use the tool by clarifying that it only removes the schedule, not the workflow files. Although it does not explicitly state alternatives or when not to use, the information is clear and adequate for an agent to decide based on the sibling tool names (e.g., schedule_create, schedule_list).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all SCOUT scheduled tasks on this machine.
Returns all tasks registered with the OS task scheduler (Windows Task Scheduler, macOS launchd, or Linux cron) under the SCOUT namespace.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions OS coverage (Windows, macOS, Linux) and namespace, but lacks details on return format, performance, permissions, or error conditions. Since no annotations are provided, the description should carry more behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action, and contains no extraneous words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's scope and OS support, but lacks output format details. Since there is no output schema, the description should at least hint at what a task object contains (e.g., name, trigger).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no parameters (0 params, 100% schema coverage), so baseline is 4. The description does not need to add parameter details, but it could mention that no arguments are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies 'List all SCOUT scheduled tasks on this machine', clearly stating the verb (list), resource (SCOUT scheduled tasks), and scope (on this machine). It also distinguishes from siblings schedule_create and schedule_delete by focusing on listing only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for viewing existing tasks, and siblings are for create/delete. However, it does not explicitly state when to use this tool versus alternatives, leaving it implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform deep reconnaissance on the current page state.
Returns a structural overview of the page: metadata, iframe hierarchy, shadow DOM boundaries, and element counts. Use find_elements to search for specific interactive elements by text, type, or selector.
Args: session_id: Active session ID from launch_session. focus_frame: Optional iframe CSS selector to scout instead of the full page. detail_level: 'summary' (default) returns compact overview with element counts. 'full' returns all interactive elements (large response).
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | ||
| focus_frame | No | ||
| detail_level | No | summary |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It implies a non-destructive reconnaissance operation but does not explicitly state it is read-only or safe. It explains the return type and detail levels but lacks disclosure of any side effects or permissions needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with a clear one-line summary followed by bullet points for arguments. It prioritizes the main purpose and provides necessary details without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters and no output schema, the description adequately covers the input parameters and general output (structural overview). It references a sibling tool for specific searches, making it contextually complete for an AI agent to understand when and how to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 0%, so the description adds significant value by explaining the purpose of each parameter: session_id (from launch_session), focus_frame (optional iframe CSS selector), and detail_level with two enumerated options ('summary' vs 'full') and their implications on response size.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Perform deep reconnaissance on the current page state') and clearly defines the output (structural overview with metadata, iframe hierarchy, shadow DOM boundaries, element counts). It also distinguishes from sibling 'find_elements' by directing the agent to use that tool for searching specific elements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool (for structural overview) and references the alternative 'find_elements' for specific searches. However, it does not discuss when not to use it or mention any prerequisites beyond having a valid session_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Capture a screenshot of the current page. The screenshot is always saved to disk.
By default, also returns the image inline so Claude can see it (~1,600 tokens at typical browser resolution). Set return_image=false when capturing screenshots as file artifacts that don't need visual analysis — the file_path in the JSON response is sufficient to reference or copy the file.
Args: session_id: Active session ID. format: Image format: 'png' or 'jpeg'. Default: 'png'. quality: JPEG quality (1-100). Only used when format='jpeg'. clip_x: Left coordinate of clip region (viewport pixels). clip_y: Top coordinate of clip region (viewport pixels). clip_width: Width of clip region. clip_height: Height of clip region. full_page: Capture the full scrollable page, not just viewport. Default: false. Note: pages with lazy-loaded content may still show incomplete results. return_image: Return image inline for visual inspection. Default: true. Set to false when collecting screenshots as file artifacts to save ~1,600 tokens per screenshot.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | ||
| format | No | png | |
| quality | No | ||
| clip_x | No | ||
| clip_y | No | ||
| clip_width | No | ||
| clip_height | No | ||
| full_page | No | ||
| return_image | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that screenshots are saved to disk, inline image vs file artifact, token cost (~1,600 tokens), and full_page limitation. Without annotations, this is strong transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with a concise first paragraph and detailed but organized Args list. A bit lengthy but each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers behavior, parameter details, and token trade-offs. Missing explicit return format (file_path) but given no output schema, it's fairly complete for a screenshot tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description includes an Args section explaining each parameter with defaults, usage details, and constraints, fully compensating for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool captures a screenshot of the current page. The verb 'Capture' and resource 'screenshot' are specific, and it distinguishes from siblings like record_video.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context on when to set return_image=false to save tokens, and notes full_page may be incomplete with lazy-loaded content. However, no explicit when-not-to-use or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.8.1allow_navigationbrowsecheck_extensionclose_sessionexecute_action_toolexecute_javascriptfill_secretfind_elementsget_2fa_codeget_security_logget_session_historyinspect_element_toollaunch_sessionmonitor_networkprocess_downloadrecord_videoschedule_createschedule_deleteschedule_listscout_page_tooltake_screenshot_toolEach tool has a clearly distinct purpose, from session management (launch/close) to interaction (click/type), page reconnaissance, network monitoring, downloads, video recording, scheduling, and security. No two tools overlap in function; even similar actions like browse and scout_page_tool operate in different contexts (standalone vs. session).
Most tools follow a verb_noun pattern (e.g., allow_navigation, check_extension, execute_javascript). However, a few deviate: the schedule tools use noun_verb (schedule_create), and some tools have a 'tool' suffix (execute_action_tool, inspect_element_tool) while others do not. This minor inconsistency prevents a perfect score but does not hinder readability.
With 21 tools, the server strikes an excellent balance between comprehensive capabilities and manageable scope. Each tool addresses a specific need in web automation, and the count feels well-calibrated for a tool server that handles sessions, interactions, media, scheduling, and security.
The tool surface covers the full lifecycle of web automation: session control, navigation, element interaction, JavaScript execution, page analysis, screenshots, video recording, network monitoring, download processing, 2FA, security auditing, and scheduling. There are no obvious gaps; agents can accomplish complex workflows without resorting to workarounds.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Stealth web browser for agents: search, fetch, click, download and type in persistent MCP sessions.
MCP server for Mint — AI-powered QA that runs your app in a real browser on every PR.
One MCP for the Web. Easily search, crawl, navigate, and extract websites without getting blocked.…
A paid remote MCP for AI agent browser approval MCP, built to return verdicts, receipts, usage logs,
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/stemado/scout-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
