A lightweight MCP server for controlling Arc Browser on macOS, optimized for frontend development with 30 tools.
Tab Management: Open URLs (new/current tab), list, switch, close, and reload tabs.
Navigation: Navigate back in browser history.
DOM Interaction: Click (including double-click), hover, fill inputs/forms (individually or in bulk), press key combinations, drag-and-drop, upload files, and wait for elements or text to appear.
JavaScript Execution: Run arbitrary JavaScript (with async/await support) in the page context.
Page Information: Retrieve page text, full HTML, page details (URL, title, viewport, UserAgent), meta tags, and form structures.
Screenshots: Capture screenshots via macOS screencapture (selection or window mode).
Console Monitoring: Start, collect (with level filtering), and stop console log capture.
Network Monitoring: Start, collect, and stop monitoring of fetch/XHR requests (with optional URL filter).
Storage & Cookies: Access localStorage, sessionStorage, and all page cookies.
Dialog Handling: Accept or dismiss browser dialogs (alert, confirm, prompt).
Provides tools to control the Arc browser, including tab management, DOM interaction, JavaScript execution, screenshot capture, console/network monitoring, and more.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@arc-lite-mcp open https://github.com in a new tab"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
フロントエンド開発に最適化された Arc Browser 制御用の軽量 MCP サーバーです。 AppleScript と JavaScript インジェクションを組み合わせ、必要十分な 30 ツールに絞ったコンパクトな構成を提供します。
対応環境: macOS 専用（AppleScript を使用）
軽量: フル版（76ツール）からフロントエンド開発に必須の機能のみを厳選した 30 ツール構成
依存最小: @modelcontextprotocol/sdk のみ
DOM操作対応: クリック、入力、フォーム送信、ドラッグなどの実操作をサポート
デバッグ機能: コンソール / ネットワーク監視、スクリーンショット取得
Related MCP server: arc-devtools-mcp
ツール | 説明 |
| URL を開く（新規タブ / 現在のタブ） |
| すべてのタブを一覧表示 |
| タブを切り替える |
| タブを閉じる |
| タブをリロード |
ツール | 説明 |
| 履歴を戻る |
ツール | 説明 |
| 要素をクリック |
| 要素にホバー |
| 入力欄に値を入力 |
| フォーム一括入力 |
| キー入力を送信 |
| ドラッグ操作 |
| ファイルアップロード |
| 要素の出現を待機 |
ツール | 説明 |
| 任意の JavaScript を実行 |
| ページのテキストを取得 |
| ページの HTML を取得 |
| ページ詳細情報（URL、ビューポート、UserAgent） |
| メタタグ情報（SEO 確認用） |
| フォーム情報を取得 |
ツール | 説明 |
| スクリーンショットを取得（macOS の |
ツール | 説明 |
| コンソールログのキャプチャを開始 |
| キャプチャしたログを取得 |
| コンソールキャプチャを停止 |
ツール | 説明 |
| ネットワークリクエスト（fetch/XHR）の監視を開始 |
| 監視中のリクエスト一覧を取得 |
| ネットワーク監視を停止 |
ツール | 説明 |
| ダイアログ（alert / confirm / prompt）を処理 |
| localStorage / sessionStorage の情報を取得 |
| Cookie 一覧を取得 |
git clone https://github.com/yzanbo/arc-lite-mcp.git
cd arc-lite-mcp
npm install~/.claude.json の mcpServers に以下を追加します:
{
"mcpServers": {
"arc-lite": {
"type": "stdio",
"command": "node",
"args": [
"/絶対パス/arc-lite-mcp/server/index.js"
]
}
}
}
/絶対パス/はgit cloneした実際の場所に置き換えてください。
初回実行時に macOS の権限プロンプトが表示されます:
システム設定 > プライバシーとセキュリティ > オートメーション を開く
Claude（もしくは利用クライアント）を探す
Arc を有効にする
arc_open_url で https://example.com を開いて
arc_list_tabs でタブ一覧を表示して
arc_switch_tab で 2 番目のタブに切り替えてarc_fill で "#email" に "test@example.com" を入力して
arc_fill で "#password" に "secret" を入力して
arc_click で "button[type=submit]" をクリックして
arc_wait_for で ".dashboard" の表示を待ってarc_start_console_capture でコンソール監視を開始して
arc_start_network_monitor でネットワーク監視を開始して
（アプリを操作）
arc_get_console_logs で error レベルのログを取得して
arc_get_network_requests で API リクエストを確認してarc_get_page_info でページ詳細を取得して
arc_get_meta_tags でメタタグを確認して
arc_get_page_forms でフォーム構造を取得してarc_take_screenshot でスクリーンショットを撮って
→ ドラッグで範囲を選択するとキャプチャされるシステム設定でオートメーション権限を確認
利用クライアント（Claude Code 等）を再起動
Arc Browser が起動していることを確認
/Applications/Arc.app にインストールされていることを確認
CSP（Content Security Policy）制限のあるページでは動作しない場合があります
監視はページリロード後にリセットされます
監視開始後のリクエスト / ログのみがキャプチャされます
MIT
指定したセレクタの要素をクリックする
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | CSSセレクタ | |
| dblClick | No | ダブルクリックするかどうか（デフォルト: false） | |
| tab_index | No | タブのインデックス（指定しない場合はアクティブタブ） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description carries full burden but only states basic click action. Fails to disclose potential side effects (e.g., navigation, dialog triggering, element state changes) or safety profile.
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, concise and front-loaded. Could include brief usage note without becoming verbose. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple click tool, description provides basic action but misses behavioral context (e.g., clicking may cause navigation) and doesn't leverage schema parameter info to elaborate on double-click. Adequate but not 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 descriptions for all three parameters. Description adds no additional meaning beyond the schema (e.g., no clarification on selector specificity or double-click behavior). Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description 'Click on element with specified selector' clearly states verb (click) and resource (element). It distinguishes from siblings like arc_drag and arc_fill, but lacks explicit differentiation from other click-like 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 on when to use this tool versus alternatives. No context about prerequisites or scenarios (e.g., single vs double click). Agent must infer from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
指定したタブを閉じる
| Name | Required | Description | Default |
|---|---|---|---|
| tab_index | No | タブのインデックス（1から始まる） | |
| url | No | 閉じるタブのURL（部分一致） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must fully disclose behavior. It only says 'close' with no mention of side effects (e.g., whether tab is closed silently, what happens if the tab doesn't exist, or if the window auto-closes). This is insufficient for a destructive action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no extraneous words. It is appropriately concise but could benefit from slightly more detail about parameter interaction.
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 close operation with well-described parameters, the description is minimally adequate. However, it lacks information about parameter precedence and post-close behavior, which would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters (tab_index with 1-based index, url as partial match). The description adds no additional semantics beyond what the schema already provides, meeting the baseline.
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 closes a tab ('指定したタブを閉じる'), which is specific to closing, distinguishing it from switching or duplicating tabs. However, it does not indicate that closing can be done by tab index or URL.
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 like arc_close_window, what to do if both parameters are provided, or prerequisites. The description offers no context about appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
要素を別の要素にドラッグ&ドロップする
| Name | Required | Description | Default |
|---|---|---|---|
| from_selector | Yes | ドラッグ元のCSSセレクタ | |
| to_selector | Yes | ドロップ先のCSSセレクタ | |
| tab_index | No | タブのインデックス（指定しない場合はアクティブタブ） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose behavioral traits such as whether mouse events are simulated, if viewport scrolling is handled, or if the elements must be visible. Basic action purpose is conveyed, but key behavioral details are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is appropriately sized and front-loaded, communicating the core purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite parameter descriptions, the description omits return value, error states, prerequisites (e.g., element visibility), and any side effects. For a simple action, it is incomplete; more context would help agents.
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 each parameter described. The description adds no additional meaning beyond the parameter names and schema descriptions, so a 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 '要素を別の要素にドラッグ&ドロップする' clearly states the action (drag and drop) and the resources (elements). It distinguishes from sibling tools like arc_click or arc_hover, which are not drag 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?
The description does not provide explicit guidance on when to use this tool versus alternatives. Usage is implied by the action name, but no context or exclusion criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
JavaScriptコードを実行する（async/await対応、エラーハンドリング付き）
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | 実行するJavaScriptコード（async関数として実行される） | |
| tab_index | No | タブのインデックス（指定しない場合はアクティブタブ） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behaviors. It mentions async/await and error handling but omits critical details like execution context, side effects, permissions, or return value format.
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 Japanese sentence with no unnecessary words. Every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Missing critical context: no mention of return value (result of execution or status), execution scope, or constraints. For a code execution tool without output schema or annotations, this is insufficient.
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 parameter descriptions. The description adds value by specifying that code executes as an async function and that tab_index defaults to active tab, going beyond schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Execute JavaScript code' with features like async/await and error handling. However, it does not explicitly differentiate from siblings like arc_inject_css or other execution tools, though the uniqueness is implied.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description lacks explicit context for usage scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
input、textarea に値を入力する、または select から選択する
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | CSSセレクタ | |
| value | Yes | 入力する値 | |
| tab_index | No | タブのインデックス（指定しない場合はアクティブタブ） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral details such as event triggering, error handling, or support for disabled elements, leaving the agent with significant unknowns.
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. While it lacks structure, it efficiently conveys the core purpose without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple fill tool, the description is moderately complete but misses behavioral details like whether values are cleared before input or if change events are fired. No output schema is present, so return behavior is unclear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds value beyond the schema by specifying the element types (input, textarea, select) that the selector should target, which is not present in parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (input value or select) and the target elements (input, textarea, select). It distinguishes from generic fill tools but doesn't explicitly differentiate from sibling 'arc_fill_form'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like 'arc_fill_form' or 'arc_click'. The description lacks context about prerequisites or explicit usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
複数のフォーム要素に一括で値を入力する
| Name | Required | Description | Default |
|---|---|---|---|
| fields | Yes | 入力するフィールドの配列 | |
| tab_index | No | タブのインデックス（指定しない場合はアクティブタブ） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden but only states the action. No disclosure of side effects, error behavior, preconditions (e.g., page loaded), or whether it is destructive. Missing key behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence that is front-loaded with the core action. Every word is essential; no superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers the basic purpose, for a tool with no output schema and no annotations, more contextual details (e.g., active tab behavior, handling of missing elements) would improve completeness. Adequate but not enriched.
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% and already describes `fields` and `tab_index` adequately. The description adds no additional meaning beyond affirming it works on multiple elements, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly specifies the action ('input values'), the target ('multiple form elements'), and the batch nature ('at once'). It effectively distinguishes from similar tools like `arc_fill` which likely fills a single element.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives (e.g., `arc_fill` for single fields). The description implies batch use but does not state scenarios where it is preferred or avoided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
キャプチャしたコンソールログを取得する
| Name | Required | Description | Default |
|---|---|---|---|
| level | No | フィルタするログレベル（デフォルト: all） | |
| limit | No | 取得する最大件数（デフォルト: 100） | |
| includePreservedMessages | No | 過去のナビゲーションで保存されたメッセージも含めるか（デフォルト: false） | |
| tab_index | No | タブのインデックス（指定しない場合はアクティブタブ） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only says 'get captured console logs'. No disclosure of blocking behavior, data freshness, or side effects. Agent cannot assess if it's a safe read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single short sentence with no redundancy. Could be slightly more informative, but it is not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no description of return values, pagination, or behavior when no logs. Despite 100% parameter coverage, the description lacks completeness for a retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 4 parameters with descriptions (100% coverage). Description adds no extra meaning beyond the schema. Baseline 3 is appropriate as schema handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it retrieves captured console logs, but does not differentiate from sibling tool 'arc_get_console_message'. The purpose is clear but ambiguous among alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'arc_get_console_message' or 'arc_start_console_capture'. No context on prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
すべてのCookieを取得する（名前、値、詳細情報）
| Name | Required | Description | Default |
|---|---|---|---|
| tab_index | No | タブのインデックス（指定しない場合はアクティブタブ） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose behavioral details beyond the basic action. It does not clarify whether cookies are scoped to the current tab/domain or all browser cookies, nor does it mention read-only nature or any side effects. With no annotations, the description carries full burden but falls short.
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 conveys the essential purpose without unnecessary words. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should explain the return format. While it mentions 'name, value, detailed info,' it is vague and does not specify structure (e.g., array, object). The scope of 'all cookies' is ambiguous, leaving gaps for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the single parameter 'tab_index' with 100% description coverage, so the baseline is 3. The description does not add any extra meaning or context for the parameter, but the schema already provides sufficient documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves all cookies, specifying the data returned (name, value, detailed info). The verb 'get' and resource 'cookies' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use or avoid this tool. There are no mentions of prerequisites, alternatives, or specific contexts, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ページのメタタグ情報を取得する（SEO確認用）
| Name | Required | Description | Default |
|---|---|---|---|
| tab_index | No | タブのインデックス（指定しない場合はアクティブタブ） |
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 is read-only, what permissions are needed, or the format of the returned data. It only states the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the main action and context, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema, no annotations), the description is minimally adequate but lacks details about the return value and edge cases. It leaves some interpretation to the 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?
With 100% schema description coverage, the description adds no new meaning beyond the schema's description of the tab_index parameter. 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 verb '取得する' (get) and the resource 'メタタグ情報' (meta tag information) with context 'SEO確認用' (for SEO verification), distinguishing it from sibling tools like arc_get_page_content or arc_get_page_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only implies use for SEO verification, but provides no explicit guidance on when to use this tool versus alternatives like arc_get_page_content or arc_get_page_html, and no mention of 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.
監視中のネットワークリクエスト一覧を取得する
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 取得する最大件数（デフォルト: 50） | |
| includePreservedRequests | No | 過去のナビゲーションで保存されたリクエストも含めるか（デフォルト: false） | |
| tab_index | No | タブのインデックス（指定しない場合はアクティブタブ） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose behavioral details such as whether network monitoring must be active, how requests are collected, or any side effects. Only the basic functionality is stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It could be slightly more informative but is appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (3 optional params, no output schema, no annotations), the description is minimal and lacks explanation of what 'being monitored' means or how results are delivered. It is adequate but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters are documented in the input schema. The description adds no additional meaning beyond the schema, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool gets a list of network requests being monitored, which is a clear verb-resource combination. It implicitly distinguishes from 'arc_get_network_request' (singular) but does not explicitly contrast with siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like arc_get_network_request or arc_start_network_monitor. The description does not mention prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ページのテキストコンテンツを取得する
| Name | Required | Description | Default |
|---|---|---|---|
| tab_index | No | タブのインデックス（指定しない場合はアクティブタブ） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only states the basic function without revealing traits such as read-only safety, performance implications, or limitations (e.g., content restrictions).
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 to the point. However, it is too minimal and lacks additional context that could be added without verbosity, such as clarifying 'text content' or output format.
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, full parameter description in schema, and absence of output schema or annotations, the description is minimally adequate. It covers the core functionality but could be more complete by specifying the return type or behavior for empty pages.
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 the single parameter 'tab_index' already described (index or active tab). The description adds no extra meaning beyond the schema, meeting 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 retrieves the text content of a page, using the specific verb 'get' and distinct resource 'text content'. This differentiates it from sibling tools like arc_get_page_html (HTML) and arc_get_page_links (links).
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 scenarios, exclusions, or prerequisites for using the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ページ内のフォーム情報を取得する
| Name | Required | Description | Default |
|---|---|---|---|
| tab_index | No | タブのインデックス（指定しない場合はアクティブタブ） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behaviors, but it only states the basic action. No mention of side effects, permissions, scope (e.g., all forms or specific), or return format.
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 concise single sentence that clearly conveys the core purpose. No unnecessary words, but could benefit from slightly more detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description is adequate but leaves ambiguity about what exactly is returned. Some additional context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'tab_index' is fully documented in the schema, so the description adds no extra meaning. Schema coverage is 100%, 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 retrieves form information from a page, using a specific verb and resource. It distinguishes from siblings like 'arc_fill_form' and 'arc_get_page_content', though not explicitly.
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, such as when forms need to be filled (arc_fill_form) or when page content is needed (arc_get_page_content). No context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ページのHTML全体を取得する
| Name | Required | Description | Default |
|---|---|---|---|
| tab_index | No | タブのインデックス（指定しない場合はアクティブタブ） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry the transparency burden. It implies a read operation ('get') but does not disclose potential size limits, blocking behavior, or authorization needs. Lacks detail but is not misleading. Scores 3 as minimal adequacy.
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 front-loads the core action. Every character is necessary; no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema), the description is contextually adequate for basic understanding. However, it lacks usage guidance and behavioral details that would make it complete for an agent navigating many sibling 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 coverage is 100%, with the parameter 'tab_index' described as tab index (default active tab). The description adds no extra meaning beyond the schema, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'ページのHTML全体を取得する' (Get the entire HTML of the page) uses a specific verb and resource, clearly stating the tool retrieves full page HTML. This distinguishes it from sibling tools like arc_get_page_content (likely text) and arc_get_page_links (links only).
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 arc_get_page_content or arc_get_page_forms. The description does not mention exclusions or context, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ページの詳細情報を取得する（URL、タイトル、ビューポート、UserAgent）
| Name | Required | Description | Default |
|---|---|---|---|
| tab_index | No | タブのインデックス（指定しない場合はアクティブタブ） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It omits whether the operation is read-only, what permissions are needed, or any side effects. However, the name and listed return fields imply a safe read operation, so it is minimally adequate.
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, conveying the purpose and return fields in two short sentences. No unnecessary words, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema), the description covers the main return fields. However, it may not list all possible fields returned, slightly reducing 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%; the parameter is described in the schema. The tool description adds no additional meaning or context beyond the schema, meeting the baseline but not exceeding it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets detailed page information and lists the specific fields (URL, title, viewport, UserAgent). This distinguishes it from other get_* siblings like get_page_content or get_active_tab by specifying exactly what metadata is retrieved.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any conditions, prerequisites, or exclusions, leaving the agent without context for selection among many similar get_* tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ローカルストレージ/セッションストレージの情報を取得する
| Name | Required | Description | Default |
|---|---|---|---|
| tab_index | No | タブのインデックス（指定しない場合はアクティブタブ） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states 'get information' but does not specify what information is returned (keys, values, sizes, etc.), nor does it disclose any side effects, permissions, or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence is concise and clear. However, it lacks structural elements like front-loading key points. Still, it is efficient with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations. The description does not explain what the returned information contains, leaving the agent with limited understanding of the tool's output. For a simple tool, this is a notable gap.
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 the single parameter with a description of tab index and default behavior. The tool description adds no further meaning beyond the schema, so baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool gets information about local storage and session storage, using a specific verb and resource. It distinguishes from sibling tool arc_get_storage_item which retrieves a specific storage item.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description does not explicitly contrast with siblings like arc_get_storage_item or arc_clear_storage. Context from sibling list suggests differentiation, but the description itself provides no when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ブラウザ履歴を戻る
| Name | Required | Description | Default |
|---|---|---|---|
| tab_index | No | タブのインデックス（指定しない場合はアクティブタブ） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden for behavioral disclosure. It only states the action, not what tab is affected (though input schema clarifies tab_index) or what happens if there is no previous history. No disclosure of required permissions or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one phrase) and is concise for a simple tool. However, it lacks structural elements like sentences that could improve readability. It gets a 4 for being to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter and no output schema, the description is minimal. It does not explain what tab the action applies to (though parameter implies default active tab) or the behavior when history is empty. The description is insufficient for an agent to fully understand the tool's behavior without relying on prior knowledge.
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 already provides 100% description coverage for the single parameter (tab_index). The tool description adds no additional information about parameters beyond what the schema offers, 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 means 'go back in browser history', specifying the action (go back) and the resource (browser history). It distinguishes from sibling 'arc_go_forward' which does the opposite.
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 explicit guidance on when to use this tool versus alternatives like arc_go_forward. Usage is implied by the name and description, but no when-to-use or when-not-to-use context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ブラウザのダイアログ（alert, confirm, prompt）を処理する
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ダイアログを承認するか却下するか | |
| prompt_text | No | promptダイアログに入力するテキスト（任意） | |
| tab_index | No | タブのインデックス（指定しない場合はアクティブタブ） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says 'process' without detailing outcomes of accept/dismiss, waiting behavior, or error conditions when no dialog exists. This is insufficient for an interactive 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, front-loaded with key information. No unnecessary words, every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description lacks essential context: it does not mention that a dialog must be present, that the tool waits, or possible failures. The tool's interactive nature demands more detail.
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 the baseline is 3. The description adds no extra meaning beyond the schema; it does not explain how prompt_text relates to action or the role of tab_index.
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 specifies a clear verb and resource: 'process browser dialogs (alert, confirm, prompt)'. It explicitly states the dialog types, distinguishing itself from sibling tools that handle other browser 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?
The description implies usage for handling JavaScript dialogs but provides no explicit guidance on when to use this tool versus alternatives like arc_fill or arc_click. No contexts or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
指定したセレクタの要素にホバーする
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | CSSセレクタ | |
| tab_index | No | タブのインデックス（指定しない場合はアクティブタブ） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description merely says 'hover' without disclosing behavioral details such as whether it triggers events, waits for animations, or requires the element to be visible. No annotations are provided to compensate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, but it is somewhat terse. It could be slightly more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple hover action with only two parameters and no output schema, the description is minimally adequate but could mention typical behavior like triggering CSS :hover or emitting events.
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%, and the description does not add additional meaning beyond the parameter descriptions already provided 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 'Hover over the element of the specified selector' clearly states the action (hover) and the target (element by CSS selector), distinguishing it from sibling tools like arc_click or arc_drag.
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 hover versus alternatives like click or drag. The description does not mention prerequisites or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
すべての開いているタブを一覧表示する
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the function. It does not disclose any behavioral details such as output format, side effects, or permissions needed. The description adds little beyond the tool name.
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 front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description would benefit from specifying what information is returned (e.g., tab titles, URLs). However, for a simple list tool, it is minimally adequate. Could be more complete to match the complexity of sibling 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?
The input schema has no parameters, so the description cannot add parameter meaning beyond what the schema provides. Baseline is 4 as per guidelines.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'すべての開いているタブを一覧表示する' (List all open tabs) clearly specifies the verb (list) and resource (tabs), distinguishing it from sibling tools that perform actions like clicking or closing tabs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use or when not to use this tool. While it's straightforward, there is no mention of alternatives or context for using this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Arc Browser で URL を開く
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | 開く URL | |
| new_tab | No | 新しいタブで開くかどうか（デフォルト: true） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only says 'open URL', without mentioning that it navigates to the URL, whether it loads the page, or any side effects. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, but it lacks structure or front-loading of key information. It is appropriately short for a simple tool, but could be improved by including a brief usage hint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description should provide more context about the tool's behavior. It fails to explain the effect of the new_tab parameter or the outcome of opening a URL, making it incomplete for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents parameters. The description adds no additional meaning beyond the schema, resulting in a baseline score 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 'Arc Browser で URL を開く' (Open URL in Arc Browser) clearly states the verb and resource, and is distinct from sibling tools like arc_click or arc_fill. However, it does not explicitly differentiate when to use this tool versus similar navigation tools like arc_switch_tab, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not specify when to use this tool, when not to, or suggest alternatives. It simply states the action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
キーまたはキーの組み合わせを押す
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | キーまたは組み合わせ（例: "Enter", "Control+A", "Escape"） | |
| selector | No | フォーカスする要素のCSSセレクタ（省略時はアクティブな要素） | |
| tab_index | No | タブのインデックス（指定しない場合はアクティブタブ） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is minimal and does not disclose any behavioral traits beyond the basic action. With no annotations, it is adequate for a simple key press but lacks details about side effects, waiting, 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 short sentence in Japanese, which is concise and contains no extraneous information. However, it could be more informative while remaining 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?
For a tool with 3 parameters and no output schema, the description lacks context such as what happens on invalid keys, whether it waits for page readiness, or how it interacts with the focused element. It is incomplete for reliable 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?
The input schema already has complete descriptions for all three parameters (key, selector, tab_index). The description adds no additional meaning beyond what the schema provides, so baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (press) and the resource (key or key combination). It is specific about what the tool does, but does not differentiate it from sibling tools like arc_click or arc_hover that perform other input 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?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of context, prerequisites, or conditions for pressing keys, nor any comparison with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
タブをリロードする
| Name | Required | Description | Default |
|---|---|---|---|
| tab_index | No | タブのインデックス（指定しない場合はアクティブタブ） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears full responsibility for behavioral disclosure. It only states the action without describing side effects (e.g., cache behavior, form resubmission) or confirmation dialogs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that concisely conveys the core function. Every word is necessary; there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple action with one optional parameter and no output schema, the description is adequately complete. It covers the primary use case without missing critical details, though it could mention reload behavior (e.g., from cache vs server).
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 the parameter 'tab_index' is already described in the input schema. The description adds no additional meaning beyond the schema's default behavior note.
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 (reload) and resource (tab) with a specific verb. It distinguishes from siblings like arc_switch_tab or arc_close_tab, though it does not explicitly contrast them.
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 lacks context on prerequisites, typical scenarios, or exclusions, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
コンソールログのキャプチャを開始する
| Name | Required | Description | Default |
|---|---|---|---|
| levels | No | キャプチャするログレベル（デフォルト: すべて） | |
| tab_index | No | タブのインデックス（指定しない場合はアクティブタブ） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It doesn't disclose side effects like clearing previous logs, performance impact, or whether capture is per-tab or global.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise single sentence, front-loaded with key action. No unnecessary words, but lacks structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Minimal context: doesn't explain capture lifecycle, how to retrieve logs, or relation to sibling tools (e.g., arc_stop_console_capture).
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 already explained. Description adds no extra 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?
The description 'Start console log capture' clearly states the action and resource. It distinguishes from siblings like arc_get_console_logs and arc_stop_console_capture, but could be more specific about what 'capture' entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like arc_get_console_logs. No prerequisites or conditions for use are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ネットワークリクエストの監視を開始する（fetch/XHR）
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | URLフィルタ（部分一致） | |
| tab_index | No | タブのインデックス（指定しない場合はアクティブタブ） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description lacks any behavioral details such as side effects, security implications, or how monitoring data is accessed. Only states the action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise and front-loaded. However, it could include more 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?
No output schema, and the description fails to mention how to stop monitoring (sibling exists) or how to retrieve captured requests. Incomplete for a tool that initiates a process.
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 100% of parameters with descriptions; the tool description adds no additional meaning beyond the schema. 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?
Description clearly states the tool starts monitoring network requests, specifically fetch/XHR, using a specific verb and resource. It differentiates from sibling 'arc_stop_network_monitor'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., arc_get_network_requests). No context on prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
コンソールキャプチャを停止してログをクリアする
| Name | Required | Description | Default |
|---|---|---|---|
| tab_index | No | タブのインデックス（指定しない場合はアクティブタブ） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It states that the tool stops capture and clears logs, which is transparent about the destructive action. However, it does not clarify side effects like whether logs are permanently lost or if the tool fails when no capture is active.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence front-loading the key action and effect. Every word serves a purpose; no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (one optional parameter, no output schema), the description covers the core behavior but lacks usage context and behavioral caveats. It would benefit from indicating prerequisites or typical workflow (e.g., paired with arc_start_console_capture).
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% as the single parameter has a descriptive label in the schema. The description adds no additional meaning beyond stating 'tab_index (optional)'. Thus, 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?
Description clearly states 'Stop console capture and clear logs' – a specific verb and resource. It distinguishes from the sibling arc_start_console_capture and implies a complementary role. However, it does not explicitly differentiate from related tools like arc_get_console_logs or arc_clear_storage, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, such as when capture should be stopped or under what conditions logs are cleared. The description does not mention prerequisites (e.g., need an active capture) or provide context for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ネットワーク監視を停止する
| Name | Required | Description | Default |
|---|---|---|---|
| tab_index | No | タブのインデックス（指定しない場合はアクティブタブ） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description lacks details on what stopping entails (e.g., does it clear captured data? what happens to ongoing requests?). The agent receives minimal behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence is concise and front-loaded, but it may be too brief for the agent to fully understand the tool's operation.
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 the description lacks context such as prerequisites (e.g., must have started a monitor), effects, or state changes. Without annotations or output schema, completeness is insufficient.
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 the parameter 'tab_index' is already described. The description adds no additional meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('stop') and the resource ('network monitoring'), and it distinguishes from sibling tools like arc_start_network_monitor.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, such as the need to have started monitoring first, or how it relates to other network tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
指定したタブに切り替える
| Name | Required | Description | Default |
|---|---|---|---|
| tab_index | No | タブのインデックス（1から始まる） | |
| url | No | 切り替えるタブのURL（部分一致） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose behavioral details like what happens if the tab does not exist, whether it fails silently, or if it requires the tab to be in the same space. The tool's simplicity reduces risk, but more context would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the core action. It is concise but could be expanded to include usage notes 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 tool's simplicity (two optional parameters, no output schema), the description is minimally adequate. However, it lacks contextual notes on behavior (e.g., priority between tab_index and url) and typical use cases.
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 each parameter (tab_index and url). The tool description adds no extra meaning beyond the schema. Baseline of 3 is appropriate as the schema already documents parameter purpose 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?
Description clearly states the tool's action: switching to a specified tab. The Japanese phrase '指定したタブに切り替える' directly conveys the purpose. It distinguishes from sibling tools like arc_list_tabs (listing) or arc_get_active_tab (retrieving info).
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 such as arc_search_tabs, arc_focus_space, or arc_get_active_tab. The agent is left to infer when to use a tab index vs URL.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
スクリーンショットを取得する。mode="selection"で範囲選択、mode="window"でウィンドウ選択
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | キャプチャモード: selection（ユーザーが範囲をドラッグ選択）、window（ユーザーがウィンドウをクリック選択） | selection |
| save_path | No | 保存先パス（省略時は自動命名: screenshot_{mode}_{timestamp}.png） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions taking a screenshot but does not disclose that the modes require user input (dragging region or clicking a window), nor does it explain what the tool returns (e.g., saved file path or raw data). This omission limits an AI agent's ability to anticipate the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a single sentence that efficiently conveys the core purpose and mode differentiation. It is front-loaded and contains no unnecessary words, making it easy for an AI agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has only two parameters, no output schema, and requires user interaction (due to the modes), the description is incomplete. It fails to mention that the tool will prompt the user for input, what the output will be (e.g., saved file), or any side effects like taking focus. This leaves the agent with an incomplete understanding of the tool's full workflow.
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 minimal value beyond the schema: it restates the mode options and their meanings. While helpful for quick understanding, it does not provide additional semantic context such as default behavior or example values for save_path.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: taking a screenshot. It explicitly distinguishes between the two modes ('selection' for range selection, 'window' for window selection), which sets it apart from sibling tools that deal with page content or other 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?
The description does not provide guidance on when to use this tool versus alternatives like arc_get_page_content or arc_get_page_images. It also does not mention prerequisites, such as the need for user interaction (clicking or dragging) or that it might block until the user completes the capture.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ファイルアップロード用のinputにファイルパスを設定する
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | ファイルinputのCSSセレクタ | |
| file_path | Yes | アップロードするファイルのローカルパス | |
| tab_index | No | タブのインデックス（指定しない場合はアクティブタブ） |
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 setting the file path triggers an upload, requires special permissions, or has side effects. The tool's behavior remains opaque.
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 efficiently conveys the core purpose. However, it could include more detail without becoming verbose, so it is not a perfect 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 lack of an output schema and the presence of three parameters, the description is too brief. It does not explain what happens after setting the file path (e.g., upload initiation, error handling), leaving 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 input schema has 100% parameter description coverage, so the description does not need to add parameter details. It adds no additional meaning beyond the schema, meeting 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 that the tool sets a file path for a file upload input, specifying the verb 'set' and the resource 'file upload input'. While it does not explicitly contrast with siblings like 'arc_fill', the unique focus on file uploads provides sufficient differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites like file existence or element type. There is no context for usage or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
指定したテキストまたはセレクタがページに表示されるまで待機する
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | 待機するテキスト（部分一致） | |
| selector | No | 待機する要素のCSSセレクタ | |
| timeout | No | タイムアウト（ミリ秒、デフォルト: 30000） | |
| tab_index | No | タブのインデックス（指定しない場合はアクティブタブ） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It only says 'wait until displayed' but lacks details on timeout behavior, return value, blocking nature, or what happens if both text and selector are specified.
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 that conveys the core functionality without extraneous words. Efficient and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Missing key context: no return value specification, no error behavior (e.g., timeout error), no indication of when to use vs siblings. Even without output schema, a wait tool should mention what happens on success/failure.
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 parameters with descriptions. The description restates 'text or selector' but adds no new meaning (e.g., relationship between text and selector, expected format of timeout). Baseline is 3 due to 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool waits for text or selector to appear on the page. It uses a specific verb ('wait') and resource ('page element/text'), but does not differentiate from sibling tools like arc_watch_element.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., arc_watch_element, arc_get_page_content). No mention of prerequisites or scenarios where it is appropriate.
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.0arc_clickarc_close_tabarc_dragarc_execute_javascriptarc_fillarc_fill_formarc_get_console_logsarc_get_cookiesarc_get_meta_tagsarc_get_network_requestsarc_get_page_contentarc_get_page_formsarc_get_page_htmlarc_get_page_infoarc_get_storage_infoarc_go_backarc_handle_dialogarc_hoverarc_list_tabsarc_open_urlarc_press_keyarc_reload_tabarc_start_console_capturearc_start_network_monitorarc_stop_console_capturearc_stop_network_monitorarc_switch_tabarc_take_screenshotarc_upload_filearc_wait_forScored across 30 tools
All 30 tools have clearly distinct purposes, covering separate actions like navigation, interaction, data extraction, and monitoring. Even similar tools like arc_get_page_content and arc_get_page_html are differentiated by returning text vs. HTML.
Every tool follows the consistent pattern 'arc_<verb>_<noun>' in snake_case, with no mixing of conventions. This makes the tool set predictable and easy to navigate.
30 tools is on the higher end, but each tool covers a specific need in browser automation, making the set well-scoped for its domain. Slightly over typical but justified.
The tool set covers all major browser automation operations: navigation, tab management, element interaction, data extraction, console/network monitoring, and screenshots. No obvious gaps for a general-purpose browser control server.
Live browser debugging for AI assistants — DOM, console, network via MCP.
An MCP server for Arcjet - the runtime security platform that ships with your AI code.
MCP server for Mint — AI-powered QA that runs your app in a real browser on every PR.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
