This MCP server provides comprehensive Firefox-based frontend JavaScript reverse engineering capabilities (~88 tools), built on WebDriver BiDi and Firefox Remote Debugging Protocol (RDP), designed to be driven by AI agents.
Browser & Page Control
Check browser health, list/open/select/navigate pages (tabs), take screenshots, get W3C performance metrics, enable/disable JavaScript or CSP per browsing context.
Frame & Worker Management
List and select active frames (iframes) and workers (dedicated, shared, service) as interaction targets.
Script Analysis
List loaded scripts, fetch and cache source code by URL, search within a single script or across all cached scripts (string or regex).
Debugger
Set breakpoints by line/column or text search; pause, resume, step over/into/out; inspect paused callframes; evaluate expressions; inspect RDP object grips.
Hooking & Tracing
Create, inject, list, and remove function hooks capturing args, return values, stack traces, and this context; read collected samples with optional filtering.
Network & WebSocket Monitoring
List/filter network requests, fetch request/response bodies, get initiator call stacks, set/remove XHR/fetch URL breakpoints, inspect WebSocket frames, cluster frames by byte-signature heuristic.
DOM Interaction
Get a flattened DOM tree, query elements via CSS selector, find clickable elements, simulate clicks, type text, wait for elements to appear or become visible.
Console & Script Evaluation
Retrieve console log entries (with level filtering), evaluate arbitrary JavaScript in a page/realm context, monitor RDP resource types (console, network, source, document events).
Storage & Session State
Read cookies, localStorage, sessionStorage, and IndexedDB; save, restore, dump (JSON export), load (JSON import), list, and delete named session snapshots.
Stealth & Anti-Detection
Apply stealth presets (e.g., firefox-default) via BiDi preload; inject stealth hooks with Function.prototype.toString spoofing and Proxy-based channel sampling; push stealth into worker realms; override User-Agent; inject arbitrary preload scripts. Leverages Camoufox's C++-level anti-fingerprinting.
AST, LLM & Crypto Analysis
Deobfuscate JavaScript using local AST transforms (constant folding, string array decryption, dead-code removal); use an LLM to explain or summarize code; detect cryptographic algorithm signatures (AES, RC4, MD5, SHA, Base64, HMAC, RSA, SM-series); compute a weighted risk score across cached scripts (crypto, exfil, fingerprint, storage writes, dynamic eval).
Rebuild, Evidence & Reporting
Export rebuild bundles (scripts + hook/network samples + env probes) to disk; record reverse-engineering evidence to a JSONL evidence chain; export Markdown session reports; diff keyed collections (scripts, requests, hooks) for change detection.
Provides tools for front-end JavaScript reverse engineering on Firefox (Camoufox) via WebDriver BiDi and Firefox Remote Debugging Protocol, enabling debugging, hooking, DOM manipulation, network interception, stealth features, and more.
Integrates OpenAI's API to provide LLM-powered tools for code deobfuscation, summarization, understanding, and encryption rule identification.
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., "@camoufox-jsreverser-mcp deobfuscate the login script"
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.
面向 Firefox 的前端 JavaScript 逆向工程 MCP 服务器，底层走 WebDriver BiDi 与 Firefox Remote Debugging Protocol (RDP)。
对外暴露约 88 个 MCP 工具，覆盖：
页面状态、Frame、导航、截图
脚本：列出 / 取源码 / 跨脚本搜索 / 单脚本检索
调试器：行/列断点与文本断点、暂停 / 恢复 / 步入步过步出、callframe 求值、对象 inspect
Hook：函数 hook、trace、采样通道、任意 preload 注入
网络与 WebSocket：请求池、initiator 调用栈、帧捕获、XHR 断点
DOM：query / 结构 / 点击 / 输入 / 等待元素
Storage 以及会话级 save / load / dump / restore
Stealth：firefox-default preset、跨 realm 的 inject_stealth_hook、worker 推送
AST 与 LLM：反混淆、摘要、理解、加密规则识别
Rebuild + 证据链：bundle 构建、环境差异、证据写入、报告导出
Worker、per-context preference（set_javascript_enabled / set_csp_enabled）
工具集中大约 80%（调试器 / 脚本 / DOM / 网络 / Hook / AST / LLM）与浏览器二进制无关——它走 WebDriver BiDi 和 Firefox RDP，这两个协议原版 Firefox 150 同样支持。那为什么仍要绑定 Camoufox？因为剩下的 20%——反检测面——需要C++ 层面的二进制补丁，任何 preload 脚本都无法等价实现。
差异分布如下：
能力 | 实现位置 | 原版 Firefox | Camoufox |
调试器 / 脚本 / DOM / 网络 / Hook / AST / LLM 工具 | BiDi + RDP 的 TypeScript | ✅ 可用 | ✅ 可用 |
| TypeScript preload | ✅ 可用 | ✅ 可用 |
| C++ 二进制补丁 | ❌ 锁死为 | ✅ 已 patch |
| C++ 注入 | ❌ 空或过短 | ✅ 真实 |
WebGL vendor / renderer 伪装 | C++ 覆盖 | ❌ 泄露真实 GPU 或 | ✅ 伪装 |
Canvas 2D / AudioContext 像素与采样级噪声 | C++ 注入 | ❌ 指纹稳定可识别 | ✅ 加噪 |
字体枚举伪装 | C++ 字体表替换 | ❌ 真实安装字体 | ✅ 伪装 |
WebDriver 协议侧信道（RemoteAgent 类、Marionette 残留） | C++ 删除 | ❌ 可被探测 | ✅ 清理 |
| 字符串问题 | n/a | 可用 |
结论：在原版 Firefox 上，仅 navigator.webdriver === true 这一条，就足以让 CreepJS / sannysoft / 商业反爬评分系统直接判定为机器人，根本走不到我们 preload 那一层。TypeScript 层的 Object.defineProperty(navigator, 'webdriver', ...) 只能影响主 realm，覆盖不到 worker、iframe、特权页；何况 Firefox 150 上 webdriver 属性描述符是锁死的，重定义会抛错。用 Proxy 包 navigator 也会被 navigator === window.navigator.constructor.prototype.constructor 这类比较探测到。
我们的 inject_stealth_hook 已经把 Hook 表面清理干净（Function.toString 伪装、跨 realm 探针、零全局变量——证据见 stealth-evidence/SUMMARY.md stage 6），但它有意止步于 Hook 边界。引擎级信号（navigator.webdriver、Canvas 噪声、GPU 字符串）按设计不在其能力范围内。
Related MCP server: camoufox-reverse-mcp
需要 Node.js 20+。
支持的浏览器组合：Camoufox + geckodriver，且仅此一种。 原版 firefox --remote-debugging-port 暴露的是 CDP，不是 WebDriver BiDi，本项目不支持；并且 stealth 那半工具链也只对 Camoufox 生效（详见 为什么是 Camoufox）。
Camoufox：从 https://github.com/daijro/camoufox/releases 下载最新 macOS .dmg，拖入 /Applications。首次运行右键 → 打开 绕过 Gatekeeper。
geckodriver：brew install geckodriver。
Apple Silicon 装到 /opt/homebrew/bin/geckodriver。
Intel 装到 /usr/local/bin/geckodriver（与代码默认值一致）。
项目本体：
npm install
npm run build集成 / e2e 套件需要 Camoufox 与 geckodriver 实际可用——握手失败会直接抛错，不会自动 skip。单元测试（npm test）不依赖任何浏览器二进制。
未做常规验证。从 Camoufox releases 与 geckodriver releases 自行安装，再通过 CAMOUFOX_PATH / GECKODRIVER_PATH（或 --camoufox-path / --geckodriver-path）指向二进制路径即可。
--stealth 到底控制什么--stealth=auto（默认）会在会话初始化时把 src/stealth-scripts/ 下的 firefox-default preload 注入进去。--stealth=off 仅跳过这一层 preload —— Camoufox 的 C++ stealth 始终生效，与这个开关无关。
本服务的预期使用方式是被 AI agent 驱动（Claude Code、Claude Desktop、Cursor 等）。从 shell 单独跑它不是真实的逆向工作流，唯一合理的场景是验证安装是否成功（见下方 冒烟测试）。
# 在仓库目录下执行，确保 build 路径解析正确
claude mcp add camoufox-jsreverser \
--env LLM_PROVIDER=openai \
--env LLM_API_KEY=sk-... \
--env GECKODRIVER_PATH=/opt/homebrew/bin/geckodriver \
-- node "$(pwd)/build/src/index.js" --stealth=auto或者直接编辑 ~/.claude.json：
{
"mcpServers": {
"camoufox-jsreverser": {
"command": "node",
"args": [
"/绝对路径/camoufox-jsreverser-mcp/build/src/index.js",
"--stealth=auto"
],
"env": {
"LLM_PROVIDER": "openai",
"LLM_API_KEY": "sk-...",
"GECKODRIVER_PATH": "/opt/homebrew/bin/geckodriver"
}
}
}
}env 块就是 agent 需要的全部配置。可用变量：
变量 | 用途 |
|
|
| 所选 provider 的 Bearer key。 |
|
|
| 可选的默认 model id。 |
| Camoufox 二进制路径。macOS 默认： |
| geckodriver 二进制路径。默认 |
understand_code、summarize_code、deobfuscate_code 这三个 LLM 后处理工具在未配置 provider 时会干净地返回 LlmNotConfigured——绝不会抛——所以即便没配 LLM key，其余工具面依然完全可用。
这些 flag 由 MCP 客户端通过 args 透传。常用的有：
Flag | 含义 |
| 初始化时是否注入 |
| 覆盖会被识别的 |
| 覆盖 Camoufox 二进制（优先级高于 |
| 覆盖 geckodriver 二进制（优先级同上）。 |
| 不启动新进程，而是连接已运行的 geckodriver 会话。仅开发/调试用。 |
要确认服务能起、MCP 客户端能与之握手，本地手动跑一次：
node build/src/index.js --stealth=auto它会通过 stdio 讲 MCP 协议。成功启动没有任何 banner——静默就是对的。按 Ctrl-C 退出。这种 shell 直跑模式下的本地 env 覆盖，可以放在仓库根目录的 .env 文件里（cp .env.example .env）；优先级为：MCP 客户端 env > .env > 系统环境。日常配置请始终放在客户端那边。
工具 | 用途 |
| 通过 BiDi preload 应用 stealth preset（默认 |
| 把 preset 推送到 dedicated / shared worker realm（worker 序章已运行后再注入）。 |
| 用 Function.toString 伪装 + 通道采样的 Proxy 包装某个全局点路径（如 |
| 直接注入任意 preload JS——上面三个都套不上时的逃生口。 |
| 反查 capability 已知的所有 preset / feature。 |
| 通过 BiDi emulation 覆盖 |
npm run lint # eslint
npm run typecheck # tsc --noEmit
npm test # vitest test/unit（快，不需要浏览器）
npm run test:integration # 真 BiDi/RDP，经 geckodriver
npm run test:e2e # 完整 MCP-over-stdio 工作流（W1–W7）集成 / e2e 在缺少 Firefox 或 geckodriver 时会干净 skip，因此开发者机器上没装浏览器也不会污染单元测试结果。
CI 在 Firefox latest + latest-esr 两条线上各跑一遍三层（见 .github/workflows/ci.yml）。
ISC。
Summarize cached scripts: crypto signature hits + sensitive API usage. Filter by URL substring.
| Name | Required | Description | Default |
|---|---|---|---|
| urlSubstring | No | ||
| maxScripts | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the action (summarize) but does not clarify if the tool is read-only, requires authentication, handles errors, or has any side effects. This is insufficient for an AI agent.
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 concise sentence with no wasted words. It is front-loaded and easy to parse. However, it could benefit from slightly more detail without losing 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?
Given no output schema and minimal annotations, the description lacks information about return values, prerequisites (e.g., cached scripts must exist), and potential limitations. The tool is simple, but the description does not fully equip an agent to understand its behavior and output.
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 must compensate. It explains the urlSubstring parameter ('Filter by URL substring') but completely omits the maxScripts parameter, leaving its purpose unclear. Only half of the parameters are addressed.
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 summarizes cached scripts for crypto signature hits and sensitive API usage, which is a specific verb+resource combination. It implies a focused analysis but does not explicitly differentiate from sibling tools like detect_crypto or search_in_scripts.
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 only mentions optional URL substring filtering but provides no guidance on when to use this tool versus alternatives. Missing context about prerequisites or exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cluster frames by byte-signature heuristic. v1 local-only; no LLM.
| Name | Required | Description | Default |
|---|---|---|---|
| wsid | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool is local-only and does not use an LLM, which is helpful, but misses other behavioral traits like potential side effects, performance impact, or the nature of the clustering 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 very short (8 words), which is concise but at the expense of necessary detail. It front-loads the key action, but critical information (parameter meaning, output nature) is missing, making it inefficient for agent understanding.
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 low complexity (1 parameter, no output schema, no nested objects), the description should be fairly complete but is not. It fails to describe the return value, the clustering algorithm's implications, or how results can be interpreted. A better description would specify what 'clusters' means and the format of the results.
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 single parameter 'wsid' has no description in either schema or tool description. Schema coverage is 0%, and the description does not explain what value to provide or its purpose, leaving the agent completely in the dark.
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 'Cluster frames by byte-signature heuristic', which gives a specific verb and noun, but 'frames' is ambiguous without referencing WebSocket explicitly. It somewhat distinguishes from siblings like get_websocket_message by implying analysis rather than retrieval, but the differentiation is weak.
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. The mention 'v1 local-only; no LLM' hints at limitations but does not provide explicit when-to-use or when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Install a hook that issues debugger; when XHR/fetch URL matches the pattern. v1 fires only if DevTools is open; M3 RDP wires the actual debugger pause.
| Name | Required | Description | Default |
|---|---|---|---|
| urlPattern | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that v1 fires only if DevTools is open and M3 RDP wires the actual pause, but no annotations are provided, leaving other behaviors (e.g., side effects, removal) unmentioned.
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 efficient sentences, but the second sentence on version details could be more relevant to the core action.
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?
Missing details on hook installation side effects, removal method, and return value; insufficient for a 1-param side-effect tool with no output schema.
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 does not clarify what format urlPattern expects (regex, substring, exact match); with 0% schema description coverage, the parameter remains ambiguous.
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 that it installs a hook that issues `debugger;` when an XHR/fetch URL matches a pattern, distinguishing it from sibling tools like set_breakpoint and remove_xhr_breakpoint.
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 vs alternatives; mentions version differences but lacks context for selection or exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify Firefox is connected and BiDi reports ready.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not disclose what happens if browser is not ready, whether the tool is idempotent, or any side effects. Minimal behavioral insight beyond the check itself.
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?
Description is a single concise sentence, front-loaded with key purpose. No wasted words; every word is necessary.
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?
No output schema exists, but description fails to explain what the tool returns (e.g., boolean, status message). Agent cannot know what to expect after calling this tool. Incomplete for a health-check 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?
No parameters exist, and schema description coverage is 100% (trivially). Per guidelines, baseline 4 is appropriate. Description does not need to add parameter info since there are none.
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 verb 'verify' and specific resources ('Firefox is connected', 'BiDi reports ready'). Clearly distinguishes from sibling tools like 'navigate_page' or 'evaluate_script' which perform actions rather than check health.
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 vs alternatives. Usage context (e.g., before performing other actions) is implied but not stated. No exclusions or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Click a DOM element identified by its sharedId.
| Name | Required | Description | Default |
|---|---|---|---|
| sharedId | Yes | ||
| contextId | 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 only states 'Click' but omits details such as whether it waits, throws on missing element, or triggers a real click event. 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 with no wasted words. However, it is too brief to be helpful; a bit more detail would improve usability without sacrificing 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?
Given no output schema and only two parameters, the description should explain inputs and behavior. It identifies the element but fails to describe return value, side effects, or success conditions. Incomplete for a simple 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%, yet the description only mentions 'sharedId' without explaining its origin or format. The 'contextId' parameter is entirely unexplained. No additional meaning provided beyond the parameter names.
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 ('Click'), the target ('DOM element'), and the identification method ('by its sharedId'). It distinguishes from sibling tools like 'type_text' or 'find_clickable_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?
No guidance on when to use this tool, prerequisites (e.g., element must be visible, already found), or alternatives. The description implies usage but provides no explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch and cache the source of every script URL on the active page. If urls/urlSubstring given, only those are collected.
| Name | Required | Description | Default |
|---|---|---|---|
| urls | No | ||
| urlSubstring | No | ||
| maxScripts | 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. 'Fetch and cache' implies reading and storing, but it does not disclose the caching behavior (scope, lifetime, overwrite), side effects, or permissions needed. Minimal behavioral information beyond the basic function.
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, each earning its place. The first sentence states the main action, the second adds the conditional filtering. No redundant words or 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?
The tool has 3 optional parameters and no output schema. The description does not explain the return value (does it return the source? cache only?), how 'maxScripts' works, or the lifecycle of the cache. For a tool that collects and caches, more behavioral detail is needed to ensure 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 has 3 parameters with no descriptions (0% coverage). The description explains 'urls/urlSubstring' as optional filters, adding meaning beyond the schema. However, 'maxScripts' is not mentioned at all, leaving its purpose unclear. Partial coverage, missing one parameter.
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 'Fetch and cache the source of every script URL on the active page' with a specific verb and resource. It distinguishes from siblings like 'list_scripts' or 'get_script_source' by focusing on bulk collection and caching. However, it does not explicitly differentiate from siblings like 'search_in_scripts' or 'summarize_code', so it falls short of a 5.
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 'get_script_source' (single script) or 'list_scripts' (metadata only). The description mentions conditional filtering but does not explain when not to use it or provide context for choosing among many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Diff two keyed collections (scripts / requests / hooks). Items with the same key but different hash become "changed". Used by evidence comparisons.
| Name | Required | Description | Default |
|---|---|---|---|
| left | Yes | ||
| right | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It explains 'changed' items but omits behavior for added/removed items.
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 crisp sentences, front-loaded with core purpose, 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 diff tool, the description defines the core logic but lacks details on added/removed items and does not leverage absence of annotations or output schema.
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 must add meaning. It implies items have key and hash, but doesn't detail the structure or required fields fully.
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 diffs two keyed collections and gives examples (scripts/requests/hooks), but does not distinguish it from 'diff_env_requirements' among siblings.
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 says 'Used by evidence comparisons' but provides no explicit when-to-use, when-not-to-use, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a hook definition. Use inject_hook to attach it to the page or workers.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| targetExpr | Yes | ||
| capture | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose behavioral traits such as whether creating a hook with the same name overwrites or errors, permission requirements, or side effects.
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 sentences) and front-loaded with the main action. However, it is slightly too terse, missing opportunities to add value without sacrificing brevity.
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 3 required parameters and no output schema or annotations, the description is incomplete. It fails to explain what a hook definition is or how parameters like targetExpr and capture are used.
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 adds no meaning to the parameters (name, targetExpr, capture). The agent must infer their semantics from names alone, which is insufficient.
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 ('Create a hook definition') and distinguishes this tool from its sibling 'inject_hook' by explicitly noting that inject_hook is for attaching the definition.
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 a clear usage guideline by directing the user to use inject_hook after creation, but it does not provide guidance on when not to use this tool or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a named session snapshot from memory.
| 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 full burden. It only reveals that the tool deletes from memory, without saying if deletion is reversible, if it affects current state, or what happens to the snapshot. Minimal disclosure beyond the action itself.
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 sentence with no extraneous words. Perfectly concise for the intended 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?
For a simple one-parameter tool, the description is adequate but could be more informative. It does not cover return values or side effects, but given the low complexity, it is minimally 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 only parameter 'name' has 0% schema description coverage, and the description does not elaborate on its format, origin, or validation. It merely repeats the fact that the snapshot is 'named', adding no substantive meaning.
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 (delete), resource (session snapshot), and scope (from memory). It distinguishes this tool from siblings like save_session_state and load_session_state by specifying deletion.
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 when to use (when you want to delete a snapshot), but provides no explicit guidance on when not to use or alternatives. No mention of prerequisites or consequences.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Apply local AST transforms (constant fold / string array decrypt / dead-code / control-flow hint) to deobfuscate a JS snippet.
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | ||
| transforms | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full transparency burden. It discloses the transforms (constant fold, string array decrypt, dead-code, control-flow hint) but does not cover side effects, limitations, or return behavior beyond the transforms.
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 concise sentence, front-loaded with the action. The list of transforms is parenthesized. It could be slightly improved by addressing parameters, but it remains 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 0% schema coverage, no annotations, and no output schema, the description is incomplete. It fails to explain return values, error scenarios, or how to specify transforms, leaving many questions unanswered.
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%, yet the description fails to explain the 'transforms' parameter or its valid values. The 'source' parameter is implied but not clarified. The description adds little meaning beyond what the schema 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 uses a specific verb 'deobfuscate' and names the resource 'JS snippet', listing the types of AST transforms. It distinguishes from sibling tools as no other tool in the list performs deobfuscation.
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 when to use (when deobfuscation is needed) but does not explicitly state when not to use or provide alternatives. Usage context is only inferred from uniqueness among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run static crypto-algorithm signature rules (AES/RC4/MD5/SHA*/Base64/HMAC/RSA/SM*) against inline source or a cached script.
| Name | Required | Description | Default |
|---|---|---|---|
| source | No | ||
| scriptUrl | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It indicates a static analysis operation but does not disclose whether it modifies state, requires permissions, or has any side effects. The read-only nature is implied but not explicit.
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, focused sentence with a useful list of algorithms. No unnecessary words, but it could be slightly more structured with separation of algorithm list.
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 does not explain what the tool returns (e.g., matches, confidence scores) or how to interpret the output. This is a significant gap for a detection tool, especially with no output schema provided.
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 mapping 'inline source' to the 'source' parameter and 'cached script' to 'scriptUrl', adding basic semantic context. However, it lacks details on accepted formats 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 action ('Run'), the resource ('static crypto-algorithm signature rules'), and lists specific algorithms (AES, RC4, etc.). It distinguishes this tool from siblings like 'search_in_scripts' or 'deobfuscate_code' by focusing solely on cryptographic pattern detection.
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 for detecting crypto algorithms in source code, but it does not explicitly state when to use this tool versus alternatives (e.g., 'search_in_scripts' for general pattern matching) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Diff two pip-style requirement files. Returns added / removed / changed / unchanged buckets plus counts.
| Name | Required | Description | Default |
|---|---|---|---|
| left | Yes | ||
| right | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the output format (buckets and counts) which is sufficient for a read-only diff operation. However, it does not disclose whether the inputs are file paths or content, nor does it mention any side effects or error conditions. With no annotations, this is a moderate level of 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?
The description is two sentences with no extraneous information. It is direct and front-loaded with the core action, making it highly efficient for an agent.
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 diff tool with two string inputs and no output schema, the description covers the essential behavior and output format. Minor missing details like order sensitivity or input type are outweighed by the tool's low 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 defines two string parameters ('left', 'right') without descriptions, and the tool description adds only that they are 'pip-style requirement files'. This leaves ambiguity about whether they are file paths or file contents, which is critical for correct usage. The low schema coverage (0%) makes the description insufficient.
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 'diff' and the resource 'two pip-style requirement files', distinguishing it from sibling 'collection_diff' which applies to collections. The output buckets are also mentioned, making the purpose 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?
No information is provided about when to use this tool compared to alternatives like 'collection_diff' or other analysis tools. There is no guidance on prerequisites or context, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export a named snapshot as a JSON string (for writing to disk).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It describes the action (export) but does not indicate whether it is read-only, whether the snapshot is preserved after export, or any side effects. This is insufficient for a tool that outputs data.
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 essential action and purpose without any extraneous words. Every part earns its place.
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, no output schema), the description is mostly complete. It explains the input and output format. A minor gap is the lack of details on the JSON structure, but this is acceptable for a straightforward export 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?
The single parameter 'name' is not described in the schema (0% coverage). The description implies it is the snapshot name, adding basic meaning. However, it does not specify constraints like acceptable formats or how missing names are handled.
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 'Export' and the resource 'named snapshot' with the format 'as a JSON string' and purpose 'for writing to disk'. It is specific enough to distinguish from sibling session state tools that likely handle saving/loading internally.
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 like save_session_state or load_session_state. There is no mention of prerequisites or context that would help the agent decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Evaluate a JavaScript expression in the context of the current paused callframe. Throws if not paused.
| Name | Required | Description | Default |
|---|---|---|---|
| expression | 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 discloses the key behavior of throwing if not paused, but omits details about return value format, side effects, or performance characteristics.
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, consisting of two sentences with no redundant information. Critical information is 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?
For a simple tool with one parameter and no output schema, the description covers the main purpose and a key behavioral constraint. However, it does not describe the return value, which would be helpful for an agent.
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%, yet the description adds no detail about the 'expression' parameter beyond what is already in the schema type (string). No examples, format hints, or context are 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 uses a specific verb ('Evaluate'), resource ('JavaScript expression'), and context ('in the context of the current paused callframe'). This clearly distinguishes it from sibling tool 'evaluate_script' which likely evaluates in a different scope.
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 paused on a callframe and mentions a failure condition ('Throws if not paused'), but does not provide explicit when-not-to-use guidance or mention alternatives like 'evaluate_script'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Evaluate a JS expression in a window realm of the active (or specified) context.
| Name | Required | Description | Default |
|---|---|---|---|
| expression | Yes | ||
| awaitPromise | No | ||
| contextId | No | ||
| realmId | 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 mentions 'in a window realm' and 'active (or specified) context', but does not describe side effects, error handling, return value behavior, or safety implications. For a tool that evaluates arbitrary JavaScript, this is insufficient.
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, concise sentence that front-loads the core purpose. However, it omits important details like parameter usage and behavioral notes, so it sacrifices completeness for brevity.
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 (evaluating arbitrary JavaScript) and the lack of annotations, output schema, and parameter descriptions, the description is far from complete. It does not address return values, error handling, security concerns, or how to use the optional parameters. A more thorough description is needed.
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, but it adds no explanation for any of the four parameters (expression, awaitPromise, contextId, realmId). The parameter names are self-explanatory to some extent, but the description does not clarify their expected values, default behavior, or how they interact.
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 ('Evaluate a JS expression') and the context ('in a window realm of the active (or specified) context'). It provides a specific verb and resource, but does not differentiate from the sibling tool 'evaluate_on_callframe', which likely evaluates in a call frame rather than a window realm.
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 it works with the active or specified context, but does not explain when to choose this over evaluate_on_callframe or other evaluation tools. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Bundle cached scripts + hook samples + network samples + env probes into artifacts/tasks//.
| Name | Required | Description | Default |
|---|---|---|---|
| taskId | Yes | ||
| envProbes | No | ||
| includeNetwork | No | ||
| includeHooks | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavior. It mentions output location but omits side effects (e.g., overwriting, deletion, or resource consumption). The tool bundles multiple elements, but the description does not state if any existing data is modified or destroyed.
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?
One sentence, no wasted words. It efficiently conveys the core action and output destination. Ideal length.
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 lack of annotations, output schema, and 0% schema coverage, the description is insufficient. It does not explain return values, preconditions, or what happens to previously stored artifacts. The tool has four parameters, but only three are implicitly referenced. Crucial context is missing.
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 hints at the purpose of includeNetwork and includeHooks by listing network samples and hooks, but it does not explain envProbes (an array of objects) or how the boolean flags affect behavior. The mapping is weak.
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 'Bundle' and lists the resources being bundled (cached scripts, hook samples, etc.), with a specific output path. This makes the tool's primary function clear, but it does not differentiate from sibling tools like 'collect_code' or 'export_session_report'.
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 (e.g., collect_code, export_session_report). The description does not mention prerequisites, typical use cases, or scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render a Markdown summary of the current session (scripts / requests / hooks / evidence) into artifacts/tasks//report.md.
| Name | Required | Description | Default |
|---|---|---|---|
| taskId | Yes | ||
| title | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral disclosure burden. It states the output location but does not mention whether the file is overwritten, requires permissions, or has any side effects. Minimal transparency beyond the basic 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?
Single sentence, front-loaded with the core action, no extraneous words. Efficient and clear.
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 or output schema, and 0% schema description coverage, the description is adequate but lacks details like behavior on file existence, title parameter usage, or limitations. Could be more complete to aid an agent.
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 add meaning. It indirectly explains taskId via the output path, but does not describe the title parameter. Partial compensation for schema gap but not 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 clearly states it renders a Markdown summary of the current session into a specific file path, listing included elements (scripts, requests, hooks, evidence). This distinguishes it from sibling tools like collect_code or record_reverse_evidence.
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 for generating a session summary but does not explicitly state when to use this tool vs alternatives. No when-not guidance or differentiation from siblings like export_rebuild_bundle or collection_diff.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find all clickable elements (links, buttons, role=button, onclick, submit inputs) on the active page.
| Name | Required | Description | Default |
|---|---|---|---|
| contextId | 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 does not disclose whether the tool highlights elements, returns a list, or has side effects. Behavioral details beyond the basic function are absent.
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 that efficiently conveys the tool's purpose. No filler or 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, no annotation guidance, and an undocumented parameter, the description is incomplete. It does not specify what the tool returns or how to use the contextId parameter, leaving significant gaps for an agent.
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 one optional parameter 'contextId' with no description. The tool description does not explain its purpose, leaving agents without guidance. Since schema description coverage is 0%, the description should compensate but fails to do so.
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 finds clickable elements and provides specific examples like links, buttons, and role=button. It distinguishes itself from siblings such as click_element, which performs an action on a specific element.
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 that this tool is useful for discovering interactive elements before clicking, but it does not explicitly state when to use it versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find string or regex pattern in a single cached script. Use get_script_source first to populate the cache.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| pattern | Yes | ||
| regex | No |
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 the cache dependency but does not specify behavior when cache is empty or URL not found, nor does it describe return format 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 extremely concise with two sentences. The first sentence states the purpose, the second provides a usage guideline. 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?
Given the absence of annotations and output schema, the description is somewhat incomplete. It covers the prerequisite but lacks details on parameter semantics and return behavior, which would be helpful for an agent.
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% description coverage. The description mentions 'pattern' implicitly but does not explain the meaning of 'url', 'pattern', or the 'regex' boolean flag. It adds minimal value over 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 action (Find), the resource (single cached script), and the method (string or regex pattern). It distinguishes from siblings like 'search_in_scripts' which likely searches across scripts.
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 a clear prerequisite: 'Use get_script_source first to populate the cache.' This guides the agent on when to use this tool. However, it does not explicitly mention when not to use it or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a single console entry by index.
| Name | Required | Description | Default |
|---|---|---|---|
| index | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It indicates a read operation ('Get'), but does not disclose behavior for out-of-range index or other edge cases. Adequate for a simple getter but lacks depth.
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: one sentence, no unnecessary words. Front-loaded with the 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?
Given the tool's simplicity (one parameter, no output schema), the description is complete. It tells what is retrieved and how to specify which entry.
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 adds meaning to the only parameter 'index' by specifying it selects the console entry. With 0% schema description coverage, this is valuable, but the explanation is minimal.
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 'Get' and the resource 'single console entry by index'. It distinguishes from sibling tool 'list_console_messages' by specifying 'single'.
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 like 'list_console_messages'. The differentiation is implied by the word 'single', but no direct comparison or conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a flattened summary of the DOM tree (up to depth 4, 20 children per node).
| 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 full burden. It discloses the flattening, depth, and children constraints, but does not describe the output format, what elements are included, or performance implications. Partial 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?
One sentence, 13 words, front-loaded with key information. No unnecessary content.
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 explain what a 'flattened summary' contains (e.g., tag names, attributes). Without that, the tool's return value is unclear. Incomplete for practical 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?
No parameters exist; the input schema is empty. Per guidelines, zero parameters baseline is 4. The description does not need to add parameter info, and it does not.
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 'Get' and the resource 'flattened summary of the DOM tree' with specific constraints (depth 4, 20 children per node). It distinguishes from siblings like 'query_dom' which implies more flexible querying.
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, no prerequisites or exclusions. The description only states what it does without context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read collected samples for a hook. Optionally limit count and filter by timestamp.
| Name | Required | Description | Default |
|---|---|---|---|
| hookId | Yes | ||
| limit | No | ||
| since | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It states 'Read' implying read-only behavior, but does not disclose any constraints, side effects, or behavior under error conditions (e.g., missing hookId, no data).
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 concise sentence, front-loaded with the core action. Every word adds value, with no redundancy or 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 no output schema, the description should hint at the return format (e.g., array of sample objects). It does not. Additionally, it lacks context about data volume or performance implications. The description is adequate for a minimal read tool but incomplete for robust 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 description coverage is 0%, so the description must compensate. It explains 'limit' and 'since' parameters ('Optionally limit count and filter by timestamp'), adding meaning beyond the schema. However, it does not specify the format of 'since' (e.g., Unix timestamp) and omits 'hookId' which is implicitly clear from 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 verb 'Read' and the resource 'collected samples for a hook', distinguishing it from sibling tools like 'list_hooks' and other get_* tools. It is 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?
No guidance is provided on when to use this tool versus alternatives (e.g., get_network_request, get_websocket_message). The description is purely functional without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full details of a single network request by ID. Optionally fetch its body via networkObserver.getData.
| Name | Required | Description | Default |
|---|---|---|---|
| requestId | Yes | ||
| fetchBody | No | ||
| dataType | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry the burden. It mentions optional body fetching but does not disclose what 'full details' includes, permissions needed, or any side effects.
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 only two sentences and front-loads the main action. No superfluous text, though it could be slightly more detailed without losing 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?
No output schema is provided, and the description does not clarify the return structure. For a tool with 3 parameters and simple task, it is minimally complete but leaves the agent guessing about the response.
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%; the description only alludes to `requestId` and the `fetchBody`/`dataType` pair but does not explain their meaning or format beyond what is trivially inferred.
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 resource ('single network request'), the action ('get full details'), and the identifier ('by ID'). It also distinguishes from sibling `list_network_requests` by being singular.
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?
Usage is implied (when you need details of one request), but no explicit when/when-not guidance or mention of alternatives like `list_network_requests` or `get_request_initiator`.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about the current paused state (callframe, location, why). Fails if not paused.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It discloses the failure behavior and the data returned (callframe, location, why). This is adequate for a simple read-only tool, though it could elaborate on side effects (none expected).
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 short sentences with no redundancy. The first sentence states the core purpose, the second adds the critical failure condition. Every word earns its place.
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, no output schema, and no parameters, the description sufficiently covers functionality, return information, and failure condition. It is complete for its 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?
No parameters exist, and schema coverage is 100%. The baseline for zero parameters is 4. The description adds no parameter info as none are needed.
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 retrieves information about the paused state including callframe, location, and why. It is distinct from sibling tools like pause, resume, or step_into, which control execution rather than query state.
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 notes it fails if not paused, providing a clear condition for use. It does not mention alternatives but the purpose is self-contained, and the failure message guides when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get W3C performance metrics from the active page (navigation timing + paint). M3 adds engine-level metrics behind the same tool.
| 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 full burden. It does not disclose any behavioral traits such as side effects, auth needs, or safety. The mention of M3 is forward-looking but does not clarify current behavior.
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 no wasted words. It front-loads the main purpose and 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?
Given the tool has no parameters and no output schema, the description is fairly complete for its simplicity. However, it could mention what the return format is or any prerequisites.
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 0 parameters, so the schema coverage is 100%. Per guidelines, a baseline of 4 is appropriate since no additional parameter information is needed.
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 'Get' and the resource 'W3C performance metrics' with specific scope ('from the active page') and types ('navigation timing + paint'). It is distinct from sibling tools, none of which relate to performance metrics.
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 says what the tool does but does not explicitly state when to use it vs alternatives or when not to use it. However, since no sibling tool performs a similar function, usage context is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the initiator info for a request. Returns BiDi initiator + (when M3 initiatorTracer is wired) normalized {type, stack[{scriptUrl,line,column,functionName?}]}.
| Name | Required | Description | Default |
|---|---|---|---|
| requestId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions conditional behavior (M3 initiatorTracer) but does not disclose error handling, permissions, or side effects (likely read-only). 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?
Single, well-structured sentence. Purpose stated first, followed by return details. No superfluous content.
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 one parameter and no output schema, the description provides key information: what is retrieved and under what condition. However, lacks completeness on what 'BiDi initiator' means and potential error states.
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 and no parameter details. Description does not explain the required 'requestId' parameter, type, format, or example. Fails to compensate for missing schema 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?
Description clearly states it gets initiator info for a request and specifies return content (BiDi initiator, optionally normalized). Distinguishes from siblings like 'get_network_request' by focusing on initiator.
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 other network-related tools (e.g., get_network_request). Lacks context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the source of a script by URL. Fetches via the page (BiDi limitation; CORS may block cross-origin). Cached.
| Name | Required | Description | Default |
|---|---|---|---|
| url | 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 fetching is via the page (BiDi limitation), may be blocked by CORS, and results are cached. This provides useful behavioral context, though it could add more detail on error handling or cache duration.
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 short sentences, no filler, and front-loads the core purpose. Every word 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 one parameter, no output schema, and no annotations, the description covers constraints (CORS, caching) but lacks details on return format (script source code as string?), error scenarios, or cache behavior. Adequate but not fully 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 description identifies the 'url' parameter by stating 'by URL', but adds little beyond the schema. Schema coverage is 0%, so description should compensate more; it could specify URL format or that it must be a full page script URL.
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 gets the source of a script by URL using a specific verb and resource, distinguishing it from siblings like list_scripts (lists scripts) and search_in_scripts (searches within scripts). The addition of 'by URL' and the constraints (BiDi, CORS) further clarify the scope.
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 needing a script's source by URL, but does not explicitly state when to use this tool versus alternatives like list_scripts or search_in_scripts. It mentions potential CORS issues but lacks when/not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read cookies, localStorage, sessionStorage, and IndexedDB names for the active page.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a read operation (non-destructive) and limits output to 'names' rather than values. However, with no annotations, it could provide more detail about permission requirements, performance, or edge cases (e.g., empty storage).
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, well-formed sentence that conveys the tool's purpose without redundancy. Front-loaded with 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?
Given the tool's simplicity (zero parameters, no output schema), the description adequately covers its functionality. It could mention the condition that a page must be loaded, but the overall context is sufficient for an agent.
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 the input schema is fully covered. However, the description does not add behavioral context beyond the schema. Baseline 3 is appropriate given 100% schema coverage.
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 explicitly states the tool reads cookies, localStorage, sessionStorage, and IndexedDB names for the active page. It uses a clear verb ('Read') and specific resources, distinguishing it from sibling tools that deal with DOM, console, network, etc.
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 or when to choose alternatives. It does not mention exclusions, prerequisites, or comparisons to other storage-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a single frame by wsid + frameIndex.
| Name | Required | Description | Default |
|---|---|---|---|
| wsid | Yes | ||
| frameIndex | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, leaving the description as the sole source for behavioral traits. It does not disclose read-only nature, error handling, or side effects. For a read operation, this is insufficient.
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 (8 words) that states purpose and key parameters. It is front-loaded and not verbose, though some additional context could be included without losing 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?
Given no annotations and no output schema, the description should provide more context about return values, error states, and what constitutes a 'frame'. It is too brief for a tool with this simplicity and missing structured data.
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 names both parameters ('wsid' and 'frameIndex'), adding minimal meaning beyond the schema's type definitions. However, it does not explain what 'wsid' represents or the role of 'frameIndex', so value is limited.
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 'Get' and the resource 'a single frame', specifying the exact parameters 'wsid + frameIndex'. It distinguishes from the sibling 'get_websocket_messages' by implying singularity, though 'frame' context is ambiguous.
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 'get_websocket_messages' or 'analyze_websocket_messages'. The description does not mention exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get multiple frames for a wsid with optional filters.
| Name | Required | Description | Default |
|---|---|---|---|
| wsid | Yes | ||
| limit | No | ||
| since | No | ||
| dir | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits, but it only states it retrieves multiple frames. It does not mention side effects, ordering, pagination, or authentication requirements.
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 concise sentence with no wasted words, but it sacrifices detail that could improve clarity.
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 does not mention the return format or any additional context about the frames. Given the presence of multiple parameters and no output schema, the description is incomplete.
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 should explain parameters. However, it only mentions 'optional filters' without detailing 'wsid', 'limit', 'since', or 'dir'. The enum for 'dir' is not explained.
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 'Get' and resource 'multiple frames for a wsid', distinguishing it from the sibling 'get_websocket_message'. However, the term 'frames' could be more explicitly defined as WebSocket frames.
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 like 'get_websocket_message' or 'list_websocket_connections'. The description lacks any context for usage decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create and inject a hook in one call. Convenience wrapper around create_hook + inject_hook.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| targetExpr | Yes | ||
| capture | Yes | ||
| target | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full burden. It only states the combined action but does not disclose side effects, permissions, reversibility, or return values. This is insufficient for a write operation.
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 at two sentences, but it sacrifices essential information. It is front-loaded with the main action, but the brevity comes at the cost of completeness for a tool with 4 parameters.
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 4 parameters (3 required), no output schema, and no annotations, the description is severely incomplete. It fails to explain parameters, behavior, return, or usage context, making it inadequate for an agent.
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 adds no meaning to parameters like name, targetExpr, capture, or target. Without any parameter explanation, the agent cannot correctly invoke the 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?
The description clearly states the tool creates and injects a hook in one call, and identifies it as a convenience wrapper around create_hook + inject_hook. This distinguishes it from sibling tools and specifies the verb and resource.
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 indicates it's a wrapper for create_hook and inject_hook, suggesting use when both actions are needed. However, it lacks explicit guidance on when not to use it or alternatives beyond the underlying tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inject a created hook into the page or worker(s). target: "page" | "worker:" | "all-workers" (default "page").
| Name | Required | Description | Default |
|---|---|---|---|
| hookId | Yes | ||
| target | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose side effects, required permissions, or whether the hook can be removed. It only describes the action without 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 very short and includes essential parameter information. It is front-loaded with the action and target. Could slightly reduce 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 two parameters, the description provides basic context. However, it lacks information about return values, errors, or lifecycle of hooks. Adequate but not comprehensive.
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 explains the target parameter options and default value, but does not describe hookId beyond being a string. Partial help for one parameter.
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 explicitly states the action (inject) and target (created hook into page or worker). It also defines the target parameter options clearly. However, it does not differentiate this tool from siblings like hook_function or inject_stealth.
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. It lacks any context about prerequisites or exclusions, leaving the agent to infer usage from the description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inject arbitrary preload JavaScript via BiDi script.addPreloadScript. Source runs before page scripts.
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions behavior (runs before page scripts) but lacks details on side effects, security implications, persistence, or removal. This is a dangerous operation with insufficient 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?
Very concise two sentences, front-loaded with essential info. Every word earns its place.
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 single-param tool with no output schema, the description should cover behavior more thoroughly, especially since it involves code injection. Missing critical context like scope, persistence, and how to revert.
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 one param 'source' with 0% description coverage. Description only says 'JavaScript' but does not clarify format (code string vs URL) or constraints. Adds minimal meaning 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?
Description clearly states it injects preload JavaScript that runs before page scripts, using BiDi API. This differentiates it from similar tools like evaluate_script or inject_hook.
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?
Description implies usage for preload scripts but does not provide explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Apply a stealth preset via BiDi preload. Default: firefox-default.
| Name | Required | Description | Default |
|---|---|---|---|
| preset | 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 reveals the mechanism ('via BiDi preload') but does not mention side effects, resource requirements, whether the action is destructive, or if it modifies persistent state. Critical 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?
The description is very short (one sentence), which is concise but lacks structure. It front-loads the main action but omits important contextual details. The brevity comes at the cost of completeness, making it minimally adequate.
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 (stealth injection, many sibling tools) and the absence of annotations and output schema, the description is insufficiently complete. It does not mention return values, prerequisites, or how this tool fits into a workflow. More context is needed for an agent to use it 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?
The input schema has one optional parameter with no description (0% coverage). The description adds only a default value ('Default: firefox-default'), but does not explain the parameter's meaning, valid values, or how to choose a preset. The agent lacks sufficient semantic information to use the parameter correctly.
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 ('Apply a stealth preset') and the method ('via BiDi preload'), providing a specific verb and resource. It also gives a default preset, which adds context. However, it does not explicitly distinguish itself from similar sibling tools like inject_stealth_hook or inject_stealth_to_workers, leaving some ambiguity.
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. Among many stealth-related sibling tools (e.g., inject_stealth_hook, list_stealth_presets), there is no explanation of the appropriate context or prerequisites. The description only mentions a default preset but lacks usage recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render a stealth-hardened wrap (Function.toString masking + channel-emitting Proxy) over one or more dotted global paths, optionally with performance.now/Date.now timing neutralisation, then install via BiDi preload. Main world only — use inject_stealth_to_workers for worker realms.
| Name | Required | Description | Default |
|---|---|---|---|
| wraps | No | ||
| neutraliseTiming | No | ||
| timingMaxGapMs | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It reveals key behavioral traits: stealth hardening, toString masking, channel-emitting Proxy, timing neutralization, and BiDi preload installation. It does not mention reversibility or permission needs, but the disclosed details are substantial.
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 tight sentences. The first packs critical technical context; the second provides essential usage guidance. No fluff or 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 complexity (stealth hook with multiple options), the description covers purpose and boundaries but lacks parameter details and return value information. No output schema, so return expectations are omitted. Adequate but not 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?
Schema coverage is 0%, so description must explain parameters. It mentions 'dotted global paths' (targetPath) and 'timing neutralisation' (neutraliseTiming/timingMaxGapMs), but does not explain channelName, capture, or the wraps array structure in sufficient detail. Only partial coverage for two of the three key parameters.
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 specifies the tool's action: rendering a stealth-hardened wrap over global paths with specific techniques (Function.toString masking, Proxy). It also distinguishes from sibling inject_stealth_to_workers by stating 'Main world only'. The verb 'render' and resource 'stealth-hardened wrap' are precise.
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: 'Main world only — use inject_stealth_to_workers for worker realms.' This clearly tells the agent when to use this tool versus a named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Push a stealth preset (default firefox-default) into every dedicated/shared worker realm via post-start eval. With watch:true (default) subscribes to new-worker events for the rest of the session.
| Name | Required | Description | Default |
|---|---|---|---|
| preset | No | ||
| watch | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses default preset, watch behavior subscription, and session scope. However, with no annotations, it lacks details on side effects, reversibility, 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?
Two concise sentences with no unnecessary words, front-loading the core action and then the watch 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 no output schema and simple parameters, the description covers the main functionality and optional behavior. Could mention return value (likely void) but 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?
Adds meaning by clarifying defaults (preset default Firefox-default, watch default true) but does not explain valid preset values or full behavior beyond defaults.
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: push a stealth preset into every dedicated/shared worker realm via post-start eval. It distinguishes from siblings by specifying the target (workers) and mechanism.
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?
Implies usage for injecting stealth into workers but provides no explicit guidance on when to use this tool versus alternatives like inject_stealth or inject_stealth_hook.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect an RDP object grip: preview + prototype + own properties (+ optional internal slots).
| Name | Required | Description | Default |
|---|---|---|---|
| grip | No | ||
| actor | No | ||
| withInternalSlots | No |
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 implies a read operation but does not explicitly state side effects, permissions, or limitations. Missing important context like whether inspection modifies state or requires specific access.
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, which is concise, but the term 'grip' is jargon that may not be immediately obvious. It could benefit from brief clarification or examples without adding length.
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, no annotations, and incomplete parameter semantics, the description leaves significant gaps. It does not describe the return structure, error conditions, or the role of 'actor'. A more complete description is needed for effective tool selection.
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 must clarify meaning for all 3 parameters. It only hints at 'withInternalSlots' via 'optional internal slots', but 'grip' and 'actor' are left unexplained. The nested 'grip' object lacks any property definitions in the schema, adding confusion.
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 ('inspect') and identifies the resource as 'RDP object grip', listing the components included (preview, prototype, own properties, optional internal slots). This clearly distinguishes it from sibling tools like analyze_target or get_dom_structure, which operate on different aspects.
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, nor any conditions or prerequisites. The description merely states what the tool does without contextual usage hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all currently registered breakpoints.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It accurately describes the listing action but fails to disclose any prerequisites (e.g., debugging status) or behavioral nuances like which breakpoints are included.
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, clear sentence with no unnecessary information, making it concise 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?
For a simple listing tool with no parameters and no output schema, the description is adequate. It could mention related sibling tools but is not incomplete.
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 the description does not need to add parameter semantics. The empty schema is fully covered, meeting the baseline for 0 parameters.
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 (list) and the scope (all currently registered breakpoints), distinguishing it from sibling tools like set_breakpoint and remove_breakpoint.
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. The description does not mention context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return console log entries from the active session. Optionally limit and filter by level.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| level | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description only states the basic function (return console log entries) and does not disclose behavioral traits such as whether it is read-only, whether it clears logs, or if it requires the session to be active. The minimal disclosure does not compensate for the lack of annotations.
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 is front-loaded and succinct. Every word is necessary and no extraneous content exists.
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 and low schema description coverage, the description is incomplete. It does not specify the return format (e.g., array of objects with fields), ordering, or pagination behavior. The tool is simple, but completeness could be improved 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?
The description mentions optional limiting and filtering by level, adding meaning to the two parameters. However, it does not specify the expected format for 'limit' (e.g., maximum number) or that 'level' must match one of the enum values. With 0% schema description coverage, more detail would be beneficial.
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 returns console log entries from the active session, with optional filtering and limiting. The verb 'return' and resource 'console log entries' are specific. It distinguishes from siblings like get_console_message which likely returns a single entry.
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 get_console_message, list_network_requests, etc. The description does not mention prerequisites or context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List frames (top + iframes) under the active page as a flat array.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It describes the return format (flat array) and scope (active page), but does not disclose any side effects, permissions, or limitations (e.g., if frames are deeply nested).
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 that front-loads the key action and output format with 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?
Given the tool has no parameters, no output schema, and a straightforward purpose, the description is fully complete for an agent to understand and invoke it 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?
There are no parameters, so the description correctly adds no parameter information. The schema coverage is 100%, meeting the baseline for zero parameters.
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 frames (top + iframes) under the active page as a flat array. It uses specific verbs and resources, distinguishing it from sibling tools like 'select_frame'.
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 when/when-not guidance is provided. The usage is implied by the simple nature of listing frames, but exclusions or alternatives (e.g., using search_in_sources) are not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all registered hooks with their injection status and sample count.
| 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 full burden. It implies a read-only listing operation but does not explicitly state side effects (none assumed), permissions, or any behavioral details beyond the output attributes. Adequate but not thorough.
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, front-loaded with the verb and resource, and contains no extraneous words. It efficiently conveys the tool's purpose and output contents.
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?
No output schema exists, but the description explains the output attributes. However, it lacks details on ordering, pagination, or any filtering capabilities (though none are expected due to no parameters). Sufficient for a simple list tool 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, and the schema coverage is 100% (empty schema). The description adds value by specifying the output contains injection status and sample count, which is beyond the schema. Baseline for 0 parameters is 4, and the description meets this.
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 registered hooks, specifying the attributes included (injection status and sample count). It uses a specific verb ('List') and resource ('hooks'), distinguishing it from sibling tools like create_hook or get_hook_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 provides no guidance on when to use this tool versus alternatives. With many related sibling tools (e.g., get_hook_data, remove_hook), the agent lacks context for decision-making, such as when a simple listing is sufficient versus needing detailed data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List network requests collected since session start. Filter by URL substring, method, or response presence.
| Name | Required | Description | Default |
|---|---|---|---|
| urlSubstring | No | ||
| method | No | ||
| hasResponse | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It indicates the tool lists data, implying a read-only operation, but does not explicitly state non-destructiveness or other behaviors like data limits, rate limits, or result order. Partially transparent.
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 sentence that is front-loaded with the main action and includes essential filtering capabilities. Every word earns its place 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?
The description is adequate for a simple list tool but lacks details about the return format or what fields each request object contains. Since there is no output schema, more context about the response would improve 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?
Schema description coverage is 0%, so description should explain parameters. It covers three of four parameters (urlSubstring, method, hasResponse) but omits 'limit'. The explanation is brief and does not specify parameter types or constraints beyond the schema itself.
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 resource 'network requests', with context 'collected since session start'. It also mentions filtering options, distinguishing this from single-request retrieval tools like 'get_network_request'.
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 for listing all network requests in a session but does not provide explicit guidance on when not to use or alternatives to consider. It lacks when-to-use vs. other network tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List browsing contexts (tabs and iframes) currently open in Firefox.
| 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 full burden. It states the tool lists browsing contexts but does not describe return format (e.g., what properties are returned for each context) or behavior (e.g., whether it returns nested iframes recursively). Still, it is a simple read operation.
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, complete sentence with no wasted words. The key information is 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?
For a tool with no parameters and no output schema, the description is mostly adequate but lacks detail on the return value. An agent might benefit from knowing whether it returns IDs, titles, or nested hierarchies. It is minimally 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 coverage is 100%. The description does not need to add parameter information, earning a baseline of 4.
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 'browsing contexts (tabs and iframes)', specifying scope 'currently open in Firefox'. It distinguishes from siblings like list_frames and list_workers, though overlap with list_frames is vague.
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 list_frames or list_workers. The description does not provide context for selection or exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List script resources loaded on the active page (URL + size). Does not include inline blocks; M3 RDP version will.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries burden. Discloses output includes URL and size, but does not mention other traits like read-only nature, performance impact, 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?
Two concise sentences, front-loaded with purpose and key details. 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?
No output schema, but description mentions output fields (URL, size). Lacks format details and error conditions, but for a simple listing tool with no params, 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?
Input schema is empty (0 parameters), so description does not need to add parameter info. Baseline 4 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?
Clearly states it lists script resources (URL + size) on the active page, and distinguishes from inline scripts and a future version.
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?
Does not explicitly state when to use this vs alternatives, but mentions what it excludes (inline scripts) and a future alternative. With many sibling tools like search_in_scripts, more guidance needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all named session snapshots in memory.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the sole source of behavioral information. It is too brief, omitting details like whether the tool is read-only, what output format to expect, or any side effects. A more complete description would include these 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 single sentence is highly concise and front-loaded. Every word is necessary, and there is no extraneous 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?
For a tool with no parameters, no output schema, and no annotations, the description could be more complete by explaining what 'named session snapshots' are or hinting at return values. However, the simplicity of the tool makes this 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?
There are zero parameters, so the description naturally needs no parameter details. Schema coverage is 100% (empty schema), and the description adds no param info, which 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 'List all named session snapshots in memory' clearly states the action (list), resource (named session snapshots), and context (in memory). It effectively distinguishes from sibling tools like delete_session_state or save_session_state.
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 over alternatives such as dump_session_state or list hooks. The description lacks context for selecting this tool among many similar siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the stealth features the capability knows about.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden but only provides the basic purpose. It does not disclose any behavioral traits like read-only nature, required permissions, or side effects.
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, clear sentence with no wasted words. 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?
The description is adequate for a simple listing tool with no parameters or output schema. It could be slightly more informative about the content of the list, but is sufficient given the 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?
The input schema has no parameters (100% coverage), so the description adds minimal value. Baseline 4 is appropriate, and the phrase 'the capability knows about' adds slight context about the source of features.
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 stealth features, using a specific verb+resource pattern. It does not explicitly differentiate from siblings like 'list_stealth_presets', but the name is distinct enough.
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. There are no usage contexts, prerequisites, or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the stealth presets the capability knows about.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description should disclose behavioral traits. It only states a read-like action, but does not confirm read-only safety, side effects, or permissions. The agent lacks information about whether this operation is safe.
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, concise sentence with no redundant information. It is front-loaded with the action and resource. It could be slightly expanded to aid understanding, but it is 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?
For a tool with no parameters, no output schema, and no annotations, the description should at least clarify what a 'stealth preset' is and what the list contains. It falls short of providing sufficient context for an agent to understand the tool's output.
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 baseline is 4. The description adds no parameter information, which is acceptable since there are none to describe.
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 'stealth presets,' which is a specific resource. The verb 'list' is appropriate. However, it does not distinguish from the similar sibling tool 'list_stealth_features,' which could cause confusion.
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, nor does it mention prerequisites or exclusions. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List active WebSocket connections detected on the page.
| Name | Required | Description | Default |
|---|---|---|---|
| urlSubstring | No | ||
| targetId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description is sparse. It does not disclose what the list contains (e.g., URLs, IDs), whether it's a snapshot or live, or any side effects. Only states it detects connections 'on the page'.
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 concise sentence, but it is too minimal. It could include more details without becoming wordy. It earns its place but is under-specified.
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 lack of annotations, output schema, and parameter explanations, the description is insufficient. It does not cover what the output looks like or how to use parameters, leaving the agent with incomplete 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 description coverage is 0%, and the description does not mention or explain the parameters urlSubstring or targetId. There is no guidance on their usage or effect.
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 active WebSocket connections, using a specific verb and resource. It distinguishes from siblings like get_websocket_messages which deal with messages, not connections.
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 analyzing targets or inspecting messages. It does not mention exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List workers (dedicated, shared, service) visible on the active page. M3 RDP version adds offline worker detection.
| 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 full burden. It discloses that the tool lists workers visible on the active page and mentions a version-specific feature, but it does not discuss side effects, permissions, performance implications, or what happens when no workers exist.
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—one sentence plus a brief version note—with no extraneous words. Every piece of information earns its place.
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 zero parameters, no output schema, and a simple listing function, the description provides sufficient context: it names the resource, specifies the scope (active page), and notes a version-dependent behavior.
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 zero parameters and 100% descriptive coverage, meaning the schema itself is empty. Per rubric, 0 parameters earns a baseline of 4, and the description adds no additional parameter information since none exist.
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 (list), the resource (workers), and specifies the types (dedicated, shared, service). It also contrasts with sibling list_* tools by focusing specifically on workers and adding version-specific detail (M3 RDP adds offline detection).
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 see workers on the active page) but provides no explicit guidance on when to use this tool versus sibling list tools like list_frames or list_scripts, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load a snapshot from a JSON string (previously produced by dump_session_state).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| json | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose side effects, permissions, or error handling (e.g., what happens if the JSON is invalid or the name already exists). It only states the basic operation.
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?
At one sentence, it is very concise, but this brevity sacrifices critical detail about parameters and usage. It earns its place but could be expanded without losing 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?
Given the lack of annotations, output schema, and parameter descriptions, the description is too minimal to guide correct usage. An agent needs more context about what loading entails (e.g., does it overwrite current state?).
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 two required parameters (name and json) with zero description coverage. The description does not explain what 'name' or 'json' represent, leaving the agent without essential semantic meaning for proper invocation.
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 verb 'load' and resource 'snapshot from JSON string' clearly state the action. Mentioning 'previously produced by dump_session_state' distinguishes it from related tools like save_session_state or restore_session_state.
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 the tool is for loading snapshots created by dump_session_state, providing some context. However, it does not explicitly state when to use it over alternatives like restore_session_state, nor does it mention prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a monitor for RDP resource types (console-message, error-message, network-event, source, document-event, etc.).
| Name | Required | Description | Default |
|---|---|---|---|
| resourceTypes | No | ||
| events | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only says 'Start a monitor' without explaining what happens (e.g., state changes, performance impact, prerequisites). The response format or stopping mechanism is not 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 sentence and contains no fluff, but it sacrifices completeness. It is appropriately brief given the tool's simplicity, but lacks necessary 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?
Given the absence of annotations and output schema, the description is insufficient. It does not clarify how to stop the monitor, what events are returned, or how the parameters interact. For a tool with two optional parameters, more context is needed.
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 should explain parameters. It mentions resource types in examples but does not explain the 'events' parameter or clarify that both arrays are optional. The meaning of each parameter is not adequately conveyed.
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 starts a monitor for RDP resource types and provides examples (console-message, error-message, etc.). It distinguishes the action (start) from its counterpart (stop_monitor), but does not explicitly differentiate from other monitoring tools like list_network_requests.
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 offers no guidance on when to use this tool versus alternatives (e.g., when to start a monitor vs. using list_network_requests). There are no usage context or explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open a new browsing context (tab).
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | ||
| background | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It fails to disclose whether the new tab is focused, how the background parameter affects behavior, or what the default URL is. Critical 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?
The description is very short but under-specified. It lacks necessary detail, making it inefficient for an agent. Conciseness requires completeness, not just brevity.
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 of opening a new tab with optional parameters and no output schema, the description is wholly insufficient. It omits parameter semantics, behavioral details, and contextual triggers.
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 explain parameters. It does not mention 'url' or 'background' at all, leaving the agent to guess their meaning and usage.
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 'Open a new browsing context (tab)', which is a specific verb and resource. It distinguishes from sibling tools like navigate_page (navigates current page) and list_pages (lists tabs).
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 usage guidance is provided. The description does not specify when to use this tool versus alternatives like select_page or navigate_page, nor does it mention prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pause script execution in the debugger thread.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose behavioral details beyond the basic pause action. It fails to mention side effects, reversibility, or state prerequisites (e.g., whether the debugger must be running). With no annotations, the description carries full burden, which is insufficient.
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 with no unnecessary words, fully front-loaded, and clearly communicates the core action.
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 (no params, no output schema), the description is minimally adequate. However, it lacks context on when the pause occurs (immediate vs next breakpoint) and does not explain the debugger thread behavior, leaving some ambiguity.
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 no parameters (100% coverage), so the description adds no parameter information. According to the rubric, for tools with 0 parameters, baseline is 4, which is appropriate here.
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 'Pause script execution in the debugger thread,' specifying the verb and resource. It is distinct from sibling tools like resume and step commands, which perform different actions.
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?
While no explicit when/when-not guidance is provided, the context of debugging and sibling tools (resume, step) makes it clear that this tool is used to pause execution. A slightly higher score would require explicit alternatives or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
CSS selector query against the active page. Returns shared node references.
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | ||
| contextId | 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 implies a read-only query but does not explicitly state no side effects, permissions, or constraints. The term 'shared node references' is vague and leaves important behavioral aspects undisclosed.
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 with no fluff, but it is under-specified. Important details about parameters and behavior are omitted, making it insufficiently informative. True conciseness requires completeness within brevity.
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, no annotations, and two parameters, the description is severely lacking. It does not explain return value semantics, error cases, or the meaning of 'shared node references'. The tool's complexity is not addressed.
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%, meaning parameters are not described in the schema. The description adds no information about parameters: it does not mention 'selector' or 'contextId', their types, or how to use them. This fails to supplement 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?
Description clearly states the tool performs a CSS selector query on the active page and returns shared node references. It specifies the verb (query) and resource (DOM of active page), but does not explicitly distinguish from sibling tools like get_dom_structure or find_clickable_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?
No guidance on when to use this tool versus alternatives. Does not mention prerequisites, context, or when not to use it. The description provides no usage recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Append a reverse-engineering evidence record to artifacts/tasks//runtime-evidence.jsonl.
| Name | Required | Description | Default |
|---|---|---|---|
| taskId | Yes | ||
| category | Yes | ||
| signal | Yes | ||
| detail | No | ||
| refs | No | ||
| severity | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It mentions appending but omits important behaviors: file creation, idempotency, error handling, or permission requirements. Does not contradict annotations (none present).
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, very concise. Front-loaded with action. However, brevity sacrifices essential detail, making it borderline insufficient despite good structure.
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?
With 6 parameters, 3 required, no annotations, and no output schema, the description is far from complete. It fails to explain the nature of the evidence record, semantics of each field, or expected behavior.
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 description must explain parameters. It only references taskId implicitly in the path. Category, signal, detail, refs, severity are unexplained, leaving agent to guess their meanings and formats.
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 ('Append') and the specific resource (a record to a file path 'artifacts/tasks/<taskId>/runtime-evidence.jsonl'). It distinguishes from sibling tools by being uniquely about recording evidence.
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 analyze_target or other siblings. Lacks context for conditionality or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove an existing breakpoint by its bpId.
| Name | Required | Description | Default |
|---|---|---|---|
| bpId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. Only states removal action; no disclosure of side effects, error behavior (e.g., invalid bpId), or destruction hint.
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, front-loaded, no unnecessary words. Efficiently communicates core action.
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?
Adequate for a simple deletion tool with one parameter, but lacks context like needing existing breakpoints or how to get bpId. Could be improved with usage hint.
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 0%, but description only repeats 'by its bpId' without explaining what bpId is, format, or how to obtain it. Adds minimal value over parameter name.
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 specific verb 'remove' and resource 'breakpoint' with identifier 'bpId'. It distinguishes from siblings like 'remove_xhr_breakpoint' and 'set_breakpoint'.
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 (e.g., after listing breakpoints) or alternatives. Missing prerequisites like needing the bpId from list_breakpoints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a hook and its preload script registration.
| Name | Required | Description | Default |
|---|---|---|---|
| hookId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It states the action but does not disclose any behavioral traits like reversibility, permissions, or side effects beyond the removal.
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?
One sentence is extremely concise but lacks structure and additional context. It could be expanded to include more detail without sacrificing 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 deletion tool with one parameter and no output schema, the description is minimally complete. It covers the core action, but falls short for a higher score.
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?
Single parameter 'hookId' has no description in schema or description. While the name is self-explanatory, the description adds no extra meaning beyond what the schema 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?
Description clearly states the tool removes a hook and its preload script registration, which is a specific verb+resource. It distinguishes from siblings like create_hook and list_hooks, but could be more precise about what 'preload script registration' entails.
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 over alternatives such as unhook_function or other removal tools. The description provides no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove an XHR/fetch breakpoint registered by break_on_xhr.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It states the action but does not mention side effects, error handling (e.g., if the id does not exist), or return values. The description is minimal but not misleading.
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 with no unnecessary words. 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?
For a simple removal tool with no output schema, the description is adequate but lacks information on return value or confirmation of success. It does not mention what happens if the id is invalid or already removed.
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 only parameter 'id' has no schema description, and the tool description does not explain what the id represents (e.g., the breakpoint identifier returned by break_on_xhr). It adds no meaning beyond the schema, and with 0% coverage, the burden is on the description.
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 'remove' and the specific resource 'XHR/fetch breakpoint', and it links to the sibling tool 'break_on_xhr' that registers such breakpoints, effectively distinguishing it from generic 'remove_breakpoint'.
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 indicates when to use this tool (to remove breakpoints set by break_on_xhr) and implicitly suggests that for other breakpoint types, one would use remove_breakpoint. It does not explicitly exclude alternatives, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Restore a previously saved snapshot back into the browser (cookies + localStorage + sessionStorage).
| 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 full burden. It mentions overwriting browser state but omits side effects, errors on missing snapshot, permissions, or reversibility.
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, 12 words, front-loaded. No wasteful language.
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, no output schema, and 1 parameter with 0% schema coverage, the description is too brief. Lacks details on parameter, error cases, and behavioral effects.
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 only parameter 'name' is not explained. Schema description coverage is 0%, so description must compensate but does not, leaving the agent to infer that 'name' identifies the snapshot.
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 (restore), the resource (previously saved snapshot), and the storage scopes (cookies, localStorage, sessionStorage). It distinguishes from siblings like save_session_state and delete_session_state, but could be confused with load_session_state.
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 vs alternatives like load_session_state, or prerequisites (e.g., snapshot must exist). Does not mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resume script execution after a pause.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description only states the basic action without disclosing potential effects (e.g., whether it halts further interaction until next breakpoint). Missing context about execution flow after resume.
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, direct sentence with no extraneous information. Perfectly concise 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?
Minimal description is adequate for a simple tool with no parameters and no output schema, but could benefit from clarifying that it resumes full execution (not stepping). Adequate given simplicity.
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 exist, so the description does not need to add parameter meanings. Baseline 4 is appropriate as schema coverage is 100% and no additional details 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 clearly states the verb 'resume' and the resource 'script execution', and it distinguishes from its sibling 'pause' by indicating 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?
No explicit guidance on when to use this tool versus alternatives (e.g., step_into, step_over). It implies usage after a pause but does not specify prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Aggregate risk signals across cached scripts: crypto, exfil, fingerprint, storage writes, dynamic eval. Returns weighted score.
| Name | Required | Description | Default |
|---|---|---|---|
| urlSubstring | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It says 'aggregate risk signals' and 'returns weighted score', but does not explain if it modifies state, requires authentication, or has side effects. Basic transparency but incomplete.
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 concise sentence that covers the main purpose. It is front-loaded and efficient, though there is room to add structure (e.g., bullet points).
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 vaguely mentions 'returns weighted score' but lacks detail on format or meaning. With only one optional parameter, it is somewhat complete but leaves gaps in return value semantics.
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 only parameter 'urlSubstring' has no documentation in the schema (0% coverage). The description does not explain its purpose or effect, leaving the agent to guess.
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 aggregates risk signals from cached scripts and returns a weighted score. It lists specific signal types (crypto, exfil, etc.), but does not explicitly differentiate from sibling tools like 'analyze_target' or 'detect_crypto'.
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 when-to-use or when-not-to-use guidance. The intended use case is implied (for overall risk assessment), but alternatives are not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Snapshot cookies + localStorage + sessionStorage of all known window realms into an in-memory snapshot.
| 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. It discloses what is captured and that it is in-memory, but omits details on whether it overwrites existing snapshots, return values, or side effects. Adequate but lacks depth.
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 with no wasted words, achieving conciseness. However, it sacrifices essential parameter explanation, so it loses a point for not being structured to include key details.
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 of capturing storage across multiple realms and one required parameter, the description is incomplete. It fails to explain the parameter's purpose and does not provide enough behavior context to confidently use the tool alongside many similar siblings.
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% description coverage for the required 'name' parameter. The description does not explain what 'name' is for, its format, or its role. This is a critical gap that significantly hinders correct tool invocation.
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 takes a snapshot of cookies, localStorage, and sessionStorage from all known window realms into an in-memory snapshot. It uses a specific verb and resource, and the scope differentiates it from siblings like dump_session_state or restore_session_state.
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 like dump_session_state or save to file. The description does not mention prerequisites, exclusions, or typical use cases, which is problematic given the many similar sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search a string or regex across ALL cached scripts. Populate the cache with get_script_source first.
| Name | Required | Description | Default |
|---|---|---|---|
| pattern | Yes | ||
| regex | No | ||
| urlSubstring | No | ||
| maxHits | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must cover behavioral traits. It discloses the scope (cached scripts) and the need for caching, but does not describe what happens on empty cache, performance implications, or return behavior.
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 wasted words. It front-loads the purpose and includes a clear usage hint.
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 4 parameters and no output schema, the description lacks details on several parameters and return values. It provides essential context about caching but misses parameter semantics and behavioral details.
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 only explains the 'pattern' parameter implicitly (string or regex). The 'regex', 'urlSubstring', and 'maxHits' parameters are not described at all.
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 searches a string or regex across cached scripts, giving a specific verb and resource. It distinguishes from siblings like 'find_in_script' by specifying 'ALL cached scripts', but does not explicitly differentiate from 'search_in_sources'.
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 to populate the cache with get_script_source first, providing context for when to use this tool. However, it does not mention when not to use it or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Alias of search_in_scripts. M3 RDP version differentiates by including dynamically-evaluated sources too.
| Name | Required | Description | Default |
|---|---|---|---|
| pattern | Yes | ||
| regex | No | ||
| urlSubstring | No | ||
| maxHits | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions that the tool includes dynamically-evaluated sources, which is a behavioral distinction. However, it does not state whether the tool is read-only or has any side effects, leaving some ambiguity.
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 key point (alias) and the differentiation. No redundant or unnecessary 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 lack of schema descriptions, output schema, and annotations, the description is too brief. It does not explain the return value, parameter usage, error conditions, or any other contextual details needed 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 0%, so the description must compensate. It provides no explanation of the parameters (pattern, regex, urlSubstring, maxHits), leaving the agent with no guidance beyond the schema definition.
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 it is an alias of search_in_scripts and clarifies that the M3 RDP version includes dynamically-evaluated sources. This clearly communicates the tool's purpose as searching sources, with a specific variant compared to its sibling.
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 differentiates this tool from search_in_scripts by noting that it includes dynamically-evaluated sources. This provides clear guidance on when to use this tool instead of the sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the active frame (iframe) context for subsequent tool calls. Pass empty string to clear.
| Name | Required | Description | Default |
|---|---|---|---|
| frameContextId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It reveals that passing an empty string clears the context, but does not specify error handling (e.g., if frame ID is invalid), side effects, or whether the context persists across calls. Additional traits like requiring frame IDs from list_frames are omitted.
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 purpose, and every word is essential. There is no fluff or 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 and no annotations, the description covers the basic functionality adequately for a simple tool. However, it lacks details on error conditions, prerequisites (e.g., need to list frames first), and how the context interacts with other tools. It is minimally complete but has 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 must compensate. It adds value by explaining the clearing behavior with empty string, but does not clarify what a non-empty string should represent (e.g., frame ID, name, or index) or its required format. This is insufficient for correct invocation.
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 ('Set'), the resource ('active frame (iframe) context'), and its effect ('for subsequent tool calls'). It distinguishes from siblings like list_frames by focusing on setting the context rather than listing. The mention of clearing with empty string adds specificity.
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 needing to interact with an iframe, but lacks explicit guidance on when to use versus siblings like select_page or select_worker. No when-not-to-use or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the active browsing context for subsequent tool calls.
| Name | Required | Description | Default |
|---|---|---|---|
| contextId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the disclosure burden. It states the core behavior (sets active context) but omits potential side effects, error conditions (e.g., invalid contextId), or confirmation of success. The transparency is adequate but not thorough.
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, well-structured sentence that efficiently conveys the tool's function. No extraneous words or 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?
Despite its simplicity, the description lacks necessary context: it does not explain what 'active browsing context' means, how to retrieve valid contextIds, or what subsequent tools are affected. The absence of an output schema further reduces completeness for agent 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?
The 'contextId' parameter is a string with no schema description. The tool description does not clarify what values are expected or how to obtain them (e.g., from list_pages). Since schema coverage is 0%, the description should compensate, but it adds no additional meaning.
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 ('Set the active browsing context') and the scope ('for subsequent tool calls'). It effectively distinguishes from sibling tools like 'navigate_page' (navigation) and 'select_frame' (frame selection) by focusing on page-level context switching.
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 implicitly suggests using this tool to switch between existing pages but lacks explicit guidance on when to use it versus alternatives like 'list_pages' or 'new_page'. No when-not-to-use or prerequisite information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the active worker realm. Pass empty string to clear. Used as default target by hook tools.
| Name | Required | Description | Default |
|---|---|---|---|
| workerRealmId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the behavior of clearing the realm with an empty string, which is useful. However, it does not mention potential side effects, error conditions (e.g., invalid realm ID), or whether the operation is idempotent. For a tool with zero annotations, more behavioral detail would be warranted.
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 with no wasted words. The first sentence states the primary action, and the second provides additional context. 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's low complexity (1 parameter, no output schema, no nested objects), the description covers the essential aspects: purpose, usage, and a special behavior. It is missing a brief note about parameter format or return value, but for a simple setter tool, this 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?
The input schema has one required string parameter 'workerRealmId' with 0% description coverage in the schema. The description adds important meaning: 'Pass empty string to clear.' This clarifies that an empty string is a valid input for clearing, which is not obvious from the schema alone. It does not, however, explain what constitutes a valid non-empty realm ID.
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 ('set'), the resource ('active worker realm'), and includes a special case ('pass empty string to clear'). It also mentions its role as default target for hook tools, distinguishing it from sibling tools like select_frame and select_page.
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 this tool: 'Used as default target by hook tools.' This implies that select_worker should be called before using hook tools. It lacks explicit 'when not to use' or alternatives, but the guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set a breakpoint by source URL + line (+ optional column). columnTolerance > 0 enables multi-hit auto-resume until the paused column falls within ± tolerance of the requested column.
| Name | Required | Description | Default |
|---|---|---|---|
| sourceUrl | Yes | ||
| line | Yes | ||
| column | No | ||
| columnTolerance | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the columnTolerance parameter's behavior (multi-hit auto-resume until column within tolerance). No annotations are provided, so the description carries the full burden and adequately discloses this behavioral trait.
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 with no extraneous information. The first sentence states the purpose and required/optional parameters, and the second explains a key behavioral detail. Every sentence earns its place.
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 lack of annotations and output schema, the description provides sufficient context for a breakpoint tool: what it does, what parameters to use, and special behavior of columnTolerance. It could mention return value or error conditions 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?
Schema documentation coverage is 0%, so the description must add meaning. It describes all four parameters: sourceUrl, line, column, and columnTolerance, with an explanation of columnTolerance. However, it does not specify the format of sourceUrl or numbering convention for line/column.
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 sets a breakpoint using source URL, line, and optional column. It uses specific verbs and resources, distinguishing it from sibling tools like list_breakpoints and remove_breakpoint.
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 for pausing execution at a specific line but does not provide explicit guidance on when to use this versus alternatives like set_breakpoint_on_text. No exclusion criteria or context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set a breakpoint by searching for a text string in cached sources (+ optional sourceUrl filter). columnTolerance > 0 enables multi-hit auto-resume.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| sourceUrl | No | ||
| columnTolerance | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It mentions 'cached sources' and 'auto-resume' but does not disclose side effects, permissions, or error states. 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?
Two sentences, no wasted words. Core function front-loaded, parameter explanation follows. Highly 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?
Covers core usage and optional parameters. Missing details on return values (breakpoint ID) and prerequisites (sources must be cached). Reasonably complete for a simple 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 coverage is 0%, but the description explains all three parameters: text (search string), sourceUrl (optional filter), and columnTolerance (enables auto-resume). This fully compensates for missing schema 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 verb 'Set' and resource 'breakpoint by searching for a text string in cached sources', distinguishing it from sibling tools like set_breakpoint (by location) and break_on_xhr.
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?
It explains when to use columnTolerance (multi-hit auto-resume) but does not explicitly state when to prefer this over alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enable or disable CSP enforcement for a browsing context. Per-context scope via BiDi browsingContext.setBypassCSP — when enabled=false, bypass is set so inline injections succeed.
| Name | Required | Description | Default |
|---|---|---|---|
| enabled | Yes | ||
| contextId | 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 of behavioral disclosure. It reveals that setting 'enabled=false' enables bypass for inline injections, which is significant. However, it does not discuss reversibility, persistence, or security implications beyond that. The behavioral insight is useful but incomplete.
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, consisting of two tight sentences. Every word adds value: the first states the core action, the second provides technical context and behavioral effect. There is no redundancy or filler, making it efficient for an AI agent 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 has two parameters, no output schema, and no annotations, the description adequately covers the main behavior but leaves gaps. It explains the effect of 'enabled' and the per-context scope, but does not describe the 'contextId' parameter explicitly, fail conditions, or return behavior. It is moderately complete but missing details for full agent understanding.
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 schema description coverage at 0%, the description must compensate for missing parameter documentation. It clarifies the 'enabled' parameter as a boolean controlling CSP enforcement, but does not explicitly describe the 'contextId' parameter (only implying it via 'per-context scope'). This leaves the 'contextId' parameter's role and syntax unclear, which is insufficient for full understanding.
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 ('Enable or disable CSP enforcement') and identifies the resource ('browsing context'). It provides a specific verb and resource, making the purpose unambiguous. It also references the underlying BiDi command, adding precision. While it doesn't explicitly differentiate from siblings, the unique functionality of CSP enforcement is distinct enough.
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 per-context scope and the effect of 'enabled=false', giving some context for usage. However, it does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. The guidance is implied but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enable or disable JavaScript execution for a browsing context. Per-context scope via BiDi emulation.setScriptingEnabled — does not affect other tabs.
| Name | Required | Description | Default |
|---|---|---|---|
| enabled | Yes | ||
| contextId | 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 discloses scoping (per-context) and non-interference with other tabs, but does not mention potential side effects like page reload, persistence, or reversibility.
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: one sentence plus a brief technical note. Every word adds value, no fluff.
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 boolean toggle with no output schema, the description covers the core behavior and scope. However, it lacks details on default behavior when contextId is omitted and does not mention the return value or success indication.
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%, yet the description provides no explanation of the parameters 'enabled' or 'contextId'. The description does not clarify what each parameter does, which is a significant gap for a tool with only two parameters.
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 verb (enable/disable) and resource (JavaScript execution for a browsing context). The description distinguishes the tool from siblings by noting it's per-context and does not affect other tabs, which is unique among sibling 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?
Indicates when to use via 'Per-context scope' and mentions it corresponds to BiDi emulation.setScriptingEnabled. However, it does not explicitly state when not to use 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.
Override the User-Agent string for a browsing context via BiDi emulation.setUserAgentOverride.
| Name | Required | Description | Default |
|---|---|---|---|
| userAgent | Yes | ||
| contextId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It indicates mutation ('override') but does not explain side effects, reversibility, auth requirements, or the implications of 'BiDi emulation.' The agent is left uninformed about 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, which is concise. However, the redundant 'setUserAgentOverride.' at the end wastes space and could be removed. Front-loading is adequate.
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, moderate parameter count (2), and lack of annotations, the description is insufficient. It does not explain the return value, error conditions, or how the contextId parameter works. A complete description should include these details.
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 0%, so the description must add meaning to the parameters. It provides no information about 'userAgent' or 'contextId,' leaving the agent to infer from names alone. This is a significant gap.
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 the specific action: overriding the User-Agent string for a browsing context. It is clear and distinguishes the tool from siblings like set_javascript_enabled or set_csp_enabled. However, the trailing 'setUserAgentOverride.' is redundant and slightly confusing.
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 (e.g., other emulation or override tools). No context about prerequisites, such as needing an active browsing context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Step into the current function call.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure, but it is extremely brief. It does not explain the effects of stepping into a function call (e.g., pausing at the first line, entering a new call frame), leaving significant behavioral ambiguity.
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 with a single sentence that directly states the action. However, it lacks structure and could be improved by adding details about prerequisites or effects 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?
The description is incomplete given the tool's complexity. It does not mention prerequisites (e.g., must be paused at a function call site) or outcomes (e.g., moves to the first line of the function), which are essential for an agent to use 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?
There are no parameters, so the description does not need to add parameter information. The schema coverage is trivially 100%, and the baseline score for zero-parameter tools is 4.
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 'Step into' and the resource 'the current function call', indicating a debugging action. However, it does not distinguish this tool from sibling tools like 'step_over' or 'step_out', which have similar purposes.
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. The description only states what the tool does, leaving the agent to infer appropriate usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Step out of the current function, resuming until the caller.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates that the tool resumes execution until the caller, which is the main behavioral trait. No annotations are provided, and the description does not disclose potential side effects or 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 a single sentence that is concise and front-loaded with the 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?
For a simple tool with no parameters and no output schema, the description is adequate. It could be enhanced by explicitly stating that it only works when paused in a function, but that is implied.
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 baseline 4 applies. The description does not need to add parameter information.
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 ('Step out of the current function') and the result ('resuming until the caller'). It distinguishes from sibling tools like step_into and step_over.
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 paused inside a function and wanting to return to the caller, but it does not explicitly state when to use vs alternatives like step_into or step_over.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Step over the current statement (skips into function calls).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only gives a vague, partially incorrect behavior hint. It fails to disclose execution state changes, requirement of being paused, or other side effects.
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 short sentence, well-structured and without redundant words. However, it lacks necessary details, but for conciseness alone it scores well.
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 debugging nature, with no output schema or annotations, the description is insufficient. It omits critical context like the need to be in a paused state and the effect on the execution flow.
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 zero parameters, so the schema coverage is 100%. The description adds no parameter info because none are needed. Baseline score of 4 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?
The description states the action 'step over the current statement' but the parenthetical '(skips into function calls)' is misleading because stepping over typically does not enter functions; it executes the function call and moves to the next line. This reduces clarity.
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 compared to siblings like 'step_into' or 'step_out'. The description does not specify prerequisites (e.g., must be paused) or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop a monitor previously started by monitor_events.
| Name | Required | Description | Default |
|---|---|---|---|
| monitorId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It merely states the action without explaining any side effects, reversibility, or state changes upon stopping the monitor.
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, concise and front-loaded. No unnecessary words are present.
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?
With no annotations, no output schema, and a single parameter, the description is minimal and does not cover return values, error conditions, or prerequisites. For a simple stop action, it is adequate but lacks 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?
Schema description coverage is 0%, and the description does not elaborate on the 'monitorId' parameter. It does not explain how to obtain the ID (e.g., from monitor_events response) or its expected format, leaving ambiguity.
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 ('Stop') and the resource ('monitor'), and distinguishes it from siblings by referencing 'monitor_events' as the counterpart that starts the monitor.
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 context by specifying 'previously started by monitor_events', but does not explicitly exclude other scenarios or compare to alternatives. It provides clear context for when to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use an LLM to produce a bullet-list summary of a JS snippet. Returns LlmNotConfigured when no provider is set.
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | ||
| maxBullets | No | ||
| model | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses one behavioral outcome (LlmNotConfigured error) but does not mention side effects, network requirements, or read-only nature. Partial 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?
Two sentences, highly concise, with clear front-loading of purpose. No extra 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 3 parameters, no output schema, and complexity of an LLM call, the description is incomplete. It does not explain output beyond bullet-list, potential slowness, or what constitutes a 'JS snippet'. Missing details for effective 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 0%, and the description adds no information about the three parameters (source, maxBullets, model). It fails to explain their meaning or usage.
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 'summarize' and resource 'JS snippet', with output format 'bullet-list'. It also mentions an error condition. However, it does not distinguish from sibling tool 'understand_code' which may perform similar analysis.
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 vs alternatives like 'understand_code' or 'analyze_target'. The description lacks context on scenarios or exclusions.
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 active page as base64 PNG.
| Name | Required | Description | Default |
|---|---|---|---|
| contextId | 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 mentions the output format (base64 PNG) but omits details like whether it captures the full viewport, scrolls, or requires user interaction. The optional parameter 'contextId' is not explained.
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 concise sentence. However, it could be slightly expanded to include the role of the optional parameter without losing efficiency. Still, it avoids fluff.
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, no output schema, and a parameter with 0% coverage, the description is severely incomplete. It does not explain the purpose of the optional contextId, the dimensions of the screenshot, or any side effects. The agent cannot effectively use this tool based solely on the description.
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%, meaning neither the schema nor the description explains the 'contextId' parameter. The tool description does not add any meaning beyond the schema, so the agent has no clue what 'contextId' does or when to provide 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 action (take a screenshot), the target (active page), and the output format (base64 PNG). It is specific and distinguishes from all sibling tools, none of which involve screenshots.
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. The description does not mention any prerequisites, context requirements, or scenarios where this tool is preferred or should be avoided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Trace a function: hook with capture preset [args, return, stack]. Convenience wrapper for call-chain debugging.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| targetExpr | Yes | ||
| target | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the capture preset (args, return, stack) and that it hooks a function, but lacks details on side effects, persistence, or how the tracing data is returned. Given no annotations, this provides moderate transparency but leaves gaps.
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 with two short sentences, front-loaded with the primary purpose. No wasted words; every part 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 3 parameters, no output schema, and no annotations, the description is incomplete. It does not explain parameters, return value, or side effects such as whether the hook is temporary or needs removal. Only the capture preset is mentioned.
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 fails to explain the three parameters (name, targetExpr, target). It only mentions 'Trace a function' and 'hook with capture preset', which does not clarify parameter roles or semantics beyond the schema property names.
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 'Trace a function' with a specific verb and resource, and mentions 'hook with capture preset [args, return, stack]' providing the scope. It distinguishes itself as a convenience wrapper for call-chain debugging from siblings like hook_function.
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 for simple call-chain debugging via 'Convenience wrapper', but does not explicitly state when to use this tool versus alternatives like hook_function, nor does it provide when-not-to-use or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Type text into a DOM element identified by its sharedId.
| Name | Required | Description | Default |
|---|---|---|---|
| sharedId | Yes | ||
| text | Yes | ||
| clearFirst | No | ||
| contextId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description must cover behavior. It lacks mention of side effects, error handling, or what happens if element is not found or not focusable.
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, front-loaded with purpose. No wasted words, but could benefit from 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?
No output schema and 4 parameters without explanations. Incomplete for a DOM modification tool; missing return info, error cases, 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?
Schema coverage is 0%. Description only references sharedId implicitly, ignoring text, clearFirst, and contextId. No value added over parameter names.
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 action (type text) and target (DOM element by sharedId). Specific verb and resource, but could be more precise about input fields.
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 vs. siblings like click_element or wait_for_element. No mention of prerequisites or contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use an LLM to explain what a JS snippet does. Returns LlmNotConfigured cleanly when no provider is set.
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | ||
| question | No | ||
| model | No | ||
| maxTokens | 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 discloses the use of an LLM and clean error handling for missing configuration. It does not mention other behavioral aspects like rate limits, side effects, or read-only nature.
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 core purpose and a key behavior.
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 4 parameters, no output schema, and no annotations, the description is too minimal. It fails to explain parameter purposes, output format, or use cases beyond the basic 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%, and the description adds no information about the parameters (source, question, model, maxTokens). The agent gets no guidance beyond the schema structure.
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 the tool uses an LLM to explain a JS snippet. It includes a specific behavioral note about error handling. However, it does not differentiate from similar siblings like 'summarize_code' or 'deobfuscate_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?
The description explicitly says when to use (explain JS snippet) and mentions a clean error return for missing LLM. It does not provide when-not-to-use or alternative tools, but the intended use is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Alias for remove_hook (kept for compatibility with the original CDP project naming).
| Name | Required | Description | Default |
|---|---|---|---|
| hookId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only says 'alias' without disclosing behavioral traits (e.g., destructive nature, side effects, or return behavior). Minimal transparency for a tool that likely modifies 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?
Single concise sentence that efficiently states the tool's role as an alias. No extraneous content, but could be more informative without sacrificing brevity.
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?
With a single parameter and no output schema, the description is too minimal. It does not specify what the tool does (e.g., removes a hook) or how it behaves, leaving the agent to rely on the sibling tool's documentation.
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%; the description does not explain the 'hookId' parameter. The agent must infer its meaning from the parameter name alone. No added semantics 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?
Description states it is an alias for 'remove_hook', implying it removes a function hook. However, it does not explicitly state the action (e.g., 'removes a hook') and relies on knowledge of the sibling tool, making the purpose somewhat vague.
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 'remove_hook' or other hook-related tools. The description only mentions compatibility without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wait for a CSS selector to match an element on the active page.
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | ||
| timeoutMs | No | ||
| state | No | ||
| contextId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It fails to specify timeout behavior, what happens on failure, or the meaning of the 'state' parameter. Critical details 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?
Extremely short, but severely under-specified for a tool with 4 parameters. Conciseness should not sacrifice essential 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 the complexity (4 parameters, no annotations, no output schema), the description is grossly incomplete. It fails to cover key aspects like parameter details, return behavior, and error conditions.
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 tool description adds no meaning for any of the 4 parameters. It only mentions 'CSS selector' implicitly for the 'selector' field.
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 (wait) and the resource (CSS selector matching an element). It distinguishes from other tools like query_dom which may not wait. However, it doesn't explicitly differentiate from siblings that also use selectors.
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 other similar tools (e.g., clicking or querying). No exclusions or context provided.
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.
v0.1.0analyze_targetanalyze_websocket_messagesbreak_on_xhrcheck_browser_healthclick_elementcollect_codecollection_diffcreate_hookdelete_session_statedeobfuscate_codedetect_cryptodiff_env_requirementsdump_session_stateevaluate_on_callframeevaluate_scriptexport_rebuild_bundleexport_session_reportfind_clickable_elementsfind_in_scriptget_console_messageget_dom_structureget_hook_dataget_network_requestget_paused_infoget_performance_metricsget_request_initiatorget_script_sourceget_storageget_websocket_messageget_websocket_messageshook_functioninject_hookinject_preload_scriptinject_stealthinject_stealth_hookinject_stealth_to_workersinspect_objectlist_breakpointslist_console_messageslist_frameslist_hookslist_network_requestslist_pageslist_scriptslist_session_stateslist_stealth_featureslist_stealth_presetslist_websocket_connectionslist_workersload_session_statemonitor_eventsnavigate_pagenew_pagepausequery_domrecord_reverse_evidenceremove_breakpointremove_hookremove_xhr_breakpointrestore_session_stateresumerisk_panelsave_session_statesearch_in_scriptssearch_in_sourcesselect_frameselect_pageselect_workerset_breakpointset_breakpoint_on_textset_csp_enabledset_javascript_enabledset_user_agentstep_intostep_outstep_overstop_monitorsummarize_codetake_screenshottrace_functiontype_textunderstand_codeunhook_functionwait_for_elementMany tools overlap in purpose, such as multiple injectors (inject_hook, inject_preload_script, inject_stealth, inject_stealth_hook), breakpoint setters (set_breakpoint, set_breakpoint_on_text), and search tools (search_in_scripts, search_in_sources, find_in_script). Convenience wrappers like hook_function, trace_function, and unhook_function add ambiguity. An agent would struggle to select the correct tool.
Tool names mostly follow verb_noun in snake_case (e.g., analyze_target, list_scripts), but inconsistencies exist: mix of 'get_' vs 'list_' for retrieval, 'find_' vs 'search_' for searches, and some compound names (break_on_xhr, type_text) break the pattern. Overall moderately consistent but deviations are notable.
84 tools is far beyond typical MCP server scope (3-15 tools). This extreme count suggests scope creep, many niche utilities, and overlapping functionality. The number makes the server unwieldy and poorly scoped for its stated purpose.
The tool set covers a broad range of reverse engineering tasks (debugging, script analysis, deobfuscation, stealth, networking, sessions). However, gaps exist: limited DOM manipulation (only click, type_text), no storage value access, and many tools marked as v1 or M3, indicating incomplete implementation. Comprehensive but not fully polished.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for understanding Javascript internals from ECMAScript specification.
MCP server to assist with JxBrowser development.
Security research canary remote MCP server for owned-account testing.
MCP server for ScanMalware.com URL scanning, malware detection, and analysis.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/wukaka/camoufox-jsreverser-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
