Característica | CDP directo (v1.4.0) ⭐ RECOMENDADO | Basado en Puppeteer (v1.2.0) |
Dependencias | Solo | Puppeteer + MCP SDK (163 paquetes) |
Uso de memoria | Menor (chromium nativo) | Mayor (sobrecarga del envoltorio de Node.js) |
Tiempo de inicio | Más rápido (WebSocket directo) | Más lento (inicialización de puppeteer) |
Control del navegador | Protocolo nativo Chrome DevTools | Capa de abstracción de Puppeteer |
Optimización ARM64 | ARM64 nativo completo | Depende del soporte ARM64 de Puppeteer |
Depuración | Mensajes CDP sin procesar visibles | Abstraído por Puppeteer |
Mantenimiento | Solo cambios en el protocolo Chrome | Cambios en Puppeteer + protocolo Chrome |
Rendimiento | Mejor (comunicación directa) | Bueno (comunicación envuelta) |
Use CDP directo (v1.4.0) si:
✅ Desea el máximo rendimiento y el mínimo de dependencias
✅ Necesita optimización nativa para ARM64
✅ Desea un control directo del protocolo Chrome DevTools
✅ Está creando sistemas de automatización en producción
✅ Desea las últimas funciones y las actualizaciones más rápidas
Use la versión basada en Puppeteer (v1.2.0) si:
✅ Está migrando desde código de Puppeteer existente
✅ Prefiere la abstracción de la API de Puppeteer
✅ Necesita funciones específicas de Puppeteer que aún no se han implementado en CDP directo
✅ Desea minimizar los cambios en los flujos de trabajo existentes
# 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
Este repositorio incluye múltiples enfoques de documentación para diferentes audiencias:
📖 README TÉCNICO - Documentación técnica completa que incluye:
Diagramas de arquitectura y referencia de API
Benchmarks de rendimiento y guías de optimización
Ejemplos de integración CI/CD y flujos de trabajo de pruebas E2E
Opciones avanzadas de depuración y personalización
📖 README DE RASPBERRY PI - Guía centrada en el presupuesto que incluye:
Configuración completa de desarrollo de IA por $480
Flujos de trabajo de desarrollo SaaS sin código
Casos de uso de startups del mundo real y análisis de ROI
Enfoque en accesibilidad global y el movimiento maker
Desarrolladores: Ir a Documentación técnica →
Creadores: Ir a Guía de Raspberry Pi →
Todos: Continúe leyendo para la configuración y el uso universal
🤖 Automatización de navegador ARM64 nativa
Implementación directa del protocolo Chrome DevTools
27 herramientas MCP integrales para un control total del navegador
Optimizado para arquitecturas Raspberry Pi y Apple Silicon
Sin dependencia de binarios de Puppeteer x86_64 rotos
⚡ Arquitectura de alto rendimiento
Solo 2 dependencias (ws + MCP SDK) frente a 163 paquetes en Puppeteer
Menor uso de memoria y tiempos de inicio más rápidos
Comunicación WebSocket directa con Chrome
Capacidades integrales de registro y auditoría
🛠️ Desarrollo listo para empresas
Suite de depuración completa con monitoreo de consola/red
Auditorías de accesibilidad, SEO y rendimiento integradas
Ejemplos de integración CI/CD y flujos de trabajo de pruebas E2E
Compatibilidad multiplataforma (Linux ARM64, macOS Apple Silicon)
💰 Plataforma de innovación asequible
Configuración completa de desarrollo de IA por menos de $500
Mismas capacidades que estaciones de trabajo empresariales de más de $50,000
Accesibilidad global para creadores y startups de todo el mundo
Sin costos recurrentes en la nube: sea dueño de su infraestructura
# 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')"Resultado esperado: [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 - Navegar a URLs con carga completa de página
screenshot - Capturar capturas de pantalla PNG (página completa o ventana gráfica)
click - Hacer clic en elementos mediante selector CSS con posicionamiento preciso
fill - Rellenar campos de entrada con texto o valores
hover - Pasar el ratón sobre elementos para interacciones de menús desplegables/información sobre herramientas
select - Seleccionar opciones de menús desplegables por valor
evaluate - Ejecutar JavaScript y devolver resultados
get_content - Extraer HTML de la página o contenido de texto plano
get_console_logs - Recuperar la salida de la consola del navegador
get_console_errors - Obtener solo mensajes de error de la consola
get_network_logs - Monitorear todas las solicitudes/respuestas de red
get_network_errors - Rastrear solicitudes de red fallidas (4xx/5xx)
wipe_logs - Borrar todos los registros almacenados de la memoria
get_selected_element - Obtener información sobre el elemento enfocado actualmente
emulate_device - Emular dispositivos móviles con 17 preajustes o ventana gráfica/UA/DPR/táctil personalizados, con soporte horizontal
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 - Restablecer la emulación del dispositivo al modo de escritorio
start_screencast - Iniciar la grabación de la actividad del navegador mediante screencast CDP (formato, calidad, resolución, salto de fotogramas configurables)
stop_screencast - Detener la grabación y codificar a MP4, GIF o WebM mediante ffmpeg (detecta automáticamente los FPS a partir de las marcas de tiempo de los fotogramas)
screencast_status - Verificar el estado de la grabación, el recuento de fotogramas y la duración transcurrida
run_accessibility_audit - Verificar texto alternativo, etiquetas, encabezados, contraste
run_performance_audit - Medir tiempos de carga, uso de memoria, recursos
run_seo_audit - Validar título, meta descripción, etiquetas H1, canónicas
run_best_practices_audit - Verificar HTTPS, HTML obsoleto, ventana gráfica
run_nextjs_audit - Verificaciones de optimización específicas de Next.js
run_debugger_mode - Información de depuración completa
run_audit_mode - Ejecutar todas las auditorías juntas con un resumen
close_browser - Apagado limpio del proceso de 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.jsRequiere:
ffmpeginstalado en el sistema. Los FPS se detectan automáticamente a partir de las marcas de tiempo de los fotogramas de CDP. La salida GIF está limitada a 15 fps para tamaños de archivo razonables.
# 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'Error | Causa | Solución |
| Conexión WebSocket perdida | Reiniciar navegador, verificar disponibilidad de puerto |
| Chrome no iniciado completamente | Aumentar retraso de inicio, verificar proceso de chrome |
| Selector CSS no válido | Verificar selector con la herramienta |
| Puerto de depuración bloqueado | Verificar firewall, cerrar procesos de chrome existentes |
| Problemas de carga de página | Verificar red, aumentar tiempo de espera, probar página más simple |
// 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
];Plataforma | Estado | Ruta de Chrome | Método de instalación | Notas |
Linux ARM64 ✅ | Totalmente compatible |
|
| Probado en Raspberry Pi OS |
macOS Apple Silicon ⚠️ | Requiere modificaciones |
| Descargar de Google o | Necesita actualizaciones de ruta y flags |
Windows ARM64 ❓ | No probado |
| Descargar de Google | Necesitaría cambios específicos para 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-quarantineActualmente, el servidor está optimizado para Linux ARM64. Para la compatibilidad con macOS, modifique 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 platformAunque no se ha probado, el soporte para Windows ARM64 necesitaría:
// 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...Plataforma | Tiempo de inicio | Uso de memoria | Notas |
Linux ARM64 (Pi 4) | ~3-4s | ~150MB | Optimizado, bien probado |
macOS Apple Silicon | ~2-3s | ~200MB | CPU más rápida, más memoria |
Windows ARM64 | Desconocido | Desconocido | Dependería del hardware |
¡Agradecemos las contribuciones para un soporte multiplataforma completo!
Probadores de macOS: Prueben los cambios propuestos en Apple Silicon
Windows ARM64: Prueben en Surface Pro X o dispositivos similares
Optimización de rendimiento: Optimizaciones específicas de la plataforma
Scripts de instalación: Configuración automatizada para cada plataforma
# 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 - ✓ ConnectedDEBE iniciar una nueva sesión de Claude después de agregar el servidor MCP:
# Exit current session if in one
exit
# Start fresh session
claudePídale a Claude que use las herramientas de 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-arm64Sea explícito para evitar Playwright/Puppeteer:
"Usa chromium-
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.
