Композитный MCP-шлюз — он агрегирует несколько серверов Model Context Protocol за одним подключением, специально подобранных для рабочих процессов SDET / QE. Добавьте один сервер к вашему ИИ-ассистенту вместо пяти.
npx qualien-mcpИз коробки он предоставляет стартовую QE-пару — Playwright MCP (автоматизация браузера, DOM, скриншоты) и Filesystem MCP (чтение/редактирование файлов проекта, объекты страниц, тестовые утилиты) — без настройки. Инструменты предоставляются вашему ассистенту с пространствами имён вида playwright__… и filesystem__….
Ваш ассистент уже умеет подключаться ко многим MCP-серверам напрямую — поэтому шлюз оправдывает своё место, делая то, что не под силу куче серверов:
Единая точка входа — для добавления в любой клиент (Claude Code, Claude Desktop, Cursor, …).
Курирование — включение/отключение для каждого сервера и каждого инструмента. Меньше инструментов, но с лучшими именами = лучший выбор инструмента моделью (вываливание на неё 200 инструментов делает её хуже).
Единая поверхность маршрутизации/логирования — каждый вызов логируется в stderr с указанием нижестоящего сервера, инструмента и задержки.
Чистый жизненный цикл — запускает каждый нижестоящий сервер как дочерний процесс и завершает их все при выходе (без осиротевших процессов браузера).
Ориентированность на QE — авторский SDET-инструментарий, а не универсальный прокси.
Related MCP server: Multi-MCP Hub
Claude Code (.mcp.json или пользовательские настройки):
{
"mcpServers": {
"qualien": { "command": "npx", "args": ["-y", "qualien-mcp"] }
}
}Claude Desktop (claude_desktop_config.json) — та же структура внутри mcpServers.
Эта единственная запись даёт вашему ассистенту все инструменты всех агрегированных серверов.
Поместите qualien-mcp.config.json в рабочую директорию (или передайте --config <path>). Записи накладываются поверх встроенных значений по умолчанию — переопределите ключ, чтобы изменить его, или установите enabled: false, чтобы отключить стандартную возможность. Никаких новых релизов не требуется.
{
"servers": {
"filesystem": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem", "/abs/path/to/allow"]
},
"sequential-thinking": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-sequential-thinking"]
},
"chrome-devtools": {
"command": "npx",
"args": ["-y", "chrome-devtools-mcp@latest"]
},
"playwright": {
"command": "npx",
"args": ["-y", "@playwright/mcp@latest"],
"tools": { "deny": ["browser_close"] }
}
}
}Полную структуру (command, args, env, enabled, tools.allow / tools.deny) см. в qualien-mcp.config.example.json.
qualien-mcp поставляется с курируемым каталогом известных серверов (проверенных в npm), поэтому вы включаете нужный по ключу, указав только свои секреты — не нужно запоминать пакеты или команды:
{
"servers": {
"chrome-devtools": { "enabled": true },
"postgres": { "enabled": true, "env": { "DATABASE_URI": "postgres://…" } },
"slack": { "enabled": true, "env": { "SLACK_MCP_XOXP_TOKEN": "xoxp-…" } }
}
}Выполните npx qualien-mcp catalog, чтобы вывести их все с указанием требований каждого. Текущий каталог:
Ключ | Что делает | Требования |
| Автоматизация браузера, DOM, скриншоты | — |
| Чтение/редактирование файлов проекта | директория для доступа (по умолчанию cwd) |
| Пул-реквесты, задачи, ревью кода | ваш GitHub OAuth App + |
| Структурированные рассуждения / отладка | — |
| Постоянный граф знаний | — |
| Сеть, консоль, производительность, хранилище | — |
| SQL / проверка данных бэкенда |
|
| SQL / проверка данных бэкенда | переменные окружения MySQL |
| Чтение/публикация в Slack |
|
| Управление контейнерами | демон Docker |
| Просмотр/операции с кластером | kubeconfig |
| Взаимодействие с любым REST API через спецификацию |
|
| Чтение/обновление задач Jira | переменная окружения с API-токеном Atlassian |
| Чтение макетов Figma |
|
use монтирует сервер из каталога под другим ключом (например, две базы данных): { "db-prod": { "use": "postgres", "enabled": true, "env": {…} } }. Всё, чего нет в каталоге, вы по-прежнему определяете полностью (command/args или type/url).
Нижестоящие серверы могут быть удалёнными (Streamable HTTP), так же как и локальными. Удалённый сервер задаётся как { "type": "http", "url": "…" }, и если ему нужен OAuth, каждый пользователь входит в свою собственную учётную запись — токены хранятся для каждого пользователя в ~/.qualien-mcp/credentials.json (0600) и никогда не объединяются и не передаются.
Хостируемый MCP GitHub — эталонный случай. Он не поддерживает динамическую регистрацию клиентов, поэтому вы один раз регистрируете собственное приложение GitHub OAuth App и передаёте qualien-mcp его Client ID:
GitHub → Settings → Developer settings → OAuth Apps → New. Установите callback URL на http://127.0.0.1:41999/callback. Скопируйте Client ID.
В qualien-mcp.config.json:
{
"servers": {
"github": {
"type": "http",
"url": "https://api.githubcopilot.com/mcp/",
"oauth": true,
"clientId": "<your client id>"
}
}
}Авторизуйтесь (браузер откроется один раз):
npx qualien-mcp login githubПосле этого шлюз подключается к GitHub в неинтерактивном режиме (обновляя токены по мере необходимости) и предоставляет инструменты github__*. Если удалённый сервер ещё не авторизован, шлюз пропускает его с подсказкой (run: npx qualien-mcp login github) и продолжает обслуживать всё остальное — он никогда не блокирует запуск. Серверам, которые поддерживают динамическую регистрацию, clientId не требуется.
qualien-mcp применяет ограничения централизованно, перед передачей вызова — поэтому они действуют независимо от того, что разрешает нижестоящий сервер, и композитные инструменты тоже не могут их обойти:
Базы данных доступны только для чтения — вызовы postgres/mysql, содержащие записывающий/DDL SQL (INSERT/UPDATE/DELETE/DROP/…), отклоняются. Разрешается явно через { "postgres": { "readOnly": false } }.
Корни файловой системы — { "filesystem": { "roots": ["./src", "./tests"] } } отклоняет любой вызов, чей аргумент пути выходит за пределы этих директорий.
Деструктивные инфраструктурные инструменты блокируются — инструменты docker/kubernetes, имя которых выглядит деструктивным (delete/remove/prune/kill/…), отклоняются, если не задано { "allowDestructive": true }.
Плюс курирование tools.deny / tools.allow для каждого сервера.
Честная оценка: они мешают LLM случайно нанести вред. Проверка SQL основана на ключевых словах (эвристика), а не на парсере — это не песочница для защиты от вредоносных действий. Для настоящей изоляции нужны собственные разрешения нижестоящего сервера или контейнер.
Помимо сквозной передачи, qualien-mcp поставляет инструменты, которые он реализует сам (пространство имён qe__) и которые оркестрируют несколько нижестоящих серверов в одном вызове — в этом главная ценность шлюза для QE.
qe__verify_api_vs_db — сквозная проверка согласованности API↔БД в одном вызове. Передайте ему два подвызова (инструменты с пространствами имён, которые можно найти через tools/list); он выполнит оба и сравнит полезные нагрузки:
{
"api": { "tool": "openapi__getUser", "arguments": { "id": 1 } },
"db": { "tool": "postgres__query", "arguments": { "sql": "select id, name from users where id = 1" } },
"match": "subset" // every field the DB returns must match the API (default)
}
// → { "match": false, "differences": [ { "path": "name", "api": "Ann", "db": "Bob" } ], … }Композитные инструменты появляются только при подключении требуемых нижестоящих серверов (qe__verify_api_vs_db требует сервер database). В планах — больше (repro-from-Jira, page-object-from-URL, flaky triage).
В одном процессе qualien-mcp является одновременно MCP-сервером для вашего ассистента и MCP-клиентом для каждого нижестоящего сервера:
assistant ⇄ qualien-mcp ⇄ playwright-mcp
⇄ filesystem-mcp
⇄ …tools/list отправляет вызовы всем нижестоящим серверам, фильтрует по вашим правилам курирования и задаёт каждому пространство имён вида <server>__<tool>.
tools/call маршрутизирует по этому префиксу к серверу-владельцу и пробрасывает ответ насквозь.
Ресурсы и промпты агрегируются так же, когда их предоставляет нижестоящий сервер.
Нижестоящий сервер, который не смог запуститься, логируется и пропускается — шлюз продолжает обслуживать остальные.
Логи отправляются в stderr (stdout — это протокол); ваш хост показывает их в своих MCP-логах.
v0.1 — Playwright + Filesystem, пространства имён, курирование, логирование, чистый жизненный цикл ✅
Далее — расширение на основе конфигурации (GitHub через его размещённый OAuth MCP, БД, Sequential-Thinking, Memory, Chrome DevTools), композитные QE-инструменты (например, проверка согласованности API ↔ БД в одном вызове), определение границ безопасности.
MIT
Create a new directory or ensure a directory exists. Can create multiple nested directories in one operation. If the directory already exists, this operation will succeed silently. Perfect for setting up directory structures for projects or ensuring required paths exist. Only works within allowed directories.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
| Name | Required | Description |
|---|---|---|
| content | Yes |
Get a recursive tree view of files and directories as a JSON structure. Each entry includes 'name', 'type' (file/directory), and 'children' for directories. Files have no children array, while directories always have a children array (which may be empty). The output is formatted with 2-space indentation for readability. Only works within allowed directories.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| excludePatterns | No |
| Name | Required | Description |
|---|---|---|
| content | Yes |
Make line-based edits to a text file. Each edit replaces exact line sequences with new content. Returns a git-style diff showing the changes made. Only works within allowed directories.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| edits | Yes | ||
| dryRun | No | Preview changes using git-style diff format |
| Name | Required | Description |
|---|---|---|
| content | Yes |
Retrieve detailed metadata about a file or directory. Returns comprehensive information including size, creation time, last modified time, permissions, and type. This tool is perfect for understanding file characteristics without reading the actual content. Only works within allowed directories.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
| Name | Required | Description |
|---|---|---|
| content | Yes |
Returns the list of directories that this server is allowed to access. Subdirectories within these allowed directories are also accessible. Use this to understand which directories and their nested paths are available before trying to access files.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| content | Yes |
Get a detailed listing of all files and directories in a specified path. Results clearly distinguish between files and directories with [FILE] and [DIR] prefixes. This tool is essential for understanding directory structure and finding specific files within a directory. Only works within allowed directories.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
| Name | Required | Description |
|---|---|---|
| content | Yes |
Get a detailed listing of all files and directories in a specified path, including sizes. Results clearly distinguish between files and directories with [FILE] and [DIR] prefixes. This tool is useful for understanding directory structure and finding specific files within a directory. Only works within allowed directories.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| sortBy | No | Sort entries by name or size | name |
| Name | Required | Description |
|---|---|---|
| content | Yes |
Move or rename files and directories. Can move files between directories and rename them in a single operation. If the destination exists, the operation will fail. Works across different directories and can be used for simple renaming within the same directory. Both source and destination must be within allowed directories.
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | ||
| destination | Yes |
| Name | Required | Description |
|---|---|---|
| content | Yes |
Read the complete contents of a file as text. DEPRECATED: Use read_text_file instead.
| Name | Required | Description | Default |
|---|---|---|---|
| head | No | If provided, returns only the first N lines of the file | |
| path | Yes | ||
| tail | No | If provided, returns only the last N lines of the file |
| Name | Required | Description |
|---|---|---|
| content | Yes |
Read a file and return it as a base64-encoded content block with its MIME type. Image and audio files are returned as image/audio content; any other file type is returned as an embedded resource. Only works within allowed directories.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
| Name | Required | Description |
|---|---|---|
| content | Yes |
Read the contents of multiple files simultaneously. This is more efficient than reading files one by one when you need to analyze or compare multiple files. Each file's content is returned with its path as a reference. Failed reads for individual files won't stop the entire operation. Only works within allowed directories.
| Name | Required | Description | Default |
|---|---|---|---|
| paths | Yes | Array of file paths to read. Each path must be a string pointing to a valid file within allowed directories. |
| Name | Required | Description |
|---|---|---|
| content | Yes |
Read the complete contents of a file from the file system as text. Handles various text encodings and provides detailed error messages if the file cannot be read. Use this tool when you need to examine the contents of a single file. Use the 'head' parameter to read only the first N lines of a file, or the 'tail' parameter to read only the last N lines of a file. Operates on the file as text regardless of extension. Only works within allowed directories.
| Name | Required | Description | Default |
|---|---|---|---|
| head | No | If provided, returns only the first N lines of the file | |
| path | Yes | ||
| tail | No | If provided, returns only the last N lines of the file |
| Name | Required | Description |
|---|---|---|
| content | Yes |
Recursively search for files and directories matching a pattern. The patterns should be glob-style patterns that match paths relative to the working directory. Use pattern like '.ext' to match files in current directory, and '**/.ext' to match files in all subdirectories. Returns full paths to all matching items. Great for finding files when you don't know their exact location. Only searches within allowed directories.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| pattern | Yes | ||
| excludePatterns | No |
| Name | Required | Description |
|---|---|---|
| content | Yes |
Create a new file or completely overwrite an existing file with new content. Use with caution as it will overwrite existing files without warning. Handles text content with proper encoding. Only works within allowed directories.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| content | Yes |
| Name | Required | Description |
|---|---|---|
| content | Yes |
Perform click on a web page
| Name | Required | Description | Default |
|---|---|---|---|
| button | No | Button to click, defaults to left | |
| target | Yes | Exact target element reference from the page snapshot, or a unique element selector | |
| element | No | Human-readable element description used to obtain permission to interact with the element | |
| modifiers | No | Modifier keys to press | |
| doubleClick | No | Whether to perform a double click instead of a single click |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide destructiveHint=true and readOnlyHint=false. The description adds no additional behavioral context beyond stating the action. It does not disclose side effects (e.g., navigation, page state changes) or permission requirements, relying entirely on the 'destructive' hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise and front-loaded. However, it is too minimal to be informative; space could be better used to add context without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, no output schema, and multiple sibling tools, the description is very incomplete. It does not explain what happens after clicking (e.g., waiting for navigation, return value), the scope of interaction (openWorldHint=true), or how the 'target' parameter relates to the 'element' parameter. Significant gaps remain.
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 all parameters are documented in the schema. The tool description adds no extra meaning to parameters beyond what the schema already provides. A baseline of 3 is appropriate since the schema carries the burden.
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 'Perform click on a web page' clearly states the verb and resource, but it is vague and does not differentiate from sibling tools like hover, double-click (which is a parameter), or select_option. It is not a tautology but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., playwright__browser_hover, playwright__browser_drag). It does not mention when not to use it or any prerequisites. Without such guidance, an agent may select this tool inappropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Close the page
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'Close the page' while annotations (title: 'Close browser', destructiveHint: true, readOnlyHint: false) indicate it closes the browser. This contradiction between description and annotations makes the behavioral intent unclear. The description also fails to detail what state changes occur, confirmation steps, or whether the entire session is terminated.
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 (single sentence) but underspecified. While brevity is valued, the content is too sparse to be effectively informative, especially given the contradiction with annotations.
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 is simple with no parameters and no output schema, the description should at least unambiguously state what is closed (browser vs page) and any notable side effects. It fails to do so, leaving the agent confused about the tool's exact scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters (schema coverage 100% with empty object), so the description does not need to add parameter information. The baseline for zero parameters is 4, and the description does not detract from this.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Close the page', which is a verb+resource, but the tool name and annotation title indicate it closes the browser. This mismatch creates ambiguity about the actual resource being closed, lowering clarity. It does distinguish from siblings since no other sibling closes anything, but the inconsistency hurts the 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?
No guidance is provided on when to use this tool versus alternatives such as navigating away or using a different browser management tool. There is no context on prerequisites, side effects, or situations to avoid, leaving the agent to infer usage solely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns all console messages
| Name | Required | Description | Default |
|---|---|---|---|
| all | No | Return all console messages since the beginning of the session, not just since the last navigation. Defaults to false. | |
| level | Yes | Level of the console messages to return. Each level includes the messages of more severe levels. Defaults to "info". | info |
| filename | No | File name to save the console messages to. Relative file names are resolved against the workspace root. If not provided, messages are returned as text. |
Perform drag and drop between two elements
| Name | Required | Description | Default |
|---|---|---|---|
| endTarget | Yes | Exact target element reference from the page snapshot, or a unique element selector | |
| endElement | No | Human-readable target element description used to obtain the permission to interact with the element | |
| startTarget | Yes | Exact target element reference from the page snapshot, or a unique element selector | |
| startElement | No | Human-readable source element description used to obtain the permission to interact with the element |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations mark this as destructiveHint: true and openWorldHint: true, indicating the operation modifies state and relies on external context. The description does not elaborate on these or mention any other behavioral details (e.g., element visibility requirements, coordinate-based vs. element-based drag). It provides marginal added value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is direct and to the point. No wasted words, but could potentially include more context without becoming overly long.
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 a drag-and-drop operation (interaction with page elements, potential for state changes), and lack of output schema, the description is insufficient. It does not explain how elements are identified (via snapshot references), what happens to intermediate mouse events, or how errors are handled.
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%, meaning all parameters have descriptions in the schema. The description does not add extra meaning beyond what is already in the schema. 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 'drag and drop' action between two elements. The verb 'Perform' and resource 'drag and drop' are specific. It distinguishes from siblings like 'click' and 'hover', but not explicitly against 'browser_drop' which might be related.
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. For example, 'browser_drop' is a sibling with potentially overlapping functionality, and there is no mention of prerequisites like needing a page snapshot or permissions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Drop files or MIME-typed data onto an element, as if dragged from outside the page. At least one of "paths" or "data" must be provided.
| Name | Required | Description | Default |
|---|---|---|---|
| data | No | Data to drop, as a map of MIME type to string value (e.g. {"text/plain": "hello", "text/uri-list": "https://example.com"}). | |
| paths | No | Absolute paths to files to drop onto the element. | |
| target | Yes | Exact target element reference from the page snapshot, or a unique element selector | |
| element | No | Human-readable element description used to obtain permission to interact with the element |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, so the description adds the behavioral context of simulating a drag from outside the page. However, it does not mention potential side effects like triggering page navigation, file downloads, or that the element must be a valid drop target. The description adds moderate value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. The first sentence defines the core action, the second adds a critical constraint. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core functionality and constraints. It does not explain the permission mechanism for the 'element' parameter (covered in schema) or the need for a valid drop target, but for a specialized tool with a detailed schema, it is sufficiently complete. No output schema exists, but the return value is implied by the action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, baseline is 3. The description adds a usage constraint ('at least one of paths or data must be provided') that is not in the schema's required list, and clarifies the two modes. This adds meaningful value beyond the parameter descriptions in 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 verb 'drop' and the resource 'files or MIME-typed data onto an element'. It distinguishes from sibling tools like file_upload by specifying 'as if dragged from outside the page', and clarifies the two input modes with the constraint 'at least one of paths or data must be provided'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly distinguishes from file upload (for input elements) and drag (within-page), but does not explicitly state when to use this tool versus alternatives. It does provide a clear prerequisite: at least one of 'paths' or 'data' must be provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Emulate CSS media features for the page, for example switch between the light and dark color scheme. Omitted parameters are left unchanged; null clears an override.
| Name | Required | Description | Default |
|---|---|---|---|
| media | No | Changes the CSS media type of the page | |
| contrast | No | Emulates the prefers-contrast media feature | |
| colorScheme | No | Emulates the prefers-color-scheme media feature | |
| forcedColors | No | Emulates the forced-colors media feature | |
| reducedMotion | No | Emulates the prefers-reduced-motion media feature |
Evaluate JavaScript expression on page or element
| Name | Required | Description | Default |
|---|---|---|---|
| target | No | Exact target element reference from the page snapshot, or a unique element selector | |
| element | No | Human-readable element description used to obtain permission to interact with the element | |
| filename | No | File name to save the result to. Relative file names are resolved against the workspace root. If not provided, result is returned as text. | |
| function | Yes | () => { /* code */ } or (element) => { /* code */ } when element is provided |
Upload one or multiple files
| Name | Required | Description | Default |
|---|---|---|---|
| paths | No | The absolute paths to the files to upload. Can be single file or multiple files. If omitted, file chooser is cancelled. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive, non-read-only, and open-world behavior. The description adds no behavioral context beyond 'upload', such as side effects, interaction with the file chooser dialog, or state changes. The description adds minimal value over annotations for understanding implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two words plus a brief schema). It front-loads the verb and resource. However, it could be expanded slightly to include context without being verbose, but for a simple tool this is adequate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameter set, high schema coverage, and presence of annotations, the description is minimally adequate. It covers the basic action but lacks information about when the file chooser appears, whether the element must be an input[type=file], or how it interacts with other browser tools.
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% for the single parameter 'paths', which explains absolute paths, single/multiple files, and cancellation. The tool description adds no additional parameter meaning, 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 'Upload one or multiple files' clearly states the verb (upload) and resource (files). It distinguishes from sibling browser tools like navigate, click, and filesystem tools because 'upload' is specific to file selection in a browser context. However, it does not specify the target (e.g., to a file input element), which slightly reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. Siblings include filesystem write tools, but no context is provided about prerequisites (e.g., a file input must be focused) or when to avoid using it. The schema mentions cancellation, but overall usage direction is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fill multiple form fields
| Name | Required | Description | Default |
|---|---|---|---|
| fields | Yes | Fields to fill in |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide destructiveHint=true and readOnlyHint=false, so the agent knows this is a write operation. The description adds no further behavioral details (e.g., that it modifies the page, requires user interactions, or handles errors). With annotations present, the bar is lower, but the description still adds no value beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is front-loaded and efficient. However, it could be slightly more informative without sacrificing brevity, earning a 4 rather than 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested array with 5 sub-properties, no output schema), the description is far too minimal. It does not mention that the tool requires target references from a page snapshot, how it handles multiple fields, or what happens on failure. The schema provides structure but the description fails to contextualize the tool's purpose and 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 input schema already documents all parameters clearly (e.g., target, name, type, value). The description does not add any additional meaning or examples beyond what the schema provides. Baseline 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 'Fill multiple form fields' clearly states the action (fill) and resource (form fields). It distinguishes from sibling tools like 'type' (single field) and 'click' by implying batch operation, though it could be more explicit about the 'multiple' aspect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives (e.g., 'type' for single fields, 'click' for interactive elements). No prerequisites, such as needing a page snapshot or target references, are mentioned. The description is too terse to provide usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the accessibility snapshot of the current page for text or a regular expression. Returns matching snapshot nodes with a few lines of surrounding context (like search snippets), each shown under its path from the root of the tree, which is cheaper than capturing the whole snapshot when you only need to locate an element and its ref.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | Plain text to search for in the page snapshot (case-insensitive substring match). Provide either text or regex, not both. | |
| regex | No | Regular expression to search for in the page snapshot. Matching is case-sensitive by default; wrap the pattern in slashes to add flags, e.g. "/error/i" for case-insensitive. Provide either text or regex, not both. | |
| filename | No | Save results to a file instead of returning them in the response. Relative file names are resolved against the workspace root. |
Handle a dialog
| Name | Required | Description | Default |
|---|---|---|---|
| accept | Yes | Whether to accept the dialog. | |
| promptText | No | The text of the prompt in case of a prompt dialog. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare destructiveHint=true, indicating mutation potential. The description adds no further behavioral context beyond the title, but does not contradict annotations. No additional detail on what happens (e.g., dialog closed, page affected) is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, efficient and front-loaded. However, it is minimal and could say more without being 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 tool has 2 parameters, no output schema, and annotations are present but basic. The description does not explain return behavior or error conditions, leaving gaps about what the tool outputs or requires.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are fully described in the schema. The description adds no additional meaning beyond the schema, matching the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'handle a dialog', which identifies a specific browser interaction. However, it does not distinguish from siblings like invoking alerts or prompts, and the term 'dialog' is broad but implied by context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives is provided. The description lacks context about prerequisites (e.g., dialog must be present) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Hover over element on page
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Exact target element reference from the page snapshot, or a unique element selector | |
| element | No | Human-readable element description used to obtain permission to interact with the element |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint: true and openWorldHint: true, but the description adds no behavioral context beyond the obvious. It does not disclose that hovering may trigger mouseover events, change UI state, or require the element to be visible. The description fails to enrich the understanding provided by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that immediately conveys the core function. It is not verbose, but it is also not overly terse to the point of being useless. It earns its place by stating the purpose clearly.
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 hover tool, the description is too sparse. It lacks any context about return values, prerequisites (e.g., page loaded, element visible), side effects, or when to use hover over other interactions. Given the tool's 2 parameters and no output schema, the description should provide more guidance to compensate.
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% – both parameters (target and element) are already well-described in the schema. The tool description 'Hover over element on page' adds no additional meaning or usage hints for the parameters. 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 'Hover over element on page' clearly states the action (hover) and the target (element on a page). It distinguishes from sibling tools by naming a specific interaction, but it is brief and could be more precise about the nature of the hover (e.g., triggering mouse events).
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 vs. alternatives like playwright__browser_click, playwright__browser_drop, or playwright__browser_find. It does not mention prerequisites, constraints, or scenarios where hovering is appropriate. This is a significant gap given the large sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns full details (headers and body) of a single network request, or a single part if part is set. Use the number from browser_network_requests.
| Name | Required | Description | Default |
|---|---|---|---|
| part | No | Return only this part of the request. Omit to return full details. | |
| index | Yes | 1-based index of the request, as printed by browser_network_requests. | |
| filename | No | File name to save the result to. Relative file names are resolved against the workspace root. If not provided, output is returned as text. |
Returns a numbered list of network requests since loading the page. Use browser_network_request with the number to get full details.
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | Only return requests whose URL matches this regexp (e.g. "/api/.*user"). | |
| static | Yes | Whether to include successful static resources like images, fonts, scripts, etc. Defaults to false. | |
| filename | No | File name to save the network requests to. Relative file names are resolved against the workspace root. If not provided, requests are returned as text. |
Press a key on the keyboard
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Name of the key to press or a character to generate, such as `ArrowLeft` or `a` |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is minimal and adds little beyond the annotations. Annotations already show destructiveHint=true and readOnlyHint=false, implying mutation, but the description does not explain what side effects occur (e.g., navigation, form submission, or triggering shortcuts). Without annotations, this would score lower, but the descriptions should supplement the annotations with context like "This can trigger browser keyboard shortcuts or activate form submission." The description merely restates the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it is too terse and lacks structure. It does not front-load crucial details like supported key formats or behavioral notes. The sentence is earned, but it could be expanded slightly to improve completeness 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 destructiveHint=true annotation and the lack of an output schema, the description should explain what happens after the key press (e.g., does the browser navigate? Does a form submit?). With many sibling tools and only one parameter, the description is inadequate for an AI agent to fully understand when and how to use it safely.
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% for the single parameter 'key', and its description is comprehensive: 'Name of the key to press or a character to generate, such as `ArrowLeft` or `a`'. The tool description adds no further 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 "Press a key on the keyboard" clearly identifies the verb (press) and resource (key on keyboard), but it does not distinguish this tool from similar sibling tools like playwright__browser_type or playwright__browser_click. The purpose is clear but lacks specificity about what types of keys or combinations are supported.
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 playwright__browser_type (for typing text) or playwright__browser_click (for mouse actions). It does not explain if this tool is suitable for key combinations (e.g., Ctrl+C), special keys, or single character keys, nor does it mention prerequisites such as having a focused element. The explicit destructiveHint=true annotation suggests it may cause state changes, but the description does not elaborate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resize the browser window
| Name | Required | Description | Default |
|---|---|---|---|
| width | Yes | Width of the browser window | |
| height | Yes | Height of the browser window |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with annotations: destructiveHint=true indicates state change, which resizing implies. However, it adds no additional behavioral context beyond what the annotations already convey. The description is consistent and sufficient when combined with annotations, but it does not elaborate on side effects like viewport changes or page re-layout.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of five words with no wasted words. It is front-loaded and 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?
Given the tool's simplicity (two numeric parameters, no output schema), the description is borderline adequate. It does not specify units (pixels), constraints, or how resizing interacts with the page. While the core action is clear, additional context like 'changes the viewport size' or 'affects page layout' would improve completeness without becoming verbose.
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 both parameters having descriptions (width and height). The description does not add any meaning beyond the schema; it simply restates the action. Baseline 3 is appropriate as the schema already documents the parameters adequately.
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 'Resize the browser window' is clear, specific, and uses a verb-resource pair. It uniquely identifies the action among sibling tools, as no other tool handles resizing. The purpose is immediately obvious.
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 does not mention prerequisites, constraints, or when resizing is appropriate. Sibling tools like 'playwright__browser_navigate' or 'playwright__browser_take_screenshot' are unrelated, but no explicit when-not or context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a Playwright code snippet. Unsafe: executes arbitrary JavaScript in the Playwright server process and is RCE-equivalent.
| Name | Required | Description | Default |
|---|---|---|---|
| code | No | A JavaScript function containing Playwright code to execute. It will be invoked with a single argument, page, which you can use for any page interaction. For example: `async (page) => { await page.getByRole('button', { name: 'Submit' }).click(); return await page.title(); }` | |
| filename | No | Load code from the specified file. Relative file names are resolved against the workspace root. If both code and filename are provided, code will be ignored. |
Select an option in a dropdown
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Exact target element reference from the page snapshot, or a unique element selector | |
| values | Yes | Array of values to select in the dropdown. This can be a single value or multiple values. | |
| element | No | Human-readable element description used to obtain permission to interact with the element |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations mark this as destructiveHint:true (modifies UI) and readOnlyHint:false, which is consistent. The description adds no further behavioral details about side effects (e.g., triggering events, page reloads). It is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence) and front-loaded. It is appropriately concise for a simple action, but could be slightly expanded with usage hints without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 params, all described in schema), the description is minimally adequate. However, it lacks context about return value (none provided) or multi-select behavior, which would help completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add additional semantics beyond what the schema provides (e.g., explaining how 'values' interact, or when 'element' is necessary). It relies fully on 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 tool selects an option in a dropdown, which is a specific verb+resource. It distinguishes well from siblings like 'fill_form', 'click', and 'type', which are for different interactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool vs alternatives like 'fill_form' or 'click' for dropdowns. It does not mention prerequisites (e.g., needing a page snapshot first) or exclusion scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Capture accessibility snapshot of the current page, this is better than screenshot
| Name | Required | Description | Default |
|---|---|---|---|
| boxes | No | Include each element's bounding box as [box=x,y,width,height] in the snapshot. Coordinates are viewport-relative, in CSS pixels (Element.getBoundingClientRect) | |
| depth | No | Limit the depth of the snapshot tree | |
| target | No | Exact target element reference from the page snapshot, or a unique element selector | |
| filename | No | Save snapshot to a file instead of returning it in the response. Relative file names are resolved against the workspace root. |
List, create, close, or select a browser tab.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | URL to navigate to in the new tab, used for new. | |
| index | No | Tab index, used for close/select. If omitted for close, current tab is closed. | |
| action | Yes | Operation to perform |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint=true and readOnlyHint=false, so the description's 'create, close' is consistent but adds no new behavioral insight. It does not disclose error handling (e.g., what happens if you close a non-existent tab), side effects of 'select' (focus changes), or the fact that openWorldHint=true implies external side effects. The description is too minimal to add value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is very concise and front-loaded. It lists the actions without any filler. However, it could be more structured (e.g., bullet points) to improve readability, but it is 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?
With no output schema, the description should explain what the tool returns for each action (e.g., for 'list', a list of tabs; for 'new', the new tab's info). It does not do this. Additionally, the description does not mention the tool's scope (e.g., operates on the current browser context). The tool has multiple actions and no output documentation, making it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents each parameter (url, index, action). The description does not add any extra meaning or clarify usage of the parameters beyond what the schema provides. 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 specific verb-resource combination: 'List, create, close, or select a browser tab.' This directly addresses the four distinct actions the tool performs, and it distinguishes the tool from sibling tools like playwright__browser_navigate (which navigates the current tab) and playwright__browser_close (which closes the entire browser).
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 does not mention that for navigating the current page one should use playwright__browser_navigate, or that closing the browser should use playwright__browser_close. The actions are listed but without context of trade-offs or prerequisites.
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. You can't perform actions based on the screenshot, use browser_snapshot for actions.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Image format for the screenshot. If unset, inferred from the filename extension, otherwise png. | |
| scale | Yes | Image resolution scale. "css" produces a screenshot sized in CSS pixels (smaller, consistent across devices). "device" produces a high-resolution screenshot using device pixels (larger, accounts for the device pixel ratio). Default is css. | css |
| target | No | Exact target element reference from the page snapshot, or a unique element selector | |
| element | No | Human-readable element description used to obtain permission to interact with the element | |
| filename | No | File name to save the screenshot to. Relative file names are resolved against the workspace root. If not specified, the screenshot is saved into the output directory as `page-{timestamp}.{png|jpeg|webp}`. | |
| fullPage | No | When true, takes a screenshot of the full scrollable page, instead of the currently visible viewport. Cannot be used with element screenshots. |
Type text into editable element
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to type into the element | |
| slowly | No | Whether to type one character at a time. Useful for triggering key handlers in the page. By default entire text is filled in at once. | |
| submit | No | Whether to submit entered text (press Enter after) | |
| target | Yes | Exact target element reference from the page snapshot, or a unique element selector | |
| element | No | Human-readable element description used to obtain permission to interact with the element |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds little beyond annotations. While annotations indicate the tool is destructive (destructiveHint: true) and not read-only, the description does not elaborate on side effects (e.g., replacing content, pressing Enter with submit, typing character by character with slowly). The agent gains minimal behavioral context from the description alone.
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, containing no wasted words. It front-loads the core action. However, it is perhaps too brief given the tool's multiple parameters and behavioral nuances, but still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With five parameters and no output schema, the description should provide a fuller picture of the tool's behavior. It does not explain how the tool interacts with the page (e.g., focusing the element, clearing content), nor does it mention the optional 'slowly' or 'submit' behaviors. The agent would need to rely heavily on the schema and trial-and-error.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds the context that the element must be 'editable', which is not in the schema. This provides marginal additional meaning, but no further parameter detail beyond what the schema already supplies.
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 'Type text into editable element' uses a specific verb and resource, clearly indicating the tool inputs text into an editable field. However, it does not distinguish itself from sibling tools like playwright__browser_fill_form or playwright__browser_press_key, which also involve text entry, so it loses a point.
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. Siblings such as fill_form (for multiple fields), press_key (for single keys), or click (to focus) are not mentioned, nor are any exclusions or prerequisites given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wait for text to appear or disappear or a specified time to pass
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | The text to wait for | |
| time | No | The time to wait in seconds, at most 30 | |
| textGone | No | The text to wait for to disappear |
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.4.1filesystem__create_directory2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"filesystem__directory_tree2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"filesystem__edit_file2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"filesystem__get_file_info2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"filesystem__list_allowed_directories2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"filesystem__list_directory2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"filesystem__list_directory_with_sizes2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"filesystem__move_file2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"filesystem__read_file2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"filesystem__read_media_file2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"filesystem__read_multiple_files2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"filesystem__read_text_file2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"filesystem__search_files2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"filesystem__write_file2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"playwright__browser_console_messages1 field changedInput schema / properties / filename / descriptionPrevious value: -"Filename to save the console messages to. If not provided, messages are returned as text."New value: +"File name to save the console messages to. Relative file names are resolved against the workspace root. If not provided, messages are returned as text."playwright__browser_emulate_mediaplaywright__browser_evaluate1 field changedInput schema / properties / filename / descriptionPrevious value: -"Filename to save the result to. If not provided, result is returned as text."New value: +"File name to save the result to. Relative file names are resolved against the workspace root. If not provided, result is returned as text."playwright__browser_find1 field changedInput schema / properties / filenameAdded value: +{
+ "description": "Save results to a file instead of returning them in the response. Relative file names are resolved against the workspace root.",
+ "type": "string"
+}playwright__browser_network_request1 field changedInput schema / properties / filename / descriptionPrevious value: -"Filename to save the result to. If not provided, output is returned as text."New value: +"File name to save the result to. Relative file names are resolved against the workspace root. If not provided, output is returned as text."playwright__browser_network_requests1 field changedInput schema / properties / filename / descriptionPrevious value: -"Filename to save the network requests to. If not provided, requests are returned as text."New value: +"File name to save the network requests to. Relative file names are resolved against the workspace root. If not provided, requests are returned as text."playwright__browser_run_code_unsafe1 field changedInput schema / properties / filename / descriptionPrevious value: -"Load code from the specified file. If both code and filename are provided, code will be ignored."New value: +"Load code from the specified file. Relative file names are resolved against the workspace root. If both code and filename are provided, code will be ignored."playwright__browser_snapshot1 field changedInput schema / properties / filename / descriptionPrevious value: -"Save snapshot to markdown file instead of returning it in the response."New value: +"Save snapshot to a file instead of returning it in the response. Relative file names are resolved against the workspace root."playwright__browser_take_screenshot1 field changedInput schema / properties / filename / descriptionPrevious value: -"File name to save the screenshot to. Defaults to `page-{timestamp}.{png|jpeg|webp}` if not specified. Prefer relative file names to stay within the output directory."New value: +"File name to save the screenshot to. Relative file names are resolved against the workspace root. If not specified, the screenshot is saved into the output directory as `page-{timestamp}.{png|jpeg|webp}`."playwright__browser_wait_for1 field changedInput schema / properties / time / descriptionPrevious value: -"The time to wait in seconds"New value: +"The time to wait in seconds, at most 30"v0.4.0filesystem__create_directoryfilesystem__directory_treefilesystem__edit_filefilesystem__get_file_infofilesystem__list_allowed_directoriesfilesystem__list_directoryfilesystem__list_directory_with_sizesfilesystem__move_filefilesystem__read_filefilesystem__read_media_filefilesystem__read_multiple_filesfilesystem__read_text_filefilesystem__search_filesfilesystem__write_fileplaywright__browser_clickplaywright__browser_closeplaywright__browser_console_messagesplaywright__browser_dragplaywright__browser_dropplaywright__browser_evaluateplaywright__browser_file_uploadplaywright__browser_fill_formplaywright__browser_findplaywright__browser_handle_dialogplaywright__browser_hoverplaywright__browser_navigateplaywright__browser_navigate_backplaywright__browser_network_requestplaywright__browser_network_requestsplaywright__browser_press_keyplaywright__browser_resizeplaywright__browser_run_code_unsafeplaywright__browser_select_optionplaywright__browser_snapshotplaywright__browser_tabsplaywright__browser_take_screenshotplaywright__browser_typeplaywright__browser_wait_forScored across 38 tools
The tools are mostly distinct as they are grouped by 'playwright__' and 'filesystem__' prefixes and have clear action-target descriptions, though a few like 'read_file' and 'read_text_file' could be confused, especially with the deprecation note.
The naming convention is largely consistent with a pattern of 'module__verb_noun' (e.g., playwright__browser_click, filesystem__read_text_file). Minor inconsistency arises with some 'playwright__browser_' tools that use somewhat different verb phrasing (e.g., 'run_code_unsafe' vs 'evaluate'), and the presence of a deprecated 'read_file' alongside the preferred 'read_text_file' is confusing.
With 38 tools, the set is on the high side. While it covers browser automation and file system operations fairly thoroughly, the sheer number could be overwhelming and suggests potential for consolidation or trimming of overlapping or rarely useful tools.
The file system tools provide a comprehensive set for read, write, edit, search, and directory management. The browser tools cover navigation, interaction, and inspection well. Minor gaps exist, such as lacking a dedicated tool for clearing browser data or handling multiple dialogs, but the core workflows are well supported.
Unified gateway exposing 150+ tools across all NexGenData MCP servers via one endpoint.
Governed MCP gateway: one endpoint for your tools, with credential custody and audit log.
MCP gateway with runtime security policy, tool-call-level control, and audit of agent actions.
Marketplace gateway: 100+ services and 1,400+ tools behind one MCP connection with unified auth