機能 | Direct CDP (v1.4.0) ⭐ 推奨 | Puppeteerベース (v1.2.0) |
依存関係 |
| Puppeteer + MCP SDK (163パッケージ) |
メモリ使用量 | 低い (ネイティブChromium) | 高い (Node.jsラッパーのオーバーヘッド) |
起動時間 | 速い (直接WebSocket) | 遅い (Puppeteerの初期化) |
ブラウザ制御 | ネイティブChrome DevTools Protocol | Puppeteer抽象化レイヤー |
ARM64最適化 | 完全ネイティブARM64 | PuppeteerのARM64サポートに依存 |
デバッグ | 生のCDPメッセージを表示可能 | Puppeteerにより抽象化 |
メンテナンス | Chromeプロトコルの変更のみ | Puppeteer + Chromeプロトコルの変更 |
パフォーマンス | 最高 (直接通信) | 良好 (ラップされた通信) |
Direct CDP (v1.4.0) を使用すべき場合:
✅ 最大限のパフォーマンスと最小限の依存関係を求める場合
✅ ネイティブARM64最適化が必要な場合
✅ Chrome DevTools Protocolを直接制御したい場合
✅ 本番環境の自動化システムを構築している場合
✅ 最新機能と最速のアップデートを求める場合
Puppeteerベース (v1.2.0) を使用すべき場合:
✅ 既存のPuppeteerコードから移行する場合
✅ Puppeteer APIの抽象化を好む場合
✅ Direct CDPでまだ実装されていない特定のPuppeteer機能が必要な場合
✅ 既存ワークフローへの変更を最小限に抑えたい場合
# Switch to Direct CDP (recommended)
git checkout direct-chromium
npm install # Only 89 packages
# Switch back to Puppeteer version
git checkout main
npm install # 163 packagesRelated MCP server: Glance
このリポジトリには、対象読者に合わせた複数のドキュメントが含まれています。
📖 技術README - 以下を含む包括的な技術ドキュメント:
アーキテクチャ図とAPIリファレンス
パフォーマンスベンチマークと最適化ガイド
CI/CD統合例とE2Eテストワークフロー
高度なデバッグとカスタマイズオプション
📖 Raspberry Pi README - 以下を特徴とする予算重視のガイド:
480ドルで構築するAI開発環境
ノーコードSaaS開発ワークフロー
実践的なスタートアップのユースケースとROI分析
グローバルなアクセシビリティとメイカームーブメントへの焦点
開発者: 技術ドキュメントへ →
メイカー: Raspberry Piガイドへ →
すべての方: 以下のユニバーサルセットアップと使用方法へ
🤖 ネイティブARM64ブラウザ自動化
Chrome DevTools Protocolの直接実装
完全なブラウザ制御のための27個の包括的なMCPツール
Raspberry PiおよびApple Siliconアーキテクチャ向けに最適化
壊れやすいx86_64 Puppeteerバイナリへの依存なし
⚡ 高パフォーマンスアーキテクチャ
依存関係はわずか2つ (ws + MCP SDK) (Puppeteerの163パッケージと比較)
低いメモリ使用量と高速な起動時間
Chromeとの直接WebSocket通信
包括的なログ記録と監査機能
🛠️ エンタープライズ対応の開発環境
コンソール/ネットワーク監視を備えた完全なデバッグスイート
アクセシビリティ、SEO、パフォーマンス監査を内蔵
CI/CD統合例とE2Eテストワークフロー
クロスプラットフォーム互換性 (Linux ARM64, macOS Apple Silicon)
💰 手頃な価格のイノベーションプラットフォーム
500ドル未満で構築できる完全なAI開発環境
5万ドル以上のエンタープライズワークステーションと同等の機能
世界中のメイカーやスタートアップが利用可能
定期的なクラウドコストなし - インフラを自前で所有
# Install system dependencies
sudo apt update
sudo apt install chromium-browser nodejs npm python3
# Verify Chromium works
chromium-browser --versiongit clone https://github.com/nfodor/mcp-chromium-arm64
cd mcp-chromium-arm64
npm install
chmod +x *.py *.sh# Verify it works immediately after install:
python3 -c "import sys; sys.path.append('.'); import arm64_browser; print('[OK] ARM64 Browser Works!' if 'error' not in arm64_browser.navigate('https://example.com').lower() else '[FAIL] Failed')"期待される結果: [OK] ARM64 Browser Works!
# Quick demo with immediate visible results (30 seconds)
python3 instant_demo.py
# Or comprehensive demo showing all capabilities (2-3 minutes)
./run_demo.sh# Test MCP server directly
echo '{"jsonrpc":"2.0","method":"tools/list","id":1}' | node index.js
# Test Python wrapper
python3 simple_browser.pynavigate - ページ読み込みを伴うURLへの移動
screenshot - PNGスクリーンショットのキャプチャ (ページ全体またはビューポート)
click - CSSセレクタによる要素のクリック (正確な位置指定)
fill - テキストや値による入力フィールドの埋め込み
hover - ドロップダウン/ツールチップ操作のための要素へのホバー
select - 値によるドロップダウンオプションの選択
evaluate - JavaScriptの実行と結果の取得
get_content - ページのHTMLまたはプレーンテキストコンテンツの抽出
get_console_logs - ブラウザコンソール出力の取得
get_console_errors - コンソールエラーメッセージのみの取得
get_network_logs - すべてのネットワークリクエスト/レスポンスの監視
get_network_errors - 失敗したネットワークリクエスト (4xx/5xx) の追跡
wipe_logs - メモリから保存されたすべてのログをクリア
get_selected_element - 現在フォーカスされている要素に関する情報の取得
emulate_device - 17個のプリセットまたはカスタムビューポート/UA/DPR/タッチによるモバイルデバイスエミュレーション (ランドスケープサポート)
iPhones: iphone-16, iphone-16-pro, iphone-16-pro-max, iphone-16e, iphone-15, iphone-15-pro-max, iphone-se
Pixels: pixel-9, pixel-9-pro, pixel-9-pro-xl, pixel-9-pro-fold
Samsung: galaxy-s24, galaxy-s24-ultra, galaxy-z-fold-5
Tablets: ipad-air-m2, ipad-pro-13, galaxy-tab-s9
reset_emulation - デバイスエミュレーションをデスクトップモードにリセット
start_screencast - CDPスクリーンキャストによるブラウザアクティビティの録画開始 (フォーマット、品質、解像度、フレームスキップを設定可能)
stop_screencast - 録画を停止し、ffmpeg経由で MP4、GIF、または WebM にエンコード (フレームタイムスタンプからFPSを自動検出)
screencast_status - 録画ステータス、フレーム数、経過時間の確認
run_accessibility_audit - 代替テキスト、ラベル、見出し、コントラストのチェック
run_performance_audit - 読み込み時間、メモリ使用量、リソースの測定
run_seo_audit - タイトル、メタディスクリプション、H1タグ、canonicalの検証
run_best_practices_audit - HTTPS、非推奨HTML、ビューポートのチェック
run_nextjs_audit - Next.js固有の最適化チェック
run_debugger_mode - 包括的なデバッグ情報
run_audit_mode - すべての監査をまとめて実行し、要約を表示
close_browser - Chromiumプロセスのクリーンな終了
# Test individual tools directly
echo '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"navigate","arguments":{"url":"https://example.com"}}}' | node index.js
echo '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"evaluate","arguments":{"script":"document.title"}}}' | node index.js
echo '{"jsonrpc":"2.0","id":3,"method":"tools/call","params":{"name":"screenshot","arguments":{"name":"debug.png"}}}' | node index.js# Start recording, interact with the page, then stop and encode
# 1. Start screencast
echo '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"start_screencast","arguments":{"format":"jpeg","quality":80,"maxWidth":1280,"maxHeight":720}}}' | node index.js
# 2. Perform actions (navigate, click, fill, etc.)
echo '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"navigate","arguments":{"url":"https://example.com"}}}' | node index.js
# 3. Check recording progress
echo '{"jsonrpc":"2.0","id":3,"method":"tools/call","params":{"name":"screencast_status","arguments":{}}}' | node index.js
# 4. Stop and encode to MP4
echo '{"jsonrpc":"2.0","id":4,"method":"tools/call","params":{"name":"stop_screencast","arguments":{"output":"mp4","name":"my-demo"}}}' | node index.js
# Output: /tmp/my-demo.mp4
# Encode as GIF instead (2-pass palette for quality)
echo '{"jsonrpc":"2.0","id":4,"method":"tools/call","params":{"name":"stop_screencast","arguments":{"output":"gif","name":"bug-repro"}}}' | node index.js
# Output: /tmp/bug-repro.gif
# Or WebM (VP9)
echo '{"jsonrpc":"2.0","id":4,"method":"tools/call","params":{"name":"stop_screencast","arguments":{"output":"webm"}}}' | node index.js要件: システムに
ffmpegがインストールされていること。FPSはCDPフレームタイムスタンプから自動検出されます。GIF出力は適切なファイルサイズを維持するため15fpsに制限されています。
# Emulate iPhone 16 Pro
echo '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"emulate_device","arguments":{"device":"iphone-16-pro"}}}' | node index.js
# Emulate in landscape mode
echo '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"emulate_device","arguments":{"device":"ipad-pro-13","landscape":true}}}' | node index.js
# Custom viewport with DPR
echo '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"emulate_device","arguments":{"width":390,"height":844,"deviceScaleFactor":3,"mobile":true}}}' | node index.js
# Reset back to desktop
echo '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"reset_emulation","arguments":{}}}' | node index.js# Navigate to a page, then check console logs
echo '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"get_console_logs","arguments":{}}}' | node index.js
# Get only errors
echo '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"get_console_errors","arguments":{}}}' | node index.js
# Check network activity (all requests with status codes)
echo '{"jsonrpc":"2.0","id":3,"method":"tools/call","params":{"name":"get_network_logs","arguments":{}}}' | node index.js
# Check for failed requests (4xx/5xx)
echo '{"jsonrpc":"2.0","id":4,"method":"tools/call","params":{"name":"get_network_errors","arguments":{}}}' | node index.js
# Clear all logs when done
echo '{"jsonrpc":"2.0","id":5,"method":"tools/call","params":{"name":"wipe_logs","arguments":{}}}' | node index.js# Run all audits at once (accessibility + performance + SEO + best practices + Next.js)
echo '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"run_audit_mode","arguments":{}}}' | node index.js
# Or run individual audits
echo '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"run_accessibility_audit","arguments":{}}}' | node index.js
echo '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"run_performance_audit","arguments":{}}}' | node index.js
echo '{"jsonrpc":"2.0","id":3,"method":"tools/call","params":{"name":"run_seo_audit","arguments":{}}}' | node index.js
# Get full debug info (URL, viewport, memory, timing)
echo '{"jsonrpc":"2.0","id":4,"method":"tools/call","params":{"name":"run_debugger_mode","arguments":{}}}' | node index.js# Get info about the currently focused element
echo '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"get_selected_element","arguments":{}}}' | node index.js
# Returns: tagName, id, className, textContent, value, and a CSS selector# Manual CDP connection test
node -e "
const { WebSocket } = require('ws');
const { spawn } = require('child_process');
const chrome = spawn('/usr/bin/chromium-browser', [
'--headless', '--remote-debugging-port=9227'
]);
setTimeout(() => {
fetch('http://localhost:9227/json')
.then(r => r.json())
.then(tabs => {
console.log('Available tabs:', tabs.length);
const ws = new WebSocket(tabs[0].webSocketDebuggerUrl);
ws.on('open', () => {
console.log('CDP WebSocket connected!');
ws.send(JSON.stringify({id: 1, method: 'Runtime.evaluate', params: {expression: '2+2'}}));
});
ws.on('message', (data) => {
console.log('CDP Response:', JSON.parse(data));
chrome.kill();
process.exit(0);
});
});
}, 2000);
"# Monitor system resources during operation
htop &
echo '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"navigate","arguments":{"url":"https://httpbin.org/delay/5"}}}' | time node index.js
# Check memory usage
ps aux | grep chromium
free -h# Check if debugging port is accessible
curl -s http://localhost:9222/json | jq '.[] | {id, title, type}'
# Monitor WebSocket traffic (install websocat)
websocat ws://localhost:9222/devtools/page/[TAB_ID] --text -v# Symptoms: "CDP command timeout" errors
# Check if chrome debugging port is running
lsof -i :9222
# Test manual connection
node -e "
const { WebSocket } = require('ws');
const ws = new WebSocket('ws://localhost:9222/devtools/browser');
ws.on('open', () => console.log('✓ WebSocket OK'));
ws.on('error', (e) => console.log('✗ WebSocket Error:', e.message));
setTimeout(() => process.exit(0), 2000);
"# Symptoms: Browser won't start or hangs
# Kill any stuck processes
pkill -f chromium-browser
pkill -f remote-debugging-port
# Test chrome startup manually
timeout 10s /usr/bin/chromium-browser --headless --remote-debugging-port=9223 --no-sandbox
# Check chrome logs
journalctl --user -u chromium --since "1 hour ago"# Debug CSS selectors interactively
echo '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"evaluate","arguments":{"script":"document.querySelectorAll(\"button\").length"}}}' | node index.js
# Get element information
echo '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"evaluate","arguments":{"script":"document.querySelector(\"#mybutton\") ? \"found\" : \"not found\""}}}' | node index.js# Monitor memory during operation
watch -n 1 'ps aux | grep -E "(chromium|node)" | grep -v grep'
# Chrome memory debugging
echo '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"evaluate","arguments":{"script":"JSON.stringify(performance.memory)"}}}' | node index.js# Set environment variables for detailed output
export DEBUG=puppeteer:*
export NODE_ENV=development
# Run with detailed Chrome logs
/usr/bin/chromium-browser --headless --enable-logging --log-level=0 --remote-debugging-port=9222# Create debug version with message logging
cp index.js debug-index.js
# Add to sendCDPCommand method:
# console.log('→ CDP:', JSON.stringify(command));
# console.log('← CDP:', JSON.stringify(response));
node debug-index.js# Connect regular Chrome DevTools to the headless instance
# 1. Start the MCP server
# 2. Open regular Chrome/Chromium
# 3. Navigate to: chrome://inspect
# 4. Click "Configure..." and add localhost:9222
# 5. Click "inspect" on the page you want to debug# Direct CDP (v1.3.0)
time echo '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"evaluate","arguments":{"script":"Date.now()"}}}' | node index.js
# Puppeteer version (v1.2.0)
git checkout main
time echo '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"evaluate","arguments":{"script":"Date.now()"}}}' | node index.js# Before operation
free -h && ps aux | grep -E "(chromium|node)" | grep -v grep
# During operation (run in another terminal)
watch -n 1 'echo "=== $(date) ===" && free -h && echo && ps aux | grep -E "(chromium|node)" | grep -v grep'エラー | 原因 | 解決策 |
| WebSocket接続の切断 | ブラウザを再起動し、ポートの可用性を確認 |
| Chromeが完全に起動していない | 起動遅延を増やし、Chromeプロセスを確認 |
| CSSセレクタが無効 |
|
| デバッグポートがブロックされている | ファイアウォールを確認し、既存のChromeプロセスを終了 |
| ページ読み込みの問題 | ネットワークを確認し、タイムアウトを増やし、より単純なページを試す |
// In index.js, add to tools array:
{
name: 'my_custom_tool',
description: 'My custom functionality',
inputSchema: {
type: 'object',
properties: {
param: { type: 'string', description: 'Parameter description' }
},
required: ['param']
}
}
// Add to switch statement in CallToolRequestSchema handler:
case 'my_custom_tool':
return await this.myCustomTool(args.param);
// Implement the method:
async myCustomTool(param) {
await this.ensureChromium();
const result = await this.sendCDPCommand('Page.navigate', { url: param });
return { content: [{ type: 'text', text: `Custom result: ${result}` }] };
}# Set browser window size (default: 1280,720)
export CHROMIUM_WINDOW_SIZE=1920,1080// Modify in startChromium() method:
const customArgs = [
'--headless',
'--no-sandbox',
'--disable-extensions',
'--disable-plugins',
'--disable-background-timer-throttling',
'--disable-backgrounding-occluded-windows',
'--disable-renderer-backgrounding',
'--remote-debugging-port=9222',
'--window-size=1920,1080', // Custom viewport
'--user-agent=CustomUA/1.0', // Custom user agent
'--disable-web-security', // For CORS testing
'--allow-running-insecure-content' // For mixed content
];プラットフォーム | ステータス | Chromeパス | インストール方法 | メモ |
Linux ARM64 ✅ | 完全サポート |
|
| Raspberry Pi OSでテスト済み |
macOS Apple Silicon ⚠️ | 修正が必要 |
| Googleからダウンロードまたは | パスとフラグの更新が必要 |
Windows ARM64 ❓ | 未テスト |
| Googleからダウンロード | Windows固有の変更が必要 |
# Install Homebrew if not already installed
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
# Install Node.js and Chromium
brew install node chromium --no-quarantine現在、サーバーはLinux ARM64向けに最適化されています。macOS互換性のために index.js を変更してください:
// Detect platform and set appropriate chrome path
function getChromePath() {
const platform = process.platform;
switch(platform) {
case 'linux':
return '/usr/bin/chromium-browser';
case 'darwin': // macOS
// Try multiple possible paths
const macPaths = [
'/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
'/Applications/Chromium.app/Contents/MacOS/Chromium',
'/opt/homebrew/bin/chromium'
];
for (const path of macPaths) {
if (require('fs').existsSync(path)) {
return path;
}
}
throw new Error('Chrome/Chromium not found on macOS');
case 'win32':
return 'C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe';
default:
throw new Error(`Unsupported platform: ${platform}`);
}
}
// Update startChromium method
async startChromium() {
const chromePath = getChromePath();
const platform = process.platform;
// Platform-specific arguments
const baseArgs = [
'--headless',
'--disable-extensions',
'--disable-plugins',
`--remote-debugging-port=${debuggingPort}`,
'--no-first-run',
'--disable-gpu',
'--window-size=1280,720'
];
// Add Linux-specific sandbox flags
if (platform === 'linux') {
baseArgs.push('--no-sandbox', '--disable-setuid-sandbox');
}
// Add macOS-specific flags if needed
if (platform === 'darwin') {
baseArgs.push('--disable-dev-shm-usage');
}
chromiumProcess = spawn(chromePath, baseArgs);
// ... rest of method
}# Remove quarantine flag if downloading manually
sudo xattr -r -d com.apple.quarantine /Applications/Chromium.app
# Or install via Homebrew with no-quarantine flag
brew install chromium --no-quarantine# Option 1: Use Google Chrome (recommended)
# Download from: https://www.google.com/chrome/
# Path: /Applications/Google Chrome.app/Contents/MacOS/Google Chrome
# Option 2: Use Chromium via Homebrew
brew install chromium --no-quarantine
# Path: /opt/homebrew/bin/chromium# Ensure Chrome has required permissions
# System Preferences > Security & Privacy > Privacy tab
# Grant Camera, Microphone access if needed for specific use casesnode -e "
console.log('Platform:', process.platform);
console.log('Architecture:', process.arch);
const fs = require('fs');
const paths = {
linux: '/usr/bin/chromium-browser',
darwin: '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
win32: 'C:\\\\Program Files\\\\Google\\\\Chrome\\\\Application\\\\chrome.exe'
};
const chromePath = paths[process.platform];
console.log('Expected Chrome path:', chromePath);
console.log('Chrome exists:', fs.existsSync(chromePath));
"# Test basic functionality across platforms
echo '{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"tools/call\",\"params\":{\"name\":\"evaluate\",\"arguments\":{\"script\":\"navigator.platform\"}}}' | node index.js
# Should return the current platform未テストですが、Windows ARM64サポートには以下が必要です:
// Windows-specific chrome path detection
case 'win32':
const winPaths = [
'C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe',
'C:\\Program Files (x86)\\Google\\Chrome\\Application\\chrome.exe',
process.env.LOCALAPPDATA + '\\Google\\Chrome\\Application\\chrome.exe'
];
// Similar path checking logic...プラットフォーム | 起動時間 | メモリ使用量 | メモ |
Linux ARM64 (Pi 4) | ~3-4秒 | ~150MB | 最適化済み、テスト済み |
macOS Apple Silicon | ~2-3秒 | ~200MB | CPUが速く、メモリが多い |
Windows ARM64 | 不明 | 不明 | ハードウェアに依存 |
完全なクロスプラットフォームサポートへの貢献を歓迎します！
macOSテスター: Apple Siliconでの提案された変更のテスト
Windows ARM64: Surface Pro Xなどのデバイスでのテスト
パフォーマンス最適化: プラットフォーム固有の最適化
インストールスクリプト: 各プラットフォーム向けの自動セットアップ
# Install Claude Code CLI if you haven't already
npm install -g @anthropic-ai/claude-code# From the project directory after cloning
claude mcp add chromium-arm64 "$(pwd)/mcp-wrapper.sh" --scope userclaude mcp list
# Should show: chromium-arm64: /path/to/mcp-wrapper.sh - ✓ ConnectedMCPサーバーを追加した後は、新しいClaudeセッションを開始する必要があります:
# Exit current session if in one
exit
# Start fresh session
claudeClaudeにchromium-arm64ツールを使用するよう指示してください:
List available MCP servers and use chromium-arm64 to navigate to https://example.com
Take a screenshot using the chromium-arm64 tool
Use chromium-arm64 to click the button with selector #submit
Fill the email field using chromium-arm64 with test@example.com
Record a screencast of the login flow and save it as a GIF
Emulate an iPhone 16 Pro and take a screenshot of the homepage
Run a full audit on https://example.com using chromium-arm64Playwright/Puppeteerを避けるために明示的に指示してください:
「chromium-arm64を使って移動して...」
「chromium-arm64ツールを使ってスクリーンショットを撮って」
「ブラウザを開いて」（壊れたPlaywrightが試される可能性があります）
「スクリーンショットを撮って」（壊れたPuppeteerが試される可能性があります）
Click an element on the page
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | CSS selector for the element to click |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Click an element' implies a user interaction that may trigger navigation or state changes, but it doesn't describe what happens after clicking (e.g., page reload, new window), error conditions, or performance considerations. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and target, making it immediately scannable and appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., success/failure, new page state), error handling, or behavioral nuances like waiting for elements to be clickable. Given the complexity of web interaction, 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?
Schema description coverage is 100%, with the single parameter 'selector' clearly documented as 'CSS selector for the element to click'. The description adds no additional parameter information beyond what the schema provides, so it meets the baseline for high 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 'Click an element on the page' clearly states the action (click) and target (element on page), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'select' or 'type' which also interact with page elements, so it doesn't reach the highest score.
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 'select' or 'type' from the sibling list. It doesn't mention prerequisites (e.g., needing an element to be clickable) or exclusions, leaving the agent with minimal context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Close the browser instance
| 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 carries full burden but offers minimal behavioral context. 'Close the browser instance' implies a destructive action that terminates the session, but it doesn't specify whether this is reversible, what happens to open tabs/data, or if authentication is affected. For a potentially destructive tool with zero annotation coverage, this is inadequate.
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, direct sentence with no wasted words. It's front-loaded with the core action and resource, making it immediately understandable. 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 tool that likely terminates a browser session (a significant action), the description is insufficient given no annotations or output schema. It doesn't explain what 'close' entails (e.g., graceful shutdown, data loss), return values, or error conditions. The simplicity of having no parameters doesn't compensate for the lack of behavioral 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 tool has zero parameters, and schema description coverage is 100% (empty schema). The description doesn't need to explain parameters, so it meets baseline expectations. No parameter information is missing or 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 action ('Close') and resource ('the browser instance'), making the purpose immediately understandable. It doesn't distinguish from siblings like 'navigate' or 'get_content', but the verb+resource combination is specific enough for basic understanding.
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 about when to use this tool versus alternatives. While the action is self-explanatory, there's no mention of prerequisites (e.g., must have an active browser session) or consequences (e.g., losing current page state). The description assumes context without providing it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute JavaScript in the browser
| Name | Required | Description | Default |
|---|---|---|---|
| script | Yes | JavaScript code to execute |
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 states what the tool does but lacks critical details: it doesn't specify execution context (e.g., current page, isolated environment), error handling, security implications, or what happens to the browser state after execution. For a tool that executes arbitrary code, this is a significant gap.
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 - a single four-word phrase that directly communicates the core functionality. Every word earns its place with no redundancy or unnecessary elaboration.
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 executing JavaScript in a browser (with security implications, state changes, and potential side effects), no annotations, no output schema, and a minimal description, this is inadequate. The description doesn't explain return values, error conditions, or what constitutes successful execution, leaving significant gaps for an AI 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 description coverage is 100%, with the single parameter 'script' clearly documented as 'JavaScript code to execute'. The description adds no additional parameter semantics beyond what the schema provides, but since the schema fully covers the parameter, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Execute JavaScript') and the context ('in the browser'), which distinguishes it from general JavaScript execution tools. However, it doesn't explicitly differentiate from sibling tools like 'get_console_logs' or 'run_audit_mode' that might also involve JavaScript execution in a browser context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an active browser session), exclusions, or how it differs from sibling tools like 'run_debugger_mode' or 'get_console_errors' that might involve similar browser interactions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fill an input field
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | CSS selector for the input field | |
| value | Yes | Value to fill |
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 mutation action ('fill') but doesn't disclose behavioral traits like whether it requires an existing element, what happens on errors, or if it triggers events. This leaves significant gaps for a tool that modifies web page state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence 'Fill an input field', which is front-loaded and wastes no words. It efficiently conveys the core purpose without unnecessary elaboration.
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 interacting with web elements, no annotations, and no output schema, the description is insufficient. It lacks details on behavior, error handling, or integration with sibling tools, making it incomplete for safe and effective use by an AI 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 100% coverage with clear descriptions for both parameters (selector and value). The description adds no additional meaning beyond what the schema provides, such as examples or constraints, so it meets the baseline for high 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 'Fill an input field' clearly states the action (fill) and target (input field), which is better than a tautology. However, it doesn't specify what type of input field (e.g., web form element) or distinguish it from similar tools like 'select' or 'click' among siblings, making it 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?
The description provides no guidance on when to use this tool versus alternatives like 'select' or 'click', nor does it mention prerequisites such as needing a browser context. It's a basic statement with no contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get browser console errors
| 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 carries the full burden of behavioral disclosure. It states what the tool does but doesn't explain what 'console errors' includes (e.g., JavaScript errors, warnings), whether it clears logs after retrieval, or what format the output takes. This leaves significant gaps for a tool that interacts with browser state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. This is an example of optimal conciseness for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of browser interaction and lack of annotations or output schema, the description is insufficient. It doesn't clarify the scope of 'console errors' (e.g., if it includes warnings or info messages), return format, or how it interacts with sibling tools like 'wipe_logs'. For a tool in this context, more detail 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?
The tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description doesn't add parameter details, but that's appropriate here. A baseline of 4 is given since the schema fully covers the absence of 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 'Get browser console errors' clearly states the verb ('Get') and resource ('browser console errors'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_console_logs' or 'get_network_errors', which would require more specificity to earn 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?
The description provides no guidance on when to use this tool versus alternatives like 'get_console_logs' or 'get_network_logs'. There's no mention of prerequisites, context, or exclusions, leaving the agent to 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.
Get browser console logs
| 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 carries the full burden of behavioral disclosure. It states what the tool does but doesn't explain key behaviors: whether it retrieves all logs or a subset, if it's read-only or has side effects, what format the logs are in, or if there are any limitations like rate constraints. This leaves significant gaps in understanding how the tool operates.
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: 'Get browser console logs.' It's front-loaded with the core action and resource, with zero wasted words. This is highly concise and well-structured for immediate comprehension.
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 browser console logs (which could include various log types, timestamps, or levels) and the lack of annotations and output schema, the description is incomplete. It doesn't specify what 'logs' entail (e.g., info, warnings, errors) or the return format, making it inadequate for an agent to fully understand the tool's output and behavior in 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 tool has 0 parameters, and schema description coverage is 100%, so there's no need for parameter details in the description. The description appropriately doesn't discuss parameters, which is efficient and avoids redundancy. A baseline score of 4 is given since no parameters exist, and the description doesn't add unnecessary 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 'Get browser console logs' clearly states the verb ('Get') and resource ('browser console logs'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_console_errors' or 'get_network_logs', which likely retrieve related but different types of logs, so it doesn't fully distinguish itself from alternatives.
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 such as 'get_console_errors' or 'get_network_logs'. It lacks any context about prerequisites, timing, or exclusions, leaving the agent to infer usage based on tool names alone, which is insufficient for optimal tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get page content (HTML or text)
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Type of content to get | text |
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 states what the tool does (get page content) but lacks critical behavioral details: it doesn't specify what 'page' refers to (e.g., current browser page, requires prior navigation), whether it's read-only (implied but not explicit), error handling, or output format beyond HTML/text. For a tool with no annotation coverage, this is a significant gap in 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 extremely concise (4 words) and front-loaded, stating the core purpose without any waste. Every word earns its place: 'Get' (action), 'page content' (resource), and '(HTML or text)' (key detail). It's appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (interacting with page content), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what 'page' means in context (likely requires a browser session), how content is retrieved, potential errors, or return values. For a tool in a browser automation context with siblings like navigate and click, more context is needed to ensure proper 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?
The input schema has 100% description coverage, with the single parameter 'type' fully documented in the schema (enum: html/text, default: text). The description adds minimal value beyond the schema by mentioning 'HTML or text', which aligns with the enum but doesn't provide additional context like when to choose one over the other. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'get' and the resource 'page content', specifying the format options (HTML or text). It distinguishes from siblings like get_console_logs or get_network_errors by focusing on page content rather than logs or errors. However, it doesn't explicitly differentiate from tools like evaluate or get_selected_element that might also retrieve content in some form.
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. It doesn't mention prerequisites (e.g., needing a page loaded via navigate), exclusions, or comparisons to siblings like evaluate (which might process content) or get_selected_element (which might get specific element content). Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get network error logs
| 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 of behavioral disclosure. It states the action ('Get') but doesn't describe what 'network error logs' entail (e.g., format, time range, source), whether it's a read-only operation, or any side effects. This leaves significant gaps in understanding the tool's 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 a single, efficient sentence with no wasted words. It's front-loaded and directly states the tool's purpose, making it easy to parse quickly.
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 is incomplete for a tool that likely returns structured data (logs). It doesn't explain what 'network error logs' include (e.g., error types, timestamps, URLs) or how results are formatted, leaving the agent with insufficient context to use the tool 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 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here, but it could have mentioned if any implicit parameters (like filters) are applied, though not required for a baseline score.
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 'Get network error logs' clearly states the verb ('Get') and resource ('network error logs'), making the tool's purpose understandable. However, it doesn't differentiate from sibling tools like 'get_console_errors' or 'get_network_logs', which reduces clarity about its specific scope compared to alternatives.
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 siblings like 'get_console_errors' and 'get_network_logs' available, there's no indication of what distinguishes this tool (e.g., focusing on errors vs. all logs, or network-specific vs. console-specific errors).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get network activity logs
| 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 of behavioral disclosure. It states the action but doesn't explain what 'network activity logs' include, whether this is a read-only operation, if it requires specific permissions, or how the logs are formatted/returned. This leaves significant gaps in understanding the tool's 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 extremely concise with just three words, front-loading the key action and resource. There is no wasted language, making it efficient and easy to parse, though this conciseness comes at the cost of detail in other dimensions.
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 is incomplete. It doesn't specify what 'network activity logs' entail, how they are returned, or any behavioral traits. For a tool with no structured data to rely on, more context is needed to fully understand its use 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?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, but since there are no parameters, this is acceptable, and it implies the tool retrieves logs without requiring inputs, which is clear enough for a baseline score.
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 'Get network activity logs' clearly states the action (get) and resource (network activity logs), which is adequate. However, it doesn't distinguish this tool from its sibling 'get_network_errors' or other logging tools like 'get_console_logs', leaving room for ambiguity about what specific logs are retrieved.
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. With siblings like 'get_network_errors' and 'get_console_logs', the description lacks context on whether this retrieves all network logs, specific types, or how it differs from other logging tools, offering no usage instructions.
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 currently selected element
| 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 carries full burden for behavioral disclosure. While 'Get information' implies a read operation, it doesn't specify what information is returned (e.g., element properties, attributes, position), whether it requires specific permissions, or how it interacts with the selection state. The description is too vague about the actual 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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized for a simple tool and front-loads the core functionality.
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 is insufficiently complete. It doesn't explain what 'information' means in this context, what format it returns, or how it relates to the selection state. For a tool in a browser automation context with many sibling tools, more specificity about the return value and usage 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?
The tool has zero parameters, and schema description coverage is 100% (though trivial since there are no parameters). The description appropriately doesn't discuss parameters, which aligns with the schema. A baseline of 4 is appropriate for zero-parameter tools when the description doesn't need to compensate for schema gaps.
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 information about') and resource ('the currently selected element'), making the purpose unambiguous. It doesn't explicitly differentiate from sibling tools like 'get_content' or 'select', but the focus on 'currently selected element' provides reasonable implicit distinction.
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 'get_content' or 'select'. It doesn't mention prerequisites (e.g., whether an element must already be selected), nor does it suggest when other tools might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Hover over an element on the page
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | CSS selector for the element to hover |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Hover over' implies a non-destructive interaction that simulates mouse movement, but the description doesn't clarify what happens after hovering (e.g., whether it waits for hover effects to complete, what visual feedback occurs, or if it triggers JavaScript events). For a browser interaction tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
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 at just 6 words, with zero wasted language. It's front-loaded with the core action and target. Every word earns its place by conveying essential information about what the tool does without unnecessary elaboration.
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 browser interaction tools and the absence of both annotations and output schema, the description is insufficiently complete. It doesn't explain what constitutes successful hovering, what errors might occur (e.g., element not found), what visual or state changes to expect, or how this interacts with other browser tools. For a tool that simulates user interactions, more context about behavior and outcomes 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 100% with the single parameter 'selector' fully documented in the schema. The description doesn't add any parameter-specific information beyond what's in the schema. According to scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in the description, which applies 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 the action ('hover over') and target ('an element on the page'), providing a specific verb+resource combination. It distinguishes itself from siblings like 'click' or 'select' by focusing on hover interactions rather than clicks or selections. However, it doesn't explicitly differentiate from all possible sibling interactions beyond the basic verb distinction.
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. It doesn't mention when hovering is appropriate (e.g., for triggering dropdowns, tooltips, or hover states) versus when to use 'click' or other interaction tools. There's no discussion of prerequisites, timing considerations, or alternative approaches for similar outcomes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run an accessibility audit on the current page
| 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 carries the full burden of behavioral disclosure. It states the action but doesn't explain what the audit entails (e.g., what standards it checks, if it's destructive, requires specific permissions, or has side effects like page reloads). This leaves significant gaps in understanding the tool's 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 a single, clear sentence with no wasted words. It's front-loaded with the core action and resource, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of an audit tool with no annotations and no output schema, the description is insufficient. It doesn't cover what the audit returns, how results are formatted, or any behavioral traits, leaving the agent with incomplete information 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?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate, but it could optionally mention that no inputs are required. This meets the baseline for zero-parameter tools.
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 'run' and the resource 'accessibility audit on the current page', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'run_best_practices_audit' or 'run_seo_audit', which would require mentioning what makes an accessibility audit unique.
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. It doesn't mention prerequisites (e.g., needing a page loaded), exclusions, or how it differs from other audit tools in the sibling list, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run comprehensive audit mode for optimization
| 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 of behavioral disclosure. It only states 'Run comprehensive audit mode for optimization', which does not reveal any behavioral traits such as what the audit entails, whether it's read-only or destructive, what permissions are needed, or how results are returned. This leaves critical operational details unspecified.
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 phrase, 'Run comprehensive audit mode for optimization', which is concise but under-specified. While it avoids unnecessary words, it lacks the detail needed to be truly helpful, making it more of a placeholder than an informative description. It is front-loaded but insufficient in 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 the complexity implied by 'comprehensive audit' and the lack of annotations and output schema, the description is incomplete. It does not explain what the audit covers, what it returns, or how it differs from other audit tools, leaving the agent with insufficient information to use the tool effectively in context with its 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 tool has 0 parameters, and the schema description coverage is 100%, so there are no parameters to document. The description does not need to add parameter semantics, and it appropriately does not mention any. This meets the baseline for a parameterless tool, though it does not compensate for other gaps.
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 'Run comprehensive audit mode for optimization' is vague and tautological—it essentially restates the tool name 'run_audit_mode' with the added term 'optimization' without specifying what is being audited or optimized. It does not clearly distinguish this tool from sibling audit tools like 'run_accessibility_audit' or 'run_performance_audit', leaving the purpose 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 is provided on when to use this tool versus alternatives. Given the presence of multiple sibling audit tools (e.g., 'run_accessibility_audit', 'run_performance_audit'), the description fails to indicate what makes this 'comprehensive audit mode' different or when it should be chosen over more specific audits, offering no context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a best practices audit on the current page
| 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 burden but lacks behavioral details. It mentions running an audit but doesn't disclose what the audit does (e.g., checks, outputs, or effects), whether it's read-only or modifies state, or any performance or permission considerations, leaving key traits unclear.
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, direct sentence with no wasted words, clearly stating the action and target. It's appropriately sized and front-loaded, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of an audit tool with no annotations or output schema, the description is incomplete. It doesn't explain what the audit entails, what results to expect, or how it differs from other audit tools, failing to provide sufficient context 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?
The tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description doesn't add param info, but this is acceptable given the lack of inputs, aligning with 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 states the action ('Run a best practices audit') and target ('on the current page'), which is clear but vague. It doesn't specify what 'best practices' entails or distinguish it from sibling audit tools like accessibility, SEO, or performance audits, leaving the purpose somewhat 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 is provided on when to use this tool versus alternatives like run_accessibility_audit or run_seo_audit. The description implies usage on a current page but doesn't specify prerequisites, exclusions, or contextual triggers, offering minimal direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run debugger mode to debug issues in the application
| 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 carries the full burden of behavioral disclosure. It states the tool runs debugger mode but doesn't explain what that entails—e.g., whether it's interactive, what data it collects, if it modifies the application state, or how results are presented. This is a significant gap for a tool with potential behavioral complexity.
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 states the purpose without unnecessary words. It's front-loaded and to the point, though it could be slightly more specific to improve clarity without adding bulk.
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 implied by 'debugger mode', lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the tool does behaviorally, what output to expect, or how it differs from sibling tools, leaving gaps for effective agent 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?
The tool has 0 parameters, and schema description coverage is 100%, so there's no need for parameter details in the description. The baseline for 0 parameters is 4, as the description appropriately doesn't discuss parameters, avoiding redundancy.
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 tool's purpose as 'run debugger mode to debug issues in the application', which includes a verb ('run') and resource ('debugger mode') with a goal ('debug issues'). However, it's somewhat vague about what 'debugger mode' entails compared to sibling tools like 'run_audit_mode' or 'run_performance_audit', lacking specific differentiation in scope or method.
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 is provided on when to use this tool versus alternatives. The description mentions debugging issues but doesn't specify what types of issues, prerequisites, or when to choose this over other debugging-related siblings like 'get_console_errors' or 'evaluate'. This leaves usage context implied at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a Next.js specific audit on the current page
| 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 for behavioral disclosure. While 'Run a Next.js specific audit' implies a read-only analysis operation, it doesn't describe what the audit entails, whether it modifies the page, what permissions are needed, or what the output looks like. For a tool with zero annotation coverage, 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 that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded, making it easy to understand at a glance.
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 is incomplete. It doesn't explain what a 'Next.js specific audit' involves, what it returns, or how it differs from other audit tools. For a specialized tool in a context with multiple audit options, more detail is needed to be fully helpful.
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 0 parameters with 100% schema description coverage, so the schema already fully documents the lack of inputs. The description appropriately doesn't add parameter information beyond what's in the schema, maintaining a baseline score of 4 for zero-parameter tools.
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 a Next.js specific audit') and the target ('on the current page'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling audit tools like 'run_accessibility_audit' or 'run_seo_audit', which would require mentioning what makes a Next.js audit distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple audit tools available (accessibility, SEO, performance, etc.), there's no indication of what scenarios warrant a Next.js-specific audit or what prerequisites might be needed (e.g., being on a Next.js page).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a performance audit on the current page
| 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 carries full burden but only states the action without disclosing behavioral traits. It doesn't mention what the audit entails, whether it's read-only or has side effects, output format, or any constraints like timeouts or permissions, leaving significant gaps for a tool with potential complexity.
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 wasted words, front-loading the core action and target. It's appropriately sized for a no-parameter tool, making it easy to parse without unnecessary elaboration.
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 implied by 'audit' and lack of annotations or output schema, the description is incomplete. It doesn't explain what the audit measures, what results to expect, or how it interacts with the page, leaving the agent with insufficient context 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?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description doesn't need to add parameter details, and it correctly implies no required inputs by not mentioning any, aligning well with 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 ('run a performance audit') and target ('on the current page'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling audit tools like 'run_accessibility_audit' or 'run_seo_audit' beyond the performance focus, missing explicit distinction.
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 'run_best_practices_audit' or 'run_nextjs_audit'. It lacks context about prerequisites (e.g., needing a page loaded) or exclusions, offering only a basic usage statement without comparative or situational advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run an SEO audit on the current page
| 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 carries the full burden of behavioral disclosure. It states what the tool does but omits critical details: whether it's read-only or mutative, what permissions are needed, how long it runs, what output format to expect, or if it has side effects. For a tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and target, making it easy to parse. Every word earns its place by conveying 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 of an SEO audit (which could involve analysis, scoring, or reporting) and the lack of both annotations and an output schema, the description is incomplete. It doesn't explain what the audit entails, what results to expect, or behavioral traits like execution time or side effects, leaving the agent with insufficient 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 tool has zero parameters, and schema description coverage is 100% (though trivial). The description doesn't need to explain parameters, and it correctly implies no inputs are required by specifying 'on the current page' as the implicit target. This meets the baseline for tools with no 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 ('run an SEO audit') and target ('on the current page'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling audit tools like 'run_accessibility_audit' or 'run_performance_audit', which follow the same pattern but target different audit types.
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. It doesn't mention prerequisites (e.g., needing a page loaded first), exclusions, or comparisons to sibling audit tools, leaving the agent to infer context 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.
Take a screenshot of the current page
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Name for the screenshot file | screenshot.png |
| fullPage | No | Capture full page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action without disclosing behavioral traits. It doesn't mention what happens after capture (e.g., file saved locally/remotely, format constraints), permissions needed, or side effects like pausing page interaction during capture.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and appropriately sized for a straightforward tool, earning full marks for 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 is incomplete for a tool that performs a visual capture operation. It lacks details on return values (e.g., file path, success confirmation), error conditions, or dependencies like requiring an active browser context, leaving significant gaps for agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both parameters (name and fullPage). The description adds no additional parameter meaning beyond implying a screenshot is taken, which is already covered by the tool name and purpose. This meets the baseline for high 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 clearly states the action ('Take a screenshot') and target resource ('of the current page'), making the purpose immediately understandable. However, it doesn't differentiate from potential sibling tools like 'get_content' or 'run_audit_mode' that might also capture visual information, so it doesn't reach the highest score.
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. It doesn't mention prerequisites (e.g., needing a browser session open), exclusions, or comparisons to sibling tools like 'get_content' for text extraction or audit tools for visual analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Select an option from a dropdown
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | CSS selector for the select element | |
| value | Yes | Value to select |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action without disclosing behavioral traits like whether it waits for page loads, handles dynamic dropdowns, requires the element to be visible, or what happens on failure. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded and appropriately sized for a simple tool, making it easy to parse quickly.
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 mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after selection (e.g., page changes, validation), error conditions, or interaction with other tools, leaving the agent with incomplete context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('selector' and 'value') adequately. The description adds no additional parameter semantics beyond what's in the schema, meeting the baseline for high 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 clearly states the action ('select an option') and target ('from a dropdown'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'click' or 'fill_form' that might also interact with form elements, missing full sibling distinction.
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 'click' for buttons or 'fill_form' for other form inputs. The description only states what it does, not when it's appropriate or what prerequisites might exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clear all stored logs from memory
| 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 carries the full burden of behavioral disclosure. It states the tool 'Clear[s] all stored logs from memory', implying a destructive operation, but doesn't specify whether this is irreversible, requires permissions, affects system performance, or has side effects. More context is needed for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste—'Clear all stored logs from memory'—front-loading the key action and resource. It's appropriately sized for a no-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature (implied by 'Clear'), no annotations, and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., irreversibility, effects), usage context, or return values, which are critical for safe operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately avoids discussing parameters, focusing on the tool's action, which aligns with the schema's simplicity.
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 ('Clear') and target resource ('all stored logs from memory'), making the purpose unambiguous. It doesn't explicitly differentiate from sibling tools like 'get_console_logs' or 'get_network_logs', but the destructive nature is implied through 'Clear' versus 'get' operations.
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 lacks context on prerequisites (e.g., whether logs must exist), exclusions, or comparisons to sibling tools like 'get_console_logs', leaving usage unclear beyond the basic action.
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.
clickclose_browserevaluatefillget_console_errorsget_console_logsget_contentget_network_errorsget_network_logsget_selected_elementhovernavigaterun_accessibility_auditrun_audit_moderun_best_practices_auditrun_debugger_moderun_nextjs_auditrun_performance_auditrun_seo_auditscreenshotselectwipe_logsScored across 22 tools
Most tools have distinct purposes, such as click, fill, navigate, and screenshot, with clear boundaries. However, some overlap exists between the various audit tools (e.g., run_accessibility_audit, run_best_practices_audit, run_performance_audit, run_seo_audit, run_nextjs_audit, run_audit_mode), which could cause confusion as their specific scopes might not be immediately clear from the names alone, though descriptions help differentiate them.
The tool names follow a highly consistent snake_case pattern with clear verb_noun structures, such as click, close_browser, evaluate, fill, get_console_errors, navigate, run_accessibility_audit, and screenshot. There are no deviations in naming conventions, making the set predictable and easy to understand.
With 22 tools, the count is borderline high for a browser automation and auditing server, as it might feel heavy and potentially overwhelming. While it covers many aspects, some tools could be consolidated (e.g., multiple audit tools), suggesting a slight over-scoping that could impact usability.
The tool set provides comprehensive coverage for browser automation and auditing, including navigation, interaction (click, fill, select), content retrieval (get_content, get_console_logs), debugging (run_debugger_mode, get_network_errors), audits (performance, SEO, accessibility), and maintenance (close_browser, wipe_logs). There are no obvious gaps, and agents can handle full workflows from setup to analysis.
MCP server for Mint — AI-powered QA that runs your app in a real browser on every PR.
Hosted real Google Chrome MCP with per-user persistent state. Navigate, click, type, screenshot.
Browserless MCP — wraps the Browserless headless-Chromium REST API (browserless.io)
Hosted Amazon Seller and Vendor MCP server for Claude, ChatGPT, Cursor, Codex, Gemini, Copilot.
