This server is a web data source discovery tool for AI, providing a suite of MCP tools to capture, inspect, and export network requests, DOM structures, and embedded data from web pages, enabling reverse engineering of APIs and page structures without being a full crawler.
Browser Navigation & Session Management: Open/close browser, navigate to URLs, manage multiple tabs (list, switch, close), and wait for manual logins by monitoring cookie changes.
Page Observation: Fetch full page text with auto-scroll, take screenshots (viewport or full page), get DOM tree, search DOM for elements, locate interactive elements and containers, view cookies, and execute console commands.
Interaction: Chain actions like text input, scroll, click, and select to trigger requests and capture data; detect login completion via cookie changes.
Data Discovery: List all captured APIs and embedded data, inspect full request/response details, search across network data and scripts by keyword, and locate field paths with sampled values.
Script Analysis: List and search JavaScript files, view source code, trace values through code, and set non-intrusive breakpoints/watchpoints to capture variable states without pausing.
Export & Replay: Export captured data in compact/raw JSON formats, replay HTTP requests with automatic cookie sync, and perform one-shot API discovery with scout_peek.
Comprehensive Scanning: Full page scan (APIs + SSR embedded JSON + recurring DOM structures) or keyword-targeted DOM scanning.
Enables AI agents to discover and capture API endpoints from Xiaohongshu, providing tools to inspect requests, responses, and extract structured data from the platform.
Click on "Deploy 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., "@web-scout Open xiaohongshu.com explore page and list APIs"
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）服务器：在网页上做数据源发现 —— 捕获网络请求、提取内嵌数据、分析脚本，并通过交互与监测点跟踪数据流向。
网络数据源：页面发出的全部请求与响应，按接口归并并给出字段结构
内嵌数据：<script> 标签里的 JSON 与 window 全局变量
脚本分析：列出与搜索已加载脚本、读取源码、追踪一个值出现在哪些位置
交互：点击、输入、选择、滚动，按可见文本或 css=、//（XPath）选择器定位
监测点：请求监测（匹配到指定模式即记录）与 JS 断点监测（命中时抓取作用域变量快照）
文档结构：DOM 树快照、关键词定位、按路径定位，全部在服务端内存中完成
工具链：一次调用顺序执行多个工具（支持等待与重复），并为每个动作给出因果差分
页面事实：地址、标题、正文长度、关键词命中的原文片段、可见与隐藏的组件
下载：发生下载时在消息中给出文件名、保存路径、状态与大小
服务端留存：结果留在服务端，返回压缩摘要，明细随时按需获取
Related MCP server: mcp-network-analyzer
Python 3.10 及以上
Chrome 或 Edge（默认以有窗口模式启动，并使用持久化配置目录保留登录状态）
一次性运行（无需安装，推荐）：
{
"mcpServers": {
"veddata": {
"command": "uvx",
"args": ["veddata", "--response-dir", "E:\\path\\to\\out"]
}
}
}或先安装再使用：uv tool install veddata（或 pip install veddata），然后
{
"mcpServers": {
"veddata": {
"command": "veddata",
"args": ["--response-dir", "E:\\path\\to\\out"]
}
}
}从源码运行（开发用）：
uv venv
uv pip install -e ".[dev]"客户端配置（标准输入输出）：
{
"mcpServers": {
"veddata": {
"command": "E:\\path\\to\\veddata\\.venv\\Scripts\\python.exe",
"args": ["-m", "veddata.server",
"--profile-dir", "E:\\path\\to\\profile",
"--response-dir", "E:\\path\\to\\out"]
}
}
}参数 | 说明 |
| 浏览器配置目录（持久化，保留登录状态）。默认 |
|
|
环境变量 | 说明 |
| 无窗口模式（默认为有窗口） |
| 指定浏览器可执行文件（填 |
| 接管已在运行的浏览器（调试协议地址），而不是自行启动 |
ved_open — 启动会话（自行启动一个普通 Chrome 并通过调试协议接管）
ved_status — 当前页面事实、标签页清单、已捕获条数、状态账本
ved_tabs、ved_tab_switch、ved_tab_close — 标签页清单、切换、关闭
ved_close — 关闭浏览器并清空捕获数据
ved_goto — 导航，返回文档结构、数据源预览与页面事实
ved_fetch — 取当前页正文（分页）
ved_dom_tree、ved_dom_search、ved_dom_locate — 树快照、关键词、路径
ved_console — 执行 JS 或读取控制台消息
ved_cookies、ved_screenshot — cookie 与截图落盘
ved_act — input、click、select、scroll；可单步或链式；target 支持可见文本、css= 或 //
ved_apis、ved_inspect — 捕获清单与单条详情（请求头、响应体、字段结构）
ved_export、ved_export_all — 导出到磁盘（原始或精简）
ved_peek — 打开网址并直接返回数据源清单
ved_request — 重放已捕获的接口或发送自定义请求（自动带上 cookie）
ved_search、ved_context、ved_trace_value — 跨网络、内嵌、脚本、全局变量的搜索与追踪
ved_list_scripts、ved_search_scripts、ved_script_source — 清单、搜索、源码
ved_watch — 注册、列表、收集、删除；分为请求与 JS 两类；命中快照留在服务端
ved_scan — 一次性汇总网络、文档结构与内嵌数据
ved_chain — 顺序执行多个工具；等待支持毫秒、网络命中、网络静默、元素可见性；重复块支持一层
只陈述事实：输出说明有什么，不含判断与下一步提示；页面状态以地址、标题、正文长度、关键词命中片段、可见组件等事实呈现。
结果留在服务端：返回压缩摘要与分页页脚，明细用 ved_apis、ved_inspect、ved_watch(collect) 等按需获取。
状态观测：发生在工具之外的变化（页面自行跳转、标签页增删）之后，依赖活状态的工具会返回一条事实说明而不执行；ved_status、ved_tabs 会重新建立观测。
人机协作：界面可见，登录或验证由用户在窗口中完成；工具照实报告当前页面事实。
浏览器生命周期：自行启动的浏览器由 ved_close 关闭；通过 BROWSER_ADDRESS 接管的仅断开连接。
以 svgrepo 为例（该站点没有公开接口文档，AI 只能自己侦察）。一条工具链跑完：
[
{"tool": "ved_open"},
{"tool": "ved_goto", "args": {"url": "https://www.svgrepo.com/vectors/arrow/"}},
{"tool": "ved_goto", "args": {"url": "https://www.svgrepo.com/svg/535197/arrow-u-up-left"}},
{"tool": "ved_act", "args": {"action": "click", "target": "css=a[href*='/download/']"}}
]消息里直接给出事实（动作、因果、落盘位置）：
[click] Clicked 'css=a[href*='/download/']' → +1 new APIs
GET https://www.svgrepo.com/_next/data/XJiZPe18H5paekHV…/tools.json
download: arrow-u-up-left-svgrepo-com.svg → E:\Downloads\arrow-u-up-left-svgrepo-com.svg (completed, 399 B)pytest tests -q
python scripts/smoke.pyMIT License，详见 LICENSE。
本项目仅用于学习、研究、技术交流与合法合规的自动化测试，不得用于任何违法、侵权或违背公序良俗的用途。使用前请完整阅读本声明；下载、安装、运行或以任何方式使用本项目，即视为已阅读、理解并同意本声明的全部内容。如不同意，请立即停止使用并删除本项目。
合规责任由使用者自负。使用者应自行确认并遵守：目标网站的服务条款、robots.txt 与使用规则；所在国家或地区的法律法规（包括但不限于网络安全、数据安全、个人信息保护、著作权、反不正当竞争、计算机信息系统相关法律）；以及任何适用的行业规范与合同约定。
禁止用途。不得用于：未经授权访问、干扰或破坏他人系统与数据；绕过技术保护措施或访问控制；大规模抓取、囤积或转售他人数据；侵犯他人知识产权、商业秘密或个人隐私；任何形式的欺诈、骚扰、垃圾信息或其他恶意行为。
风险自担。使用本项目可能导致账号被封禁、访问受限、服务中断、数据丢失或其他损失，上述风险与后果由使用者自行承担。
无担保。本项目按「原样」（AS IS）提供，作者不对其适用性、可靠性、准确性、安全性或不侵权作出任何明示或默示的担保，也不承诺任何功能可用、持续可用或不会被目标站点检测。
责任限制。在适用法律允许的最大范围内，作者与贡献者不对因使用或无法使用本项目而产生的任何直接、间接、附带、特殊、惩罚性或后果性损害（包括但不限于利润损失、数据丢失、业务中断、第三方索赔、行政处罚或法律责任）承担任何责任。
不构成法律意见。本项目不提供任何法律意见或合规承诺；涉及合规判断请咨询专业律师。
对第三方的主张由使用者承担。因使用者的行为引发的任何第三方主张、争议、投诉或索赔，由使用者自行处理并承担全部责任，与作者及贡献者无关。
权利保留。作者保留随时修改、暂停或终止本项目的权利，且无需事先通知；本声明亦可随时更新，更新后的版本自发布之日起生效。
Execute actions on the page: input, scroll, click, or select.
Two modes:
Single step: scout_act("scroll", "bottom") scout_act("input", "python教程", target="搜索") scout_act("click", target="下一页") scout_act("select", "最多播放", target="综合排序")
Chain: scout_act(actions=[ {"action": "input", "value": "python教程", "target": "搜索"}, {"action": "scroll", "value": "bottom"}, {"action": "click", "target": "最多播放"}, ])
Each step reports new API method + path inline so AI sees them immediately.
| Name | Required | Description | Default |
|---|---|---|---|
| value | No | Text input or scroll target (bottom/top/down/up/px). | |
| action | No | "input", "scroll", "click", or "select" (single mode). | |
| target | No | Visible text of the target element. | |
| actions | No | List of action dicts for chain mode. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that each step reports new API method and path inline, but does not detail side effects like page navigation or state changes.
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 moderately sized but includes verbose examples. The core purpose is front-loaded, but the examples could be more compact.
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 (4 parameters, no required, with output schema), the description adequately covers both usage modes and the chain pattern. Output schema exists so return values need not be described.
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 100%, so the schema already documents parameters. The description adds value by showing parameter relationships across modes (e.g., 'value' varies by action) and providing concrete usage examples.
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 actions (input, scroll, click, select) and provides examples. It distinguishes from siblings by focusing on interactive page actions, though it does not explicitly compare to 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 explains two modes (single step and chain) with examples, implying when to use each. However, it lacks explicit guidance on when not to use the tool or alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all captured API endpoints, optionally filtered by keyword.
| Name | Required | Description | Default |
|---|---|---|---|
| tab | No | CDP short ID (empty = current active tab). | |
| keyword | No | Optional filter — only show APIs whose path or response body contains this keyword (case-insensitive). |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the basic listing and filtering behavior, but omits details about scope (tab), side effects (none), or whether the operation is read-only. As no annotations exist, more transparency would be beneficial.
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?
A single, succinct sentence that front-loads the verb and resource. 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?
For a simple listing tool with 2 parameters and an output schema, the description is adequate but lacks mention of the tab scoping behavior, which is important for correct invocation.
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 100%, so the description adds minimal value beyond the schema. It restates the keyword filter but does not clarify the tab parameter's role in scoping.
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 'List' and the resource 'captured API endpoints', with an optional keyword filter. It distinguishes from sibling tools that perform different actions (e.g., scout_act, scout_close).
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 guidance is given on when to use this tool versus alternatives. Sibling tools have varied purposes, but the description does not explicitly differentiate or provide use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Close the browser and clear all captured data.
Kills the Chromium process on port 9222 and resets all state.
Returns: Status message.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes destructive action (kills process, resets state) and return value. No annotations provided, so description carries burden. Could mention impact on other tools or data loss risk.
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?
Extremely concise with two short sentences. 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 params and simple action, description is complete. Output schema provides return info.
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?
No parameters, schema coverage 100%. Baseline 4 for zero-parameter tool.
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 'Close the browser and clear all captured data' and specifies killing Chromium process. Distinguishes from siblings like scout_tab_close which closes a single tab.
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 vs alternatives (e.g., scout_tab_close). Purpose is clear but lacks when-not or contextual hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search all data sources for keyword, returning field paths and values.
| Name | Required | Description | Default |
|---|---|---|---|
| tab | No | CDP short ID (empty = current active tab). | |
| keyword | Yes | Search term, or comma-separated terms for OR logic. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavior. It states a read operation but does not mention any side effects, permissions, rate limits, or performance implications. Minimal disclosure.
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 a single sentence of 12 words, very concise and front-loaded. However, it could include more detail without becoming verbose.
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?
Despite having an output schema and full parameter coverage, the description omits high-level context such as result format, pagination, or behavior when no results are found. Incomplete for a tool that searches all data sources.
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 100%, so both parameters are already described in the input schema. The description adds no new meaning beyond the schema, achieving the baseline.
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 'Search' and the resource 'all data sources', and specifies the output 'returning field paths and values'. However, it does not distinguish from sibling tools like scout_search, which may have a similar purpose.
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 guidance is provided on when to use this tool versus alternatives such as scout_search. The description lacks context about the tool's scope and prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
View cookies for the current page.
| Name | Required | Description | Default |
|---|---|---|---|
| tab | No | CDP short ID (empty = current active tab). | |
| all_info | No | False = name/value/domain only, True = include path/httpOnly/secure/expires. | |
| all_domains | No | False = current domain only, True = all domains. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It merely states 'View cookies,' implying a read operation, but does not confirm that it is non-destructive, what permissions are needed, or whether it modifies browser state. No side effects or limitations are mentioned.
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 a single, front-loaded sentence with no wasted words. It efficiently conveys the basic purpose. However, it could include more detail without being verbose, such as parameter effects or usage context.
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 three parameters and an output schema, the description is too minimal. It does not explain the output schema nature, parameter interactions, or typical use scenarios. Even though output schema exists, the description should provide more context to help the agent select and invoke the tool 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?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond what the schema already provides for parameters. Each parameter (tab, all_info, all_domains) is documented in the schema, and the description does not enhance their semantics.
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 'View' and the resource 'cookies' with a scope of 'the current page.' This purpose is distinct from sibling tools like scout_act or scout_fetch. However, the parameters allow viewing cookies from other domains and including additional info, which is not reflected in the description, making it slightly narrow.
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 guidance is provided on when to use this tool versus alternatives, such as other scout tools. There are no prerequisites, conditions, or examples of appropriate use cases. The agent must infer usage solely from the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List interactive page elements, repeated DOM containers, and common actions.
Scans for clickable buttons, links, inputs and detects repeated container structures (card layouts, list items, etc.).
Returns: Numbered list of interactive elements + DOM containers + Common Actions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool scans for and returns interactive elements and DOM containers, implying it's a read-only operation. However, it does not explicitly state there are no side effects, no mutations, or any other behavioral traits (e.g., performance impact, restrictions). The description is adequate but not exhaustive.
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 relatively concise, using three lines to convey purpose and output. It front-loads the main action ('List interactive page elements...') and provides details. Some redundancy exists (e.g., 'repeated DOM containers' appears twice), but overall it's efficient and well-structured.
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 the tool has no parameters and an output schema exists, the description provides sufficient context about what it does and what it returns. It mentions the type of output (numbered list) and the categories (interactive elements, DOM containers, common actions). For a simple zero-param tool, this is adequate.
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, and the schema coverage is 100% (trivially). The description adds context about what the tool returns (numbered list of elements, containers, actions), which helps the agent understand the output even though parameters are absent. According to guidelines, 0 parameters yields a baseline of 4, and the description meets 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 it lists interactive page elements, DOM containers, and common actions. It uses specific terms like 'clickable buttons, links, inputs' and 'card layouts, list items', making the purpose clear. However, it does not explicitly differentiate from sibling tools like scout_inspect or scout_scan, which might also involve analyzing 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 implies usage when you need to discover page elements, but provides no explicit guidance on when to use this tool versus alternatives (e.g., scout_inspect for individual element details or scout_scan for accessibility). No when-not or condition-based advice is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export one or more captured API data sources.
| Name | Required | Description | Default |
|---|---|---|---|
| tab | No | CDP short ID (empty = current active tab). | |
| index | No | API ID (from scout_apis output). Use 0 when using indices. | |
| format | No | "raw" | "compact" | "both" (default "both"). | both |
| indices | No | Comma-separated API IDs (e.g. "2,4"). Overrides index. | |
| output_dir | No | Override save directory. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It only says 'Export' without disclosing what happens (e.g., file output, side effects, authorization needs). Missing behavioral traits like where output goes or if it modifies 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?
Single sentence, no wasted words. However, it is arguably under-specified for a tool with 5 parameters and output schema, but still 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 complexity (5 parameters, output schema, many siblings), the description is incomplete. It does not explain the export process, how parameters interact, or what the output schema represents.
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 100%, with detailed parameter descriptions. The tool description adds no value beyond the schema, but the baseline is 3 since the schema is complete.
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 'Export one or more captured API data sources' clearly states the verb and resource, distinguishing it from sibling scout_export_all (which exports all). However, it could be more explicit about the scope and context.
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 guidance on when to use this tool versus alternatives like scout_export_all or scout_apis. The description lacks any context about prerequisites or scenario fit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export all captured API data sources at once.
| Name | Required | Description | Default |
|---|---|---|---|
| tab | No | CDP short ID (empty = current active tab). | |
| format | No | "raw" | "compact" | "both" (default "both"). | both |
| output_dir | No | Override save directory. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It only says 'export all... at once' but omits details like authentication needs, output behavior, overwrite rules, or file structure. Minimal disclosure.
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 a single efficient sentence with no wasted words. While slightly more context could be added, it is appropriately sized for a simple tool.
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 basic purpose but lacks behavioral context and usage nuances. With no annotations and a simple tool, it is adequate but has gaps for an agent to fully understand implications.
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 100%, so the schema already describes all parameters (tab, format, output_dir). The tool description adds no additional meaning beyond the schema, earning a baseline 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 exports all captured API data sources at once, with a specific verb and resource. It distinguishes from sibling tools like scout_export, which likely exports a single item.
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 no guidance on when to use this tool versus alternatives like scout_export, nor any prerequisites or exclusions. A single sentence without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch full page content — scrolls to bottom, dumps innerText + AXTree links, writes to cache file, returns chunked segments.
First call scrolls to bottom and writes a JSON cache file. Subsequent calls with start_index read from cache (no re-scroll).
| Name | Required | Description | Default |
|---|---|---|---|
| tab | No | CDP short ID (empty = current active tab). | |
| max_length | No | Characters per chunk (default 5000). | |
| start_index | No | Start position (default 0). |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses behavior: scrolling, dumping innerText and AXTree links, writing to a cache file, returning chunked segments, and the caching lifecycle. This gives the agent full understanding of side effects and 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 two sentences with a line break. It is front-loaded with the main purpose and every sentence provides essential information. 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?
The description covers all necessary aspects: what it does, how it behaves on first vs subsequent calls, what parameters affect behavior, and output format. Given the complexity (caching, chunking, scrolling) and presence of an output schema, it is 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 100% with each parameter described. The description adds meaningful context beyond schema by explaining how start_index interacts with caching ('subsequent calls with start_index read from cache'), which is not in the schema. This adds value.
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 action: 'fetch full page content' with specific details (scroll to bottom, dump innerText + AXTree links, write cache, return chunks). It distinguishes itself from 20 sibling tools by clearly being the one for fetching content.
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 clear usage guidance: first call scrolls and writes cache, subsequent calls with start_index read from cache. This tells the agent when to use the tool and how the caching works. It lacks explicit when-not-to-use comparisons to alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Navigate to a URL and capture API requests.
Starts network monitoring BEFORE navigating (required: listen.start() must precede any action that triggers requests). Returns page text and interactive elements.
Use new_tab=True to open in a new tab while keeping the current page.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Target URL to navigate to. | |
| new_tab | No | True = create new tab; False = navigate current tab. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description covers behavioral traits: it navigates, captures API requests, returns page text/elements, and requires network monitoring before navigation. Doesn't disclose side effects like closure or auth, but adequate for a navigation tool.
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?
Three sentences, front-loaded with action, no fluff. Efficiently conveys core behavior, prerequisite, and an option.
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 full schema coverage and existence of output schema, description covers the key points: navigation, API capture, return type, and an important option. Lacks detail on output structure, but output schema presumably handles that.
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 already describes both parameters (100% coverage). Description adds context for new_tab ('use to open a new tab while keeping current page'), which is valuable but not extensive. No additional meaning for url beyond 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?
Clearly states it navigates to a URL and captures API requests, returning page text and interactive elements. Distinguishes from siblings like scout_fetch and scout_act, but does not explicitly differentiate from scout_scan or scout_inspect.
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 a prerequisite (listen.start() must precede) and explains new_tab behavior, but lacks guidance on when to use versus alternatives like scout_apis or scout_request.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show full request and response details for one or more APIs.
| Name | Required | Description | Default |
|---|---|---|---|
| tab | No | CDP short ID (empty = current active tab). | |
| index | No | API ID (from scout_apis output). Use 0 when using indices. | |
| detail | No | "preview" (default) or "full". | preview |
| indices | No | Comma-separated API IDs (e.g. "1,3,5"). Overrides index. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states 'Show full request and response details', which implies a read operation but does not confirm it's safe or idempotent. It fails to mention required permissions, side effects, or limitations. This is insufficient for a tool that might interact with network resources.
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 a single, front-loaded sentence with no unnecessary words. It efficiently conveys 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?
Despite having an output schema (reducing need to describe returns), the tool operates in a context with 20+ sibling tools. The description does not explain where this fits in a typical workflow (e.g., after scout_apis to get IDs). It is too brief to be fully self-contained.
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?
Input schema has 100% coverage with descriptions for all 4 parameters. The tool description does not add additional meaning beyond what the schema already provides. Baseline of 3 is appropriate since schema does the heavy lifting.
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 'Show full request and response details for one or more APIs' uses a clear verb-resource combination (Show + details for APIs). It indicates the tool can handle multiple APIs, which distinguishes it from potentially similar siblings like scout_request that might focus on a single API. However, the verb 'Show' is passive and could be more dynamic.
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?
There is no guidance on when to use this tool versus alternatives like scout_request or scout_apis. The description does not mention prerequisites, context, or when not to use it. With many sibling tools, this is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wait for the user to manually log in via the browser window.
Detects login by polling cookies: if cookie names change or ≥2 values change simultaneously, login is detected. Works across all sites without site-specific logic.
| Name | Required | Description | Default |
|---|---|---|---|
| timeout | No | Maximum wait time in seconds (default 300). |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the polling logic (cookie name/value changes) and timeout, providing good behavioral transparency for a waiting tool.
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 very concise, two sentences, front-loaded with the main purpose, and 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?
Given the tool's simplicity and presence of an output schema, the description covers the main behavior well. It could mention the outcome on timeout, but overall 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 100%, so baseline is 3. The description does not add any new information about the 'timeout' parameter beyond what the schema already provides.
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 waits for manual login via browser window, using a specific verb 'wait' and resource 'login', distinguishing it from other scout tools like scout_goto or scout_cookies.
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 explains the detection mechanism (cookie polling) and that it works across sites, implying when to use. However, it does not explicitly state when not to use or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open / manage the browser session.
Finds or launches a Chromium on port 9222. Clears old tabs and resets the API pool. Does NOT navigate — use scout_goto() for that.
Returns: Browser session status.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses important behaviors: clears old tabs, resets API pool, does not navigate, and returns status. However, with no annotations, it lacks details on authentication, rate limits, or potential side effects beyond clearing tabs.
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 and well-structured: purpose first, then specific actions, then a critical contrast (not for navigation), and finally return value. No wasted 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 no annotations and an output schema (not shown), the description covers the tool's core functionality and return value. It could be slightly more explicit about being the first step in a sequence, but is otherwise 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?
Tool has zero parameters and schema coverage is 100%, so the description does not need to add parameter info. Baseline score of 4 is appropriate as the description adds context without needing to explain params.
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 the tool opens/manages a browser session, with specific actions like finding/launching Chromium and clearing tabs. It explicitly distinguishes itself from scout_goto for navigation.
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 a positive use case (opening/managing session) and a clear exclusion (not for navigation, use scout_goto). However, it does not explicitly discuss when to avoid using it relative to other sibling tools like scout_close or scout_tabs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One-shot API discovery: open a URL, capture and inspect matching API.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Target page URL. | |
| method | No | Optional HTTP method filter ("GET" or "POST"). | |
| path_contains | No | Optional API path filter (e.g. "/search/notes"). |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavioral traits. It only says 'open a URL, capture and inspect matching API,' without specifying side effects (e.g., network requests, state changes), safety, or required permissions. This is insufficient for an agent to understand the tool's impact.
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 a single sentence that conveys the core purpose concisely. It is not overly verbose, though it could be slightly more structured with bullet points or separate clauses. The front-loading is good.
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?
Despite having an output schema, the description lacks details on what 'capture and inspect matching API' entails, how filtering parameters (method, path_contains) affect the result, and what the output represents. This vagueness reduces overall completeness for a tool in a complex domain.
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?
All three parameters are documented in the schema with descriptions (100% coverage). The tool description adds the context of 'one-shot API discovery' but does not provide additional meaning beyond what the schema offers. Baseline score of 3 is appropriate.
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 action ('open a URL, capture and inspect matching API') and its purpose ('One-shot API discovery'). However, it does not differentiate from sibling tools like scout_apis, scout_scan, or scout_inspect, which likely have overlapping functionality.
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 guidance is provided on when to use scout_peek versus alternative tools. There is no mention of prerequisites, when not to use it, or typical use cases. Given the many sibling tools, this lack of direction hinders correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a test HTTP request — replay from captured API or fully custom.
Two modes:
Replay: index=3, params='{"page":2}' — uses API #3's URL/method/headers.
Manual: url="...", method="POST", body="..." — fully custom.
Cookies are auto-synced from the current browser tab.
| Name | Required | Description | Default |
|---|---|---|---|
| tab | No | CDP short ID for cookie sync (empty = current active tab). | |
| url | No | Request URL (manual mode). | |
| body | No | JSON string of request body. | |
| index | No | API record number to replay (0 = manual mode). | |
| method | No | HTTP method (default "GET"). | GET |
| params | No | JSON string of query parameters. | |
| headers | No | JSON string of extra headers. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description effectively discloses key behaviors: auto-syncing cookies from the current tab, and that replay mode uses parameters like index and params to reference captured API data. It does not cover rate limits or error handling.
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 very concise, using just two short paragraphs. It front-loads the core purpose ('Send a test HTTP request') and immediately lays out the two modes with examples. 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?
Given the tool has 7 parameters (0 required) and an output schema, the description covers the main behavior, including cookie sync. It does not detail return values (handled by output schema) or error cases, but is sufficient for typical use.
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 100%, but the description adds value by grouping parameters into modes (index+params for replay, url+method+body for manual) and providing example values. This helps agents understand parameter relationships beyond 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 sends a test HTTP request, with explicit examples for replay and manual modes. It distinguishes its functionality from siblings by specifying the two modes and cookie sync behavior.
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 explains two use cases (replay from captured API vs fully custom) and when to use each. It also mentions cookie auto-sync behavior. However, it does not explicitly exclude alternatives like scout_fetch.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Comprehensive page data source scanner with two modes.
MODE "all" — full page scan (default):
Network APIs — XHR/Fetch requests already captured by the listener
SSR Embedded JSON — window.INITIAL_STATE, NEXT_DATA, etc.
DOM Containers — repeated HTML structures (card layouts, list items)
MODE "dom" — keyword-targeted DOM scan: Searches DOM for containers matching the keyword.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | For mode "dom" — optional URL to open before scanning. | |
| mode | No | "all" for full scan, "dom" for keyword-targeted DOM scan. | all |
| keyword | No | For mode "dom" — search keyword. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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. While it describes what the tool scans in each mode, it lacks information on potential side effects, timeouts, execution context (e.g., whether JavaScript runs), or required permissions. This is 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, using bullet points to clearly delineate the two modes and their sub-components. Every sentence is informative and avoids redundancy, making it 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 the presence of an output schema (not shown but indicated), the description does not need to detail return values. It sufficiently covers the tool's two scanning modes and the role of each parameter. A minor gap is the lack of mention of pagination or error handling, but overall it is complete for the tool's 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?
The schema description coverage is 100%, and the description adds value by explaining how each parameter relates to the two modes. For example, it clarifies that 'url' is optional for mode 'dom' and 'keyword' is used for DOM search. This goes beyond the schema's basic parameter 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 as a 'comprehensive page data source scanner' with two explicit modes ('all' and 'dom'), each with a detailed breakdown of what it scans. This provides a specific verb-resource combination that distinguishes it from sibling tools like scout_apis or scout_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 explains the two modes and their purposes, giving clear context for when to use each. However, it does not explicitly state when not to use this tool or provide direct comparisons to alternatives, which would be helpful for a complete usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Take a screenshot of the current page.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Base filename (without extension). Default "screenshot". | screenshot |
| full_page | No | True = entire page, False = visible viewport. |
| 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. It fails to disclose any behavioral traits: e.g., whether it waits for page load, captures page isolated from overlays, or what the output format is.
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 at one sentence. Appropriate length for a simple tool, but could be more structured (e.g., separate into behavior and output).
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?
Despite simplicity and output schema existence, the description lacks key context: e.g., that output is a base64 image, that full_page defaults to true, or any side effects. Not complete for an agent to use effectively.
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 100%, so baseline is 3. The description adds no additional meaning beyond the schema's parameter descriptions. It does not elaborate on usage or constraints.
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 verb and resource: 'Take a screenshot of the current page.' It distinguishes from sibling tools (e.g., no other screenshot tools), though could be more precise by mentioning full-page vs viewport.
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 guidance on when to use this tool versus alternatives like scout_peek or scout_inspect. The description does not provide context for appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for data by keyword across ALL captured network data.
Supports comma-separated keywords for OR search.
| Name | Required | Description | Default |
|---|---|---|---|
| tab | No | CDP short ID (empty = current active tab). | |
| keyword | Yes | Search term, or comma-separated terms for OR logic. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It discloses comprehensive scope and OR logic, but omits behavioral traits like side effects (read-only vs. mutation), performance implications, or output format. With an output schema available, this is minimally adequate.
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 sentences efficiently conveying purpose and key feature. No wasted words; front-loaded with core verb and resource. Ideal conciseness.
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 simple search tool with two parameters and an output schema (not shown), the description covers primary functionality. It could mention case sensitivity or partial matching, but given low complexity and existing schema, it is sufficiently 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 100% with descriptions for both parameters (keyword and tab). The description's additional note about comma-separated OR search merely echoes the schema's keyword description, adding no new semantic value. Baseline 3 applies.
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?
Description clearly states 'Search for data by keyword across ALL captured network data.' The verb 'Search' and resource 'network data' are specific, and the scope 'ALL' distinguishes it from specialized sibling tools like scout_cookies or scout_apis.
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?
Implicitly clear: use for general keyword search across all data. While it doesn't explicitly state when not to use or name alternatives like scout_cookies for cookie-specific search, the context of sibling tools provides enough differentiation for a clear use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Close browser tab(s) by CDP short ID and prune their API records.
Supports comma-separated IDs for batch close (e.g. "C724404D,5FD84E84"). Empty = close current tab.
| Name | Required | Description | Default |
|---|---|---|---|
| tab | No | CDP short ID(s), comma-separated. Empty = current tab. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must carry full burden. It discloses the core behavior (close and prune records) and batch capability, but omits potential side effects (e.g., irreversible closure), error handling, or confirmation of success.
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 extremely concise with two sentences that front-load the primary action. Every sentence provides essential information 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 the tool's simplicity (one optional parameter) and presence of an output schema, the description covers the main use cases well. It could be improved by addressing edge cases like invalid IDs or empty tab state, but is largely sufficient.
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 100% with a clear description. The tool description adds value by providing examples and clarifying empty behavior, surpassing the baseline 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 action (close) and resource (browser tabs), mentions batch close via CDP short IDs, and distinguishes itself from sibling tools like scout_tab_switch or scout_tabs by focusing solely on closing.
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 operational context (supports batch close, empty for current tab) but does not explicitly guide when to use this tool vs alternatives like scout_close or scout_tab_switch, which are siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all open browser tabs with CDP short IDs.
Returns: Tab list with short IDs and current marker.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 does not disclose any behavioral traits beyond listing tabs; for example, it does not state that the operation is read-only, non-destructive, or safe to call repeatedly. The return description is brief and assumes knowledge of CDP terms.
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 extremely concise: two sentences that front-load the purpose. Every word is useful, and there is no unnecessary detail.
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 tool is simple with no parameters and an output schema exists. The description covers the basic function and return, but lacks context about CDP short IDs, the current marker, or how this tool fits into the broader tab management workflow. For a list tool with zero complexity, it 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?
There are no parameters, so schema description coverage is 100% by default. The description adds no parameter information, but baseline is 4 for zero parameters as per guidelines.
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 lists all open browser tabs with CDP short IDs, and mentions the return value includes a tab list with short IDs and current marker. This is a specific verb+resource that distinguishes from sibling tools like scout_tab_close and scout_tab_switch.
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 vs alternatives like scout_tab_switch or scout_tab_close. However, the name and purpose imply it is for listing tabs, and the agent can infer usage from the context. No when-not 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.
Switch the active tab by CDP short ID (from scout_tabs output).
After switching, scout_goto() targets the new tab.
| Name | Required | Description | Default |
|---|---|---|---|
| tab | Yes | CDP short ID (first 8 chars, from scout_tabs output). |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and adds the key behavioral detail that subsequent navigation (scout_goto) will target the new tab. It does not disclose all possible side effects, but for a simple switch operation this is sufficient.
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 sentences, front-loading the core action and then providing a critical behavioral note. No extraneous words, making it efficient and easy to parse.
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 (one parameter, clear purpose), the description fully covers what the tool does, how to use the parameter, and what happens after use. The presence of an output schema does not require explanation of return values, so completeness is high.
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 100%, so the schema already describes the 'tab' parameter as a CDP short ID. The description repeats this information but adds no extra semantic value beyond what the schema provides, meeting the baseline.
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 switches the active tab using a CDP short ID, which is distinct from sibling tools like scout_tab_close (closes) and scout_tabs (lists). The verb 'switch' and resource 'active tab' are specific and unambiguous.
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 specifies that the tab ID comes from 'scout_tabs output' and notes that after switching, 'scout_goto() targets the new tab,' providing clear context for when to use this tool. It does not explicitly state when not to use it, but the sibling list implies alternatives for other tab operations.
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.
v0.2.0scout_actscout_apisscout_closescout_contextscout_cookiesscout_elementsscout_exportscout_export_allscout_fetchscout_gotoscout_inspectscout_loginscout_openscout_peekscout_requestscout_scanscout_screenshotscout_searchscout_tab_closescout_tab_switchscout_tabsScored across 21 tools
Most tools have distinct purposes, but there is some overlap between scout_scan, scout_search, and scout_context, which all involve searching different data sources. Descriptions help differentiate but could still confuse an agent.
All tools share the 'scout_' prefix, but the naming pattern mixes verbs (e.g., scout_act, scout_fetch) and nouns (e.g., scout_apis, scout_cookies). This inconsistency, while readable, could be more uniform.
21 tools is slightly above the typical well-scoped range (3-15), but the domain of browser automation and API discovery justifies many of them. The count feels reasonable, not excessive.
The tool set covers navigation, interaction, API capture, data export, tab management, and login. Minor gaps like cookie management or local storage access exist, but core workflows are well-supported.
One MCP server over 253 data sources: Reddit, LinkedIn, YouTube, G2, search and AI answers.
One MCP server for 180+ live web-data APIs returning clean JSON from sites that block scrapers.
MCP server connecting AI agents to non-custodial staking data across 130+ networks.
All HasData scraping tools in one MCP server: Google, TikTok, Instagram, maps, e-commerce and more.
