Erweiterte Browserautomatisierung
Navigieren Sie mit anpassbaren Ladestrategien zu jeder URL
Erfassen Sie Screenshots der gesamten Seite oder bestimmter Elemente
Führen Sie präzise DOM-Interaktionen durch (Klicken, Füllen, Auswählen, Hovern)
Führen Sie beliebiges JavaScript im Browserkontext mit der Erfassung von Konsolenprotokollen aus
Leistungsstarker API-Client
HTTP-Anfragen ausführen (GET, POST, PUT, PATCH, DELETE)
Konfigurieren von Anforderungsheadern und Textinhalten
Antwortdaten mit JSON-Formatierung verarbeiten
Fehlerbehandlung mit detailliertem Feedback
MCP-Ressourcenmanagement
Greifen Sie auf Browserkonsolenprotokolle als Ressourcen zu
Abrufen von Screenshots über die MCP-Ressourcenschnittstelle
Dauerhafte Sitzung mit Headful-Browserinstanz
KI-Agentenfunktionen
Verketten Sie mehrere Browservorgänge für komplexe Aufgaben
Befolgen Sie mehrstufige Anweisungen mit intelligenter Fehlerbehebung
Automatisierung technischer Aufgaben durch Anweisungen in natürlicher Sprache
Related MCP server: Browserbeam MCP Server
Klicken Sie auf einen beliebigen Zeitstempel, um zu diesem Abschnitt des Videos zu springen
00:00 – Google-Suche nach MCP
Navigieren Sie zur Google-Startseite und suchen Sie nach „Model Context Protocol“. Demonstration von Claude Desktop mithilfe der MCP-Integration, um eine einfache Websuche durchzuführen und die Ergebnisse zu verarbeiten.
00:33 – Screenshot-Aufnahme
Erstellen Sie einen Screenshot der Suchergebnisse mit einem benutzerdefinierten Dateinamen und präsentieren Sie ihn im Finder. Zeigt, wie Claude während der Browserautomatisierung visuelle Inhalte von Webseiten erfassen und speichern kann.
01:00 – Wikipedia-Suche
Navigieren Sie zu Wikipedia.org und suchen Sie nach „Model Context Protocol“. Dies veranschaulicht Claudes Fähigkeit, über die MCP-Integration mit verschiedenen Websites und deren Suchfunktionen zu interagieren.
01:38 – Dropdown-Menü-Interaktion I
Navigation zu einer Testwebsite (the-internet.herokuapp.com/dropdown) und Auswahl von „Option 1“ aus einem Dropdown-Menü. Demonstriert Claudes Fähigkeit, mit Formularelementen zu interagieren und Auswahlen zu treffen.
01:56 – Dropdown-Menü-Interaktion II
Ändern der Auswahl im selben Dropdown-Menü auf „Option 2“. Zeigt Claudes Fähigkeit, dasselbe Formularelement mehrfach zu bearbeiten und unterschiedliche Auswahlen zu treffen.
02:09 – Ausfüllen des Anmeldeformulars
Navigieren Sie zu einer Anmeldeseite (the-internet.herokuapp.com/login) und füllen Sie das Feld für den Benutzernamen mit „tomsmith“ und das Feld für das Passwort mit „SuperSecretPassword!“ aus. Demonstriert die Automatisierung des Formularausfüllens.
02:28 - Login-Übermittlung
Übermittlung der Anmeldeinformationen und Abschluss des Authentifizierungsprozesses. Zeigt Claudes Fähigkeit, Formulareinreichungen auszulösen und durch mehrstufige Prozesse zu navigieren.
02:36 – Ausführung der API-Anforderung
Ausführen einer GET-Anfrage an den JSONPlaceholder-API-Endpunkt. Demonstriert Claudes Fähigkeit, direkte API-Aufrufe zu tätigen und die zurückgegebenen Daten über die MCP-Integration zu verarbeiten.
Node.js 16 oder höher
Claude Desktop
Dramatikerabhängigkeiten
npm init playwright@latestDieses Paket enthält Playwright und die notwendigen Abhängigkeiten für die Browserautomatisierung. Wenn Sie npm install ausführen, werden die erforderlichen Playwright-Abhängigkeiten installiert. Das Paket unterstützt die folgenden Browser:
Chrome (Standard)
Feuerfuchs
Microsoft Edge
WebKit (Safari-Engine)
Wenn Sie einen Browsertyp zum ersten Mal verwenden, installiert Playwright automatisch die entsprechenden Browsertreiber. Sie können sie auch manuell mit den folgenden Befehlen installieren:
npx playwright install chrome
npx playwright install firefox
npx playwright install webkit
npx playwright install msedgeHinweis zu Safari : Playwright bietet keine direkte Unterstützung für den Safari-Browser. Stattdessen verwendet es WebKit, die Browser-Engine von Safari.
Hinweis zu Edge : Wenn Sie Edge als Browsertyp auswählen, startet der Agent tatsächlich Microsoft Edge (nicht Chromium). Technisch gesehen wird Edge in Playwright mit der Chromium-Browserinstanz und dem Kanalparameter „msedge“ gestartet, da Microsoft Edge auf Chromium basiert.
Klonen oder laden Sie dieses Repository herunter:
git clone https://github.com/imprvhub/mcp-browser-agent
cd mcp-browser-agentInstallieren Sie Abhängigkeiten:
npm installErstellen Sie das Projekt:
npm run buildEs gibt zwei Möglichkeiten, den MCP-Server auszuführen:
Öffnen Sie ein Terminal oder eine Eingabeaufforderung
Navigieren Sie zum Projektverzeichnis
Führen Sie den Server direkt aus:
node dist/index.jsLassen Sie dieses Terminalfenster geöffnet, während Sie Claude Desktop verwenden. Der Server läuft, bis Sie das Terminal schließen.
Der Claude Desktop kann den MCP-Server bei Bedarf automatisch starten. So richten Sie dies ein:
Die Konfigurationsdatei von Claude Desktop befindet sich unter:
macOS : ~/Library/Application Support/Claude/claude_desktop_config.json
Windows : %APPDATA%\Claude\claude_desktop_config.json
Linux : ~/.config/Claude/claude_desktop_config.json
Bearbeiten Sie diese Datei, um die MCP-Konfiguration des Browser-Agenten hinzuzufügen. Falls die Datei nicht vorhanden ist, erstellen Sie sie:
{
"mcpServers": {
"browserAgent": {
"command": "node",
"args": ["ABSOLUTE_PATH_TO_DIRECTORY/mcp-browser-agent/dist/index.js",
"--browser",
"chrome"
]
}
}
}Wichtig : Ersetzen Sie ABSOLUTE_PATH_TO_DIRECTORY durch den vollständigen absoluten Pfad , in dem Sie MCP installiert haben
macOS/Linux-Beispiel: /Users/username/mcp-browser-agent
Windows-Beispiel: C:\\Users\\username\\mcp-browser-agent
Wenn Sie bereits andere MCPs konfiguriert haben, fügen Sie einfach den Abschnitt „browserAgent“ innerhalb des Objekts „mcpServers“ hinzu. Hier ist ein Beispiel für eine Konfiguration mit mehreren MCPs:
{
"mcpServers": {
"otherMcp1": {
"command": "...",
"args": ["..."]
},
"otherMcp2": {
"command": "...",
"args": ["..."]
},
"browserAgent": {
"command": "node",
"args": [
"ABSOLUTE_PATH_TO_DIRECTORY/mcp-browser-agent/dist/index.js",
"--browser",
"chrome"
]
}
}
}Der MCP Browser Agent unterstützt mehrere Browsertypen. Standardmäßig wird Chrome verwendet. Sie können jedoch auf verschiedene Weise einen anderen Browser angeben:
Erstellen oder bearbeiten Sie die Datei .mcp_browser_agent_config.json in Ihrem Home-Verzeichnis:
{
"browserType": "chrome"
}Unterstützte Werte für browserType sind:
chrome – Verwendet installiertes Chrome (Standard)
firefox – Verwendet den Firefox-Browser „Nightly“
webkit – Verwendet die WebKit-Engine (Hinweis: Dies ist nicht Safari selbst, sondern die WebKit-Rendering-Engine, auf der Safari basiert)
edge – Verwendet Microsoft Edge
Hinweis zu Safari : Playwright bietet keine direkte Unterstützung für den Safari-Browser. Stattdessen verwendet es WebKit, die Browser-Engine von Safari. Die WebKit-Implementierung in Playwright bietet ähnliche Funktionen, ist aber nicht identisch mit der Safari-Browser-Erfahrung.
Beim manuellen Starten des MCP-Servers können Sie den Browsertyp angeben:
node dist/index.js --browser firefoxLegen Sie die Umgebungsvariable MCP_BROWSER_TYPE fest:
MCP_BROWSER_TYPE=firefox node dist/index.jsBeim Konfigurieren des MCP in claude_desktop_config.json von Claude Desktop können Sie den Browsertyp angeben:
{
"mcpServers": {
"browserAgent": {
"command": "node",
"args": [
"ABSOLUTE_PATH_TO_DIRECTORY/mcp-browser-agent/dist/index.js",
"--browser",
"chrome"
]
}
}
}Der MCP Browser Agent basiert auf dem Model Context Protocol und ermöglicht Claude die Interaktion mit einem Headful-Browser über Playwright. Die Implementierung besteht aus vier Hauptkomponenten:
Server (index.ts)
Initialisiert den MCP-Server mit dem Standardprotokoll Model Context Protocol
Konfiguriert Serverfunktionen für Tools und Ressourcen
Stellt die Kommunikation mit Claude über den stdio-Transport her
Tools-Registrierung (tools.ts)
Definiert Browser- und API-Tool-Schemas
Gibt Parameter, Validierungsregeln und Beschreibungen an
Registriert Tools beim MCP-Server für Claudes Entdeckung
Anforderungshandler (handlers.ts)
Verwaltet MCP-Protokollanforderungen für Tools und Ressourcen
Stellt Browserprotokolle und Screenshots als abfragbare Ressourcen bereit
Leitet Anfragen zur Tool-Ausführung an die entsprechenden Handler weiter
Executor (executor.ts)
Verwaltet den Lebenszyklus von Browsern und API-Clients
Implementiert Browser-Automatisierungsfunktionen mit Playwright
Verarbeitet API-Anfragen mit ordnungsgemäßer Fehlerbehandlung und Antwortanalyse
Behält die statusbehaftete Browsersitzung zwischen Befehlen bei
Im Gegensatz zu grundlegenden Integrationen fungiert der MCP Browser Agent als echter KI-Agent durch:
Beibehalten des persistenten Browserstatus über mehrere Befehle hinweg
Erfassen detaillierter Konsolenprotokolle zum Debuggen
Speichern von Screenshots zur Referenz und Überprüfung
Komplexe Interaktionsabläufe managen
Bereitstellung detaillierter Fehlerinformationen zur Wiederherstellung
Unterstützung verketteter Vorgänge für komplexe Arbeitsabläufe
Werkzeugname | Beschreibung | Parameter |
| Navigieren Sie zu einer URL |
|
| Screenshot aufnehmen |
|
| Klickelement |
|
| Formulareingaben ausfüllen |
|
| Dropdown-Option auswählen |
|
| Bewegen Sie den Mauszeiger über das Element |
|
| JavaScript ausführen |
|
Werkzeugname | Beschreibung | Parameter |
| GET-Anfrage |
|
| POST-Anforderung |
|
| PUT-Anforderung |
|
| PATCH-Anforderung |
|
| DELETE-Anforderung |
|
Der MCP-Browser-Agent stellt die folgenden Ressourcen bereit:
browser://logs - Zugriff auf Browser-Konsolenprotokolle
screenshot://[name] - Zugriff auf Screenshots nach Namen
Hier sind einige realistische Beispiele für die Verwendung des MCP-Browser-Agenten mit Claude:
Navigate to the Google homepage at https://www.google.comTake a screenshot of the current page and name it "google-homepage"Type "weather forecast" in the search boxNavigate to https://www.wikipedia.org and search for "Model Context Protocol"Go to https://the-internet.herokuapp.com/dropdown and select the option "Option 1" from the dropdownNavigate to https://the-internet.herokuapp.com/login and fill in the username field with "tomsmith" and the password field with "SuperSecretPassword!"Go to https://the-internet.herokuapp.com/login, fill in the username and password fields, then click the login buttonGo to https://example.com and execute a JavaScript script to return the page titleNavigate to https://www.google.com and execute a JavaScript script to count the number of links on the pagePerform a GET request to https://jsonplaceholder.typicode.com/todos/1Make a POST request to https://jsonplaceholder.typicode.com/posts with appropriate JSON dataDiese Beispiele stellen die tatsächlichen Fähigkeiten des MCP-Browser-Agenten dar und geben ein realistischeres Bild davon, was er in seinem aktuellen Zustand leisten kann.
Wenn in Claude Desktop der Fehler „MCP Browser Agent: Server getrennt“ angezeigt wird:
Überprüfen Sie, ob der Server läuft :
Öffnen Sie ein Terminal und führen Sie node dist/index.js manuell aus dem Projektverzeichnis aus
Wenn der Server erfolgreich startet, verwenden Sie Claude, während Sie dieses Terminal geöffnet halten
Überprüfen Sie Ihre Konfiguration :
Stellen Sie sicher, dass der absolute Pfad in claude_desktop_config.json für Ihr System korrekt ist
Überprüfen Sie noch einmal, ob Sie doppelte Backslashes ( \\ ) für Windows-Pfade verwendet haben
Stellen Sie sicher, dass Sie den vollständigen Pfad vom Stammverzeichnis Ihres Dateisystems verwenden.
Wenn der Browser nicht startet oder Sie ihn nicht sehen:
Überprüfen Sie, ob der angegebene Browser installiert ist
Stellen Sie sicher, dass der Browser (Chrome, Firefox, Edge oder Safari/WebKit) auf Ihrem System installiert ist
Die Browsertreiber werden automatisch von Playwright verwaltet
Starten Sie den Server und Claude Desktop neu
Beenden Sie alle vorhandenen Knotenprozesse, die möglicherweise den Server ausführen.
Starten Sie Claude Desktop neu, um eine neue Verbindung herzustellen
Es gibt bekannte Probleme mit den Browsern Chromium und Chrome, bei denen der Prozess nach der Verwendung manchmal nicht ordnungsgemäß beendet wird. Wenn dieses Problem auftritt:
Schließen Sie den Browserprozess manuell :
Windows : Drücken Sie Strg+Umschalt+Esc, um den Task-Manager zu öffnen, suchen Sie den Chrome/Chromium-Prozess und beenden Sie ihn
macOS : Öffnen Sie den Aktivitätsmonitor (Programme > Dienstprogramme > Aktivitätsmonitor), suchen Sie den Chrome/Chromium-Prozess und klicken Sie auf das X, um ihn zu beenden
Linux : Führen Sie ps aux | grep chrome oder ps aux | grep chromium aus, um den Prozess zu finden, und beenden Sie ihn anschließend kill <PID> .
Hinweis zur Browserkompatibilität :
Dieses Problem wurde vor allem bei Chromium und Chrome beobachtet.
Bei den integrierten Browsern von Firefox und Playwright tritt dieses Problem normalerweise nicht auf.
[!VORSICHT] Diese MCP-Integration basiert auf Playwright. Dieses System weist bekannte Probleme und Fehler auf, die den Betrieb beeinträchtigen können. Bitte melden Sie alle Probleme, die bei der Browserautomatisierung auftreten, an Playwrights GitHub-Probleme . Das Playwright-Team arbeitet kontinuierlich an der Behebung dieser Probleme. Dieser Agent bietet trotz dieser Einschränkungen die Grundlage für die Browserautomatisierung mit Claude Desktop.
src/index.ts : Haupteinstiegspunkt und Initialisierung des MCP-Servers
src/tools.ts : Toolschemata und Registrierung
src/handlers.ts : MCP-Anforderungshandler für Tools und Ressourcen
src/executor.ts : Tool-Implementierungslogik mit Playwright
npm run buildnpm run watchDas Projekt umfasst Tests zur Überprüfung der Kernfunktionalität und der Browserhandhabung.
npm test # Run tests
npm run test:watch # Watch mode
npm run test:coverage # Coverage reportDie Tests überprüfen die Konfigurationsintegrität, die Browser-Automatisierungsfunktionen, die Fehlerbehandlung und die Prozessbereinigung. Der Schwerpunkt der Testsuite liegt insbesondere auf der Sicherstellung der ordnungsgemäßen Verarbeitung von Browserprozessen aufgrund bekannter Probleme bei der Beendigung von Chrome/Chromium.
[!WICHTIG] Diese MCP-Integration bietet Claude die Möglichkeit zur autonomen Browsersteuerung. Bitte lesen Sie unsere Sicherheitsrichtlinie, um wichtige Informationen zu verbotenen Verwendungen, Sicherheitsimplikationen und bewährten Methoden zu erhalten.
Der MCP Browser Agent ist für legitime Automatisierungsaufgaben konzipiert, könnte aber potenziell missbraucht werden. Benutzer sind dafür verantwortlich, dass die Nutzung alle geltenden Gesetze, Nutzungsbedingungen und ethischen Richtlinien einhält. Weitere Informationen finden Sie in unserer detaillierten Sicherheitsrichtlinie .
Beiträge zum MCP Browser Agent sind willkommen! Hier sind einige Bereiche, in denen Sie helfen können:
Hinzufügen neuer Browser-Automatisierungsfunktionen
Verbesserung der Fehlerbehandlung und -behebung
Verbesserung der Screenshot- und Ressourcenverwaltung
Erstellen nützlicher Arbeitsabläufe und Beispiele
Leistungsoptimierung für komplexe Vorgänge
Dieses Projekt ist unter der Mozilla Public License 2.0 lizenziert – Einzelheiten finden Sie in der Datei LICENSE .
Perform a DELETE request to an API endpoint
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | API endpoint URL | |
| headers | No | Request headers |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden but only states the action without disclosing side effects, idempotency, authentication needs, rate limits, or return format. This is minimal for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is appropriately concise for a simple tool, though slightly more context could be included without losing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema), the description covers the basic action but omits expected return values, error conditions, or usage scope, leaving the description marginally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptive parameter names (url, headers). The description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a DELETE request to an API endpoint, using a specific verb and resource that distinguishes it from sibling tools (api_get, api_patch, etc.) which handle other HTTP methods.
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 api_get or api_post. The description merely repeats the method, missing explicit when/when-not context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform a GET request to an API endpoint
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | API endpoint URL | |
| headers | No | Request headers |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It fails to mention that GET is typically safe and idempotent, how errors are handled, or whether redirects are followed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no unnecessary words. It efficiently conveys the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple but lacks information about return values, error handling, authentication requirements, or default behavior. The description is too minimal for an agent to use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The tool description adds no extra meaning beyond the schema, so 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 'Perform a GET request to an API endpoint', which identifies the HTTP method and the action. It distinguishes from sibling tools like api_post and api_delete by the method name, but lacks mention of read-only nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings. The description does not specify that GET should be used for retrieving data, nor does it mention alternatives for modifying or deleting resources.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform a PATCH request to an API endpoint
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | API endpoint URL | |
| data | Yes | Request body data (JSON string) | |
| headers | No | Request headers |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only states it performs a PATCH request, implying mutation, but does not disclose side effects, authentication needs, rate limits, or response 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 sentence with no unnecessary words. However, it is very brief and could benefit from additional context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete given the tool's complexity. No output schema exists, and the description does not explain return values or error handling. Sibling tools suggest it is part of an HTTP client set, but the description lacks depth.
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 all parameters. The description does not add any additional meaning beyond what is in the input 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 it performs a PATCH request to an API endpoint, which is a specific verb and resource. This distinguishes it from sibling tools like api_get, api_post, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus other HTTP methods (e.g., POST, PUT) or alternatives. The context signals show siblings, but the description offers no differentiation advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform a POST request to an API endpoint
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | API endpoint URL | |
| data | Yes | Request body data (JSON string) | |
| headers | No | Request headers |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It fails to mention typical POST behavior (resource creation), data validation, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise and front-loaded, but it is too brief and lacks substance for a practical tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple HTTP tool, description should mention typical use (e.g., 'sends data to URL'). Schema covers parameters but context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all parameters described), so baseline is 3. Description adds no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'POST request' verb and 'API endpoint' resource, clearly distinguishing from sibling tools like api_get, api_put, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, no mention of prerequisites or context such as authentication or data format.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform a PUT request to an API endpoint
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | API endpoint URL | |
| data | Yes | Request body data (JSON string) | |
| headers | No | Request headers |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states 'PUT request' implying mutation, but omits critical details like idempotency, side effects, authentication needs, or error 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?
Single sentence is concise and front-loaded, but does not add meaningful content beyond the tool name; minimal but not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no behavioral details; for a tool with 3 parameters and nested objects, the description is insufficient to fully understand usage and return values.
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 covers all 3 parameters with descriptions; description adds no extra meaning beyond what schema already provides, 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?
Clearly states the action ('Perform a PUT request') and resource ('API endpoint'), but lacks differentiation from sibling tools like api_patch or api_post, which perform similar HTTP methods.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use PUT versus other HTTP methods (e.g., PATCH for partial updates, POST for creation). Does not mention idempotency or replacement semantics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Click an element on the page
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | CSS selector for element to click |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose behavioral traits beyond the basic action, such as potential side effects (e.g., navigation, page changes) or element visibility requirements. No annotations exist to compensate for this lack of detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. It is appropriately sized for a simple action, though it could benefit from slight elaboration without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the sibling tools and the single parameter, the description is incomplete. It fails to mention crucial context like element visibility, clicks causing navigation, or waiting behavior, leaving the agent with insufficient information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the 'selector' parameter with a clear definition. The description adds no extra meaning beyond the schema, which is acceptable given 100% coverage, but it does not enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Click an element') and the resource ('on the page'), distinguishing it from sibling tools like browser_fill or browser_hover. However, it could benefit from specifying that it operates within the current page context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as when to click vs. hover, or prerequisites like page navigation. The description lacks context for proper selection.
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 context
| 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, the description must fully disclose behavior. It mentions script execution but omits critical details: return value, side effects, permissions, sandboxing, or error handling. This is insufficient for a potentially powerful 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, clear sentence with no unnecessary words. It is optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should explain return values or behavior. It does not. Additionally, it lacks details on execution context (e.g., async support, timeout). This leaves the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single required parameter 'script' has a description in the schema. The tool description adds no additional meaning beyond what the schema already provides, making it adequate but not additive.
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 'Execute JavaScript in the browser context' clearly states the action and resource. It is specific and distinct from sibling tools like browser_click or api_get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., browser_navigate or API calls). An agent receives no context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fill a form input with text
| Name | Required | Description | Default |
|---|---|---|---|
| value | Yes | Text to enter in the field | |
| selector | Yes | CSS selector for input field |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral details, but it only says 'fill' without specifying whether it overwrites existing text, waits for elements, or handles disabled fields. This leaves significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loading the action. However, it could be slightly expanded with useful context while remaining brief.
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 simplicity of the tool (2 params, no output schema), the description is adequate but lacks details on behavior like clearing the field or submission. Sibling tools exist for other form actions, but no comparative guidance is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 100% of parameters with descriptions (selector and value), so baseline is 3. The description adds no additional semantic information beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fill a form input with text' clearly states the action (fill) and the target (form input), distinguishing it from sibling tools like browser_click or browser_select which perform different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as browser_evaluate for setting values or browser_click for activation. There is no mention of prerequisites like element visibility or state.
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 element to hover over |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states 'hover over an element' without explaining whether it triggers JavaScript events, waits for any transitions, or is safe. Essential behavioral context is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at 6 words and front-loaded. It is not verbose, but the brevity may sacrifice necessary detail. It earns its place but could be slightly more informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, no output schema), the description is incomplete. It does not mention the return value (likely void or success), side effects, or behavior after hovering. Sibling tools suggest a sequence of actions, but this tool's role is under-described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter 'selector' described as 'CSS selector for element to hover over'. The description adds no additional meaning beyond what the schema already provides, so it meets the baseline but does not enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Hover over an element on the page' clearly states the action (hover) and target (element on page). It differentiates from siblings like browser_click and browser_fill. However, it could be more specific about the effect (e.g., triggering hover state) but is not a tautology.
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 browser_click or browser_evaluate. The description lacks any context about prerequisites, typical scenarios, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Capture a screenshot of the current page or a specific element
| Name | Required | Description | Default |
|---|---|---|---|
| mask | No | Selectors for elements to mask | |
| name | Yes | Identifier for the screenshot | |
| fullPage | No | Capture full page height | |
| savePath | No | Path to save screenshot (default: user's Downloads folder) | |
| selector | No | CSS selector for element to capture |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as whether the capture affects the page state, any authorization requirements, or rate limits. It only states the action, leaving the agent without important context about side effects or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single well-formed sentence that directly states the tool's purpose. It wastes no words, though it could benefit from slightly more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is brief and lacks context about return values (e.g., image path), default behavior, or how the tool interacts with other browser tools. Given the five parameters and no output schema, the description should provide more operational context to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since schema description coverage is 100%, the baseline is 3. The description does not add additional meaning beyond the parameter names and schema descriptions; for example, it doesn't explain when to use fullPage or mask options more concretely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool captures a screenshot of the current page or a specific element, which is a specific verb-resource combination. It distinguishes itself from sibling tools like browser_navigate or browser_click by focusing on capture rather than navigation or element interaction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when a screenshot is needed, but it provides no explicit guidance on when to use it versus alternative methods (e.g., browser_evaluate for custom captures) or any exclusions (e.g., not for video capture).
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 menu
| Name | Required | Description | Default |
|---|---|---|---|
| value | Yes | Value or label to select | |
| selector | Yes | CSS selector for select element |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as whether it waits for options to load, supports custom dropdowns, triggers events, or requires scrolling. The description is too minimal to inform the agent of important behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded. However, it sacrifices completeness for brevity. It earns a 4 for being efficient, but could include more key details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that no annotations or output schema exist, the description is insufficiently complete. It does not explain return values, constraints, or behavior for complex dropdowns, leaving 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 input schema describes both parameters (selector and value) with 100% coverage. The description adds no additional meaning beyond the schema, so 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 it selects an option from a dropdown menu, using a specific verb and resource. It distinguishes from sibling tools like browser_fill (text input) and browser_click (clicking), though it could be more precise by specifying HTML <select> elements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., browser_click for custom dropdowns) or any prerequisites. No exclusions or context are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Change the browser's viewport size and scale factor
| Name | Required | Description | Default |
|---|---|---|---|
| width | No | Viewport width in pixels | |
| height | No | Viewport height in pixels | |
| deviceScaleFactor | No | Device scale factor (affects how content is scaled) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description should disclose behavioral traits. It only states what the tool changes, but not side effects (e.g., impact on screenshots, persistence across navigation). Lacks important context 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?
Single sentence, no fluff. Every word is relevant. Excellent 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?
Adequately describes the core function, but lacks details on required fields, defaults, or behavioral context. Acceptable for a simple tool, but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with meaningful descriptions for each parameter. The description adds no extra meaning beyond the schema, justifying the 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?
Description clearly states the action 'Change' and the target 'browser's viewport size and scale factor'. It is specific and distinct from sibling tools like browser_navigate or browser_click.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use guidance is provided. The description implies usage for adjusting viewport, but does not mention alternatives or exclusions. Minimal viable score.
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.
v1.0.0api_deleteapi_getapi_patchapi_postapi_putbrowser_clickbrowser_evaluatebrowser_fillbrowser_hoverbrowser_navigatebrowser_screenshotbrowser_selectbrowser_set_viewportScored across 13 tools
Each tool has a clearly distinct purpose: API tools are differentiated by HTTP method, and browser tools cover unique interactions like clicking, hovering, filling, etc. No two tools overlap in function.
All tools follow a consistent '<domain>_<action>' pattern, with 'api_' prefix for HTTP methods and 'browser_' prefix for browser actions. Naming is unambiguous and predictable.
13 tools is well-scoped for a browser automation and API testing server. Each tool covers a fundamental operation without unnecessary bloat or gaps.
Core browser interactions (navigation, clicking, form filling, selecting, screenshot) and all major HTTP methods are covered. Minor omissions like file upload or wait-for-element are acceptable for this scope.
AI-powered web automation. Navigate websites using AI agents for one page or a thousand
AI-powered web automation. Navigate websites using AI agents for one page or a thousand
AI-powered browser automation — navigate, click, fill forms, and extract data from any website.
An agent-first office suite Claude & ChatGPT read and write over one MCP URL.
