How do I use ie-mode-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ie-mode-mcp open the legacy sales report at http://legacy01.local/reports and show me today's total" 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.

de en es ja ko ru zh

ie-mode-mcp

by sumikof

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Local

ie-mode-mcp

MCP Server for operating legacy web applications running in Microsoft Edge's IE mode from AI agents via MCP (Model Context Protocol).

AI Agent ──(MCP / stdio)──> ie-mode-mcp ──> BrowserManager ──> selenium-webdriver
                                                                     │
                                                          IEDriverServer.exe
                                                                     │
                                                     Microsoft Edge (IE Mode)
                                                                     │
                                                       Legacy Web Application

Configured only with Node.js 22 / TypeScript / selenium-webdriver (no HTTP Server, DB, DI, Logging Framework)
MCP Transport is stdio only
Browser session is only one, WebDriver operations are fully sequential
Does not return full HTML, inspect_page returns summarized screen information for LLM
No approval flow. Operations are executed when the Tool is called.

Related MCP server: Selenium MCP Server

1. Quick Start

Run the following on Windows.

git clone https://github.com/sumikof/iedriver-mcp.git
cd iedriver-mcp
npm install
npm run build

# IEDriverServer.exe のパスと、遷移を許可する Origin を指定して起動
$env:IE_MCP_DRIVER_PATH = "C:\tools\IEDriverServer.exe"
$env:IE_MCP_ALLOWED_ORIGINS = "http://legacy01.local"
node dist/index.js

If {"level":"info","event":"started","transport":"stdio"} is output to stderr, startup is successful. Normally, do not start manually; let it auto-start from the AI Agent's MCP settings.

2. Prerequisites

Item	Description
OS	Windows 11 / Windows 10 (logged-in interactive session)
Node.js	22 or higher
Browser	Microsoft Edge (IE mode must be available)
Driver	IEDriverServer.exe (Selenium 4.x series. 32-bit version recommended)

Download IEDriverServer.exe from the Selenium download page and place it in any folder (e.g., C:\tools\). Since the 64-bit version has known limitations, Selenium officially recommends using the 32-bit version.
IEDriver is affected by GUI, window focus, and native events, so use in a dedicated Windows VM or dedicated Windows session is recommended.
Configuration to run the browser on a Windows Service (Session 0) is not assumed.
MCP Server and IEDriver / Edge run in the same Windows environment.

3. Windows Pre-configuration

IEDriver is strongly affected by environment settings. Complete the manual configuration first before starting the MCP Server.

3.1 Enable Edge IE Mode

First, manually verify with Edge that the target site can be opened in IE mode. IE mode is enabled via one of the following policies (under Software\Policies\Microsoft\Edge).

Policy (Display Name)	Registry Value Name
Configure Internet Explorer integration	`InternetExplorerIntegrationLevel`
Configure the Enterprise Mode Site List	`InternetExplorerIntegrationSiteList`
Send all intranet sites to Internet Explorer	(Configured via Group Policy for Edge 77 and later)

Specific configuration depends on organizational policy, so check with the Microsoft IE mode documentation and your organization's administrator. Apply the latest updates to Windows / Edge.

3.2 IEDriver Required Settings

Item	Required State	Handling in this Server
Browser zoom	100%	Not required because `ignoreZoomSetting(true)` is set, but 100% recommended
Protected Mode	Same setting for all zones	If not unified, an exception occurs at startup. Unify via Internet Options → Security
IEDriverServer bitness	32-bit recommended	—

If the Protected Mode settings are not unified, browser_start will fail. IEDriver's introduceFlakinessByIgnoringProtectedModeSettings is not used because it makes behavior unstable.

4. Installation and Build

npm install     # 依存パッケージの取得
npm run build   # TypeScript を dist/ へビルド

The output is dist/index.js. After building, it can also be started with npm start (= node dist/index.js).

5. Environment Variables

Configuration files (YAML/JSON) are not used; settings are configured only via environment variables.

Environment Variable	Description	Default Value
`IE_MCP_EDGE_PATH`	Path to msedge.exe	Not specified (IEDriver auto-detects)
`IE_MCP_DRIVER_PATH`	Path to IEDriverServer.exe	Not specified (searched from `PATH`)
`IE_MCP_ALLOWED_ORIGINS`	Comma-separated origins allowed for `navigate`. `*` for unlimited	`*`
`IE_MCP_TIMEOUT_MS`	Default timeout for element search and waiting (ms)	`10000`

IE_MCP_EDGE_PATH=C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe
IE_MCP_DRIVER_PATH=C:\tools\IEDriverServer.exe
IE_MCP_ALLOWED_ORIGINS=http://legacy01.local,http://legacy02.local
IE_MCP_TIMEOUT_MS=10000

IE Driver 4.5.0 and later automatically detects Edge in environments without IE (Windows 11 default), so IE_MCP_EDGE_PATH is usually unnecessary. Only specify explicitly when auto-detection fails.
To prioritize operational reproducibility, it is recommended to explicitly specify IE_MCP_DRIVER_PATH.
IE_MCP_ALLOWED_ORIGINS is a simple restriction to prevent accidental operations, and is determined by exact match of Origin (scheme + host + port). Path-based restrictions are not performed.

6. Startup Methods

Manual Startup (for verification)

PowerShell:

$env:IE_MCP_DRIVER_PATH = "C:\tools\IEDriverServer.exe"
$env:IE_MCP_ALLOWED_ORIGINS = "http://legacy01.local"
node dist/index.js

Command Prompt:

set IE_MCP_DRIVER_PATH=C:\tools\IEDriverServer.exe
set IE_MCP_ALLOWED_ORIGINS=http://legacy01.local
node dist\index.js

Listens for connections from the client via stdio. Since standard input/output is used for the MCP protocol, there is no response to keyboard input in this state (normal). All logs are output to stderr. Exit with Ctrl+C (browser also closes automatically).

Note: Starting the MCP Server alone does not start the browser. The browser starts when the Agent calls browser_start.

Normal Operation

The AI Agent (MCP client) starts this Server as a child process. Manual startup is not required. Configure as described in the next chapter.

7. Registration with AI Agent

Add the following to the MCP client's configuration file.

{
  "mcpServers": {
    "ie-mode": {
      "command": "node",
      "args": ["C:\\ie-mode-mcp\\dist\\index.js"],
      "env": {
        "IE_MCP_DRIVER_PATH": "C:\\tools\\IEDriverServer.exe",
        "IE_MCP_EDGE_PATH": "C:\\Program Files (x86)\\Microsoft\\Edge\\Application\\msedge.exe",
        "IE_MCP_ALLOWED_ORIGINS": "http://legacy01.local,http://legacy02.local",
        "IE_MCP_TIMEOUT_MS": "10000"
      }
    }
  }
}

Escape backslashes in paths within JSON (C:\\...).
Specify the absolute path of the built dist/index.js in args.
For Claude Code, it can also be registered with claude mcp add.

claude mcp add ie-mode --env IE_MCP_DRIVER_PATH=C:\tools\IEDriverServer.exe --env IE_MCP_ALLOWED_ORIGINS=http://legacy01.local -- node C:\ie-mode-mcp\dist\index.js

After registration, if the client shows 10 Tools including browser_start, the connection is successful.

8. Tool Reference

There are 10 Tools exposed. Low-level WebDriver APIs (such as findElement / executeScript) are not exposed.

Tool	Input	Overview
`browser_start`	None	Start Edge IE Mode. If already started, reuse existing session
`browser_close`	None	Close the browser. No error even if called multiple times
`navigate`	`url`	Navigate after checking URL Allowlist
`inspect_page`	`frame?`	Return URL / title / screen text / operable elements
`click`	`selector`, `frame?`	Wait for visible and enabled, then click
`type`	`selector`, `frame?`, `text`, `clear?`	Input into input / textarea
`select`	`selector`, `frame?`, `by`, `value`	Select an option from `<select>`
`wait_for`	`type`, `selector?`, `frame?`, `text?`, `timeoutMs?`	Wait until condition is met
`switch_window`	`target:"newest"` / `index`, `timeoutMs?`	Switch to popup or another window
`screenshot`	None	Return current screen as PNG (MCP image content)

Common: Selector

{ "by": "id | name | css | xpath | linkText", "value": "searchButton" }

Legacy web applications frequently use name and xpath, so they are supported.

Common: frame (iframe is one level)

All element operation Tools accept an optional frame. When specified, they switch back to defaultContent and then to the frame, and search for elements within it.

{
  "frame": { "by": "name", "value": "mainFrame" },
  "selector": { "by": "id", "value": "searchButton" }
}

`browser_start`

{}

{ "status": "ready", "reused": false }

reused: true indicates that the existing session was used as-is. If the existing session is dead, it automatically restarts.

`navigate`

{ "url": "http://legacy01.local/customer" }

{ "url": "http://legacy01.local/customer", "title": "顧客検索" }

`inspect_page`

Main Tool for the Agent to understand the screen. Does not return full HTML, only returns URL / title / displayed text / operable elements (a button input textarea select iframe). Hidden elements and type="hidden" inputs are excluded.

{ "frame": { "by": "name", "value": "mainFrame" } }

{
  "url": "http://legacy01.local/customer",
  "title": "顧客検索",
  "text": "顧客検索 顧客名 支店 検索",
  "elements": [
    { "tag": "input", "id": "customerName", "name": "customerName", "type": "text" },
    { "tag": "select", "id": "branch", "name": "branch", "text": "東京支店", "optionCount": 12 },
    { "tag": "button", "id": "searchButton", "text": "検索" },
    { "tag": "iframe", "name": "mainFrame" }
  ],
  "truncated": false
}

truncated: true indicates that elements were truncated at the upper limit (300 items).
If the element list includes iframe, call again with frame specified to see its contents.

`click`

{ "selector": { "by": "id", "value": "searchButton" } }

{ "url": "http://legacy01.local/customer", "title": "顧客検索" }

Waits until visible and enabled, then clicks. click does not automatically retry (to prevent duplicate processing from re-clicking when registration/update/submission has already succeeded).

`type`

{
  "selector": { "by": "id", "value": "customerName" },
  "text": "山田太郎",
  "clear": true
}

If clear (default true) is true, inputs after clear(); if false, appends.

`select`

{
  "selector": { "by": "id", "value": "branch" },
  "by": "text",
  "value": "東京支店"
}

{ "text": "東京支店", "value": "13", "index": 2 }

by is one of text / value / index (index is 0-based).

`wait_for`

Does not use fixed sleep, waits explicitly.

{
  "type": "visible",
  "selector": { "by": "id", "value": "resultTable" },
  "timeoutMs": 10000
}

`type`	Required Input	Condition
`present`	`selector`	Element exists in DOM
`visible`	`selector`	Element is visible
`enabled`	`selector`	Element is visible and operable
`text`	`selector`, `text`	Element's text contains `text`
`url`	`text`	Current URL contains `text`
`title`	`text`	Title contains `text`

When timeoutMs is omitted, IE_MCP_TIMEOUT_MS is used.

`switch_window`

{ "target": "newest" }

{ "index": 1 }

{ "url": "http://legacy01.local/detail", "title": "顧客詳細", "index": 1, "windowCount": 2 }

newest polls briefly until a new window handle appears. If not detected, switches to the last existing window.

`screenshot`

{}

Returns a PNG image (MCP image content). Used to check layout/error screens that cannot be determined from DOM alone.

9. Usage Examples

Basic Loop

browser_start → navigate → inspect_page → click / type / select → wait_for → inspect_page

Repeat: inspect_page to understand the screen → operate → wait_for to wait for result → inspect_page again.

Example: Search for customer "Yamada Taro" and open detail screen

#	Tool	Arguments
1	`browser_start`	`{}`
2	`navigate`	`{ "url": "http://legacy01.local/customer" }`
3	`inspect_page`	`{}`
4	`type`	`{ "selector": { "by": "id", "value": "customerName" }, "text": "山田太郎" }`
5	`select`	`{ "selector": { "by": "id", "value": "branch" }, "by": "text", "value": "東京支店" }`
6	`click`	`{ "selector": { "by": "id", "value": "searchButton" } }`
7	`wait_for`	`{ "type": "visible", "selector": { "by": "id", "value": "resultTable" } }`
8	`inspect_page`	`{}`
9	`click`	`{ "selector": { "by": "linkText", "value": "山田太郎" } }`
10	`wait_for`	`{ "type": "title", "text": "顧客詳細" }`
11	`inspect_page`	`{}`

Example: Operate inside an iframe

{"tool": "inspect_page", "args": {}}
{"tool": "inspect_page", "args": { "frame": { "by": "name", "value": "mainFrame" } }}
{"tool": "click", "args": {
  "frame": { "by": "name", "value": "mainFrame" },
  "selector": { "by": "id", "value": "searchButton" }
}}

Specify the frame each time for each operation (because internally it resets to defaultContent and switches each time, state is not carried over).

{"tool": "click",         "args": { "selector": { "by": "id", "value": "openPopup" } }}
{"tool": "switch_window", "args": { "target": "newest" }}
{"tool": "inspect_page",  "args": {}}
{"tool": "switch_window", "args": { "index": 0 }}

10. Errors and Troubleshooting

Errors are returned with the following code instead of Selenium's stack trace (isError: true).

{
  "error": "ELEMENT_NOT_FOUND",
  "message": "Element was not found: id=searchButton",
  "selector": { "by": "id", "value": "searchButton" }
}

Error Code	Meaning	Countermeasure
`BROWSER_NOT_STARTED`	Browser not started	Call `browser_start`
`ELEMENT_NOT_FOUND`	Element/frame not found	Check actual elements with `inspect_page` and review Selector
`TIMEOUT`	Condition for `wait_for` not met	Review condition and `timeoutMs`. Screen may differ from expected.
`WINDOW_NOT_FOUND`	Specified window does not exist	Review `switch_window`'s `index`
`NAVIGATION_FAILED`	Navigation failed	Check URL, network, authentication
`DRIVER_LOST`	IEDriver/Edge terminated abnormally	Restart with `browser_start` (see below)
`URL_NOT_ALLOWED`	Origin outside Allowlist	Review `IE_MCP_ALLOWED_ORIGINS`
`INVALID_ARGUMENT`	Invalid argument	Check Tool input specification
`INTERNAL_ERROR`	Other (including startup failure)	Check `message` and stderr logs

Recovery from `DRIVER_LOST`

If the browser or Driver crashes, the internal WebDriver is discarded and subsequent operations will result in BROWSER_NOT_STARTED. Automatic recovery and automatic re-execution of the last operation are not performed (to prevent side effects such as duplicate registration). The Agent should call browser_start again, check the screen state with inspect_page, and then resume operations. Since the previous operation may have already succeeded, do not re-execute registration/update operations as-is.

11. Logging

Since stdout is used by the MCP protocol, all logs are output to stderr as single-line JSON.

{"level":"info","event":"started","transport":"stdio"}
{"level":"info","tool":"navigate","url":"http://legacy01.local/customer","durationMs":842}
{"level":"info","tool":"type","selector":{"by":"id","value":"password"},"textLength":16,"durationMs":128}
{"level":"error","tool":"click","selector":{"by":"id","value":"x"},"error":"ELEMENT_NOT_FOUND","message":"Element was not found: id=x","durationMs":5012}

The input string itself, cookies, authentication information, and full HTML are not recorded (type only records character count). To save to a file, redirect stderr.

node dist/index.js 2>> C:\logs\ie-mode-mcp.log

12. Troubleshooting

Symptom	What to check
`browser_start` becomes `INTERNAL_ERROR`	Is `IE_MCP_DRIVER_PATH` correct? Can IEDriverServer.exe be started alone?
Protected mode related exceptions occur	Internet Options → Security: unify protected mode settings for all zones
Zoom related exceptions occur	Reset Edge / IE zoom to 100%
Edge starts but does not enter IE mode	Check IE mode policies (site list, etc.). First verify manually that IE mode can be displayed
Operations freeze / cannot click elements	Is the window minimized or inactive? Becomes unstable when Remote Desktop is disconnected
`inspect_page` elements are empty	Is it a screen inside a frame? (Re-acquire by specifying `frame`). Check the actual screen with `screenshot`
Tool not visible on Agent side	Is `dist/index.js` specified with an absolute path? Has `npm run build` been executed?
Nothing appears in standard output	Normal. Logs are output to stderr

screenshot is effective for investigating causes. It allows you to check states that cannot be determined from DOM information alone (modals, authentication dialogs, rendering issues).

13. Development

src/
├─ index.ts      MCP Server のエントリーポイント（stdio）
├─ config.ts     環境変数と stderr ログ
├─ tools.ts      MCP Tool の Schema と Handler
├─ browser.ts    BrowserManager（Selenium / IEDriver 操作の集約）
├─ selectors.ts  Selector → Selenium の By 変換
└─ errors.ts     Selenium Error → MCP Error Code 変換

npm run build   # tsc でビルド
npm start       # node dist/index.js

MCP Tool does not directly touch Selenium; it always goes through BrowserManager.
All WebDriver operations are serialized via a Promise Chain, so even if Tools are called in parallel, only one request at a time is sent to IEDriver.
Only operations without side effects (element search, Window Handle detection) are retried. click and submissions are not retried.

14. Limitations

The initial implementation does not support the following:

Multiple browser sessions / Multiple users / HTTP Transport / REST API / DB / Session persistence / Automatic browser recovery / Complex Retry Policy / WebDriver Grid / General-purpose Selenium API / executeScript Tool / Multi-level iframes (only one level) / Element Cache / Metrics / Approval flow / Authentication and authorization

Available Tools

10 tools

browser_closeClose browserB

Close the browser session. Safe to call repeatedly.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are available so the description carries the full burden. It only says 'close the browser session' and 'safe to call repeatedly', but does not disclose whether this terminates all browser state or if there are side effects on open windows, tabs, or downloads. The behavioral context is thin.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences that are front-loaded and to the point. Every sentence adds value: the first states the action, the second clarifies safety/repeatability. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters and no output schema, the description covers the basic purpose and safety. However, it lacks details on what happens after closing (e.g., can browser_start reopen cleanly) or any cleanup behavior, which might be useful context for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters and schema coverage is 100%. The description adds value by stating it is safe to call repeatedly, which implies no parameters are needed and calls are idempotent. With no parameters to explain, this is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool closes the browser session with a specific verb and resource. It distinguishes enough from siblings like 'navigate' which moves within a session.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description notes it is safe to call repeatedly, which implies idempotency, but does not explicitly tell when to call it (e.g., end of a browsing task) or when not to (e.g., still need to interact). No sibling differentiation is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

browser_startStart Edge IE ModeA

Start Microsoft Edge in IE Mode through IEDriverServer. Only one browser session exists; calling this while a session is running returns the existing one. Also use this to recover after a DRIVER_LOST error.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description must carry the full burden of behavioral disclosure. It transparently reveals that only one browser session exists, that calling the tool again returns the existing session, and that it can be used for recovery. This is strong for a start tool, but it could additionally mention potential side effects like timeouts or prerequisites for the IEDriverServer.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long, front-loading the primary purpose in the first sentence and adding behavioral nuance in the second. Every sentence provides essential information without redundancy or fluff, achieving maximum conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (no parameters, no output schema, straightforward start action), the description is complete. It covers the core function, the singleton behavior, error recovery, and is sufficient for an AI agent to understand when and how to invoke the tool alongside its sibling tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters and 100% schema coverage, so the baseline is 4. The description adds no parameter information, which is appropriate since there are none to document. No additional semantic value is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool starts Microsoft Edge in IE Mode via IEDriverServer, using the specific verb 'Start' and the resource 'Microsoft Edge in IE Mode'. It also distinguishes itself from sibling tools by noting that only one browser session exists and that calling it again returns the existing session, which is unique among the provided sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use the tool: normally to start the browser, and also to recover after a DRIVER_LOST error. It implicitly advises against calling it multiple times for new sessions by stating that subsequent calls return the existing session. However, it does not explicitly list alternatives or state when not to use it, though no alternative starting tool exists among the siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

clickClick elementA

Click an element after waiting for it to be visible and enabled. This operation is never retried automatically, because a repeated click may submit or register data twice.

ParametersJSON Schema

Name	Required	Description	Default
`frame`	No	Optional iframe/frame to switch into first. One level of nesting is supported.
`selector`	Yes

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It discloses two key behaviors: waiting for the element to be visible and enabled, and the lack of automatic retry with a rationale. However, it does not mention timeout behavior, scroll-into-view, or what happens if the element is not found.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the core purpose, and every sentence adds value. No fluff or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's potential side effects (e.g., triggering navigation or form submission), the description is minimal. It does not mention return values, scroll behavior, or failure modes. It is adequate for a simple click but lacks completeness for an AI agent to fully anticipate outcomes.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 50%, and the description adds no information about the parameters. It does not explain the 'frame' or 'selector' parameters beyond what is already in the schema. The description should compensate for the missing schema descriptions but fails to do so.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Click an element after waiting for it to be visible and enabled,' using a specific verb and resource. It distinguishes the tool from siblings like 'type' and 'select' by specifying the action and the precondition (visibility and enabled state).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly warns that the operation is never retried automatically because a repeated click may submit or register data twice. This gives a clear usage caution about retries, though it does not explicitly compare to alternative tools or state when not to use click.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

inspect_pageInspect pageA

Return the current URL, title, visible page text and the operable elements (a, button, input, textarea, select, iframe). The full HTML is never returned. Pass frame to inspect the contents of an iframe listed by a previous inspect_page call.

ParametersJSON Schema

Name	Required	Description	Default
`frame`	No	Optional iframe/frame to switch into first. One level of nesting is supported.

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden of disclosing behavior. It explicitly states 'The full HTML is never returned' and that frame must reference an iframe from a previous call. The read-only nature is implied by 'Return' but not stated outright, though this is likely sufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two succinct sentences that front-load the main purpose and then add the iframe caveat. Every sentence earns its place with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has one well-described parameter, no output schema, and no annotations. The description covers the output, a key constraint (no full HTML), and iframe usage, making it reasonably complete for an inspection tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

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 meaning beyond the schema by clarifying that the frame must come from a previous inspect_page call, which is not stated in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Return') and enumerates exactly what is returned (URL, title, visible text, operable elements). This clearly distinguishes it from sibling tools like 'click' or 'navigate'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool (to inspect page state) and gives specific guidance for iframe usage ('Pass frame to inspect the contents of an iframe listed by a previous inspect_page call'). It doesn't explicitly exclude alternatives, but the context is clear given the sibling list.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

navigateNavigateA

Navigate the browser to a URL. The origin must be permitted by IE_MCP_ALLOWED_ORIGINS.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes	Absolute URL to open.

TDQS

A3.7/5.0

Behavior2/5

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 discloses the origin permission requirement but fails to mention behavioral details like whether the browser must already be open, whether it waits for page load, or what happens on invalid URLs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is only two sentences, front-loaded with the core action in the first sentence, followed by the key constraint. Every word earns its place with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter and no output schema, the description covers the action and a key constraint but lacks context about prerequisites (e.g., browser must be started) and error behavior. It is adequate but not thorough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already describes the 'url' parameter as 'Absolute URL to open' (100% coverage). The description meaningfully adds that the URL's origin must match IE_MCP_ALLOWED_ORIGINS, which is a critical constraint not present in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Navigate') and resource ('the browser to a URL'), clearly distinguishing it from sibling tools like browser_start, browser_close, and click. The added constraint on allowed origins further clarifies scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides one condition for use (origin must be permitted by IE_MCP_ALLOWED_ORIGINS) but no guidance on when to choose this tool over alternatives (e.g., if origin is not allowed) or prerequisites like starting the browser first.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

screenshotScreenshotB

Capture the current browser window as a PNG image.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description bears the full burden. It states the action (capture) and format (PNG) but omits crucial details: whether it modifies state, if a browser window must be open, what exactly 'current browser window' captures (viewport vs full page), and if there are 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single 9-word sentence, efficient and front-loaded. However, it could include additional essential context (e.g., 'captures the visible viewport area') without losing conciseness, making it slightly under-specified.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters and no output schema, the description should clarify what the tool returns (e.g., base64 PNG data). It only says 'as a PNG image' but doesn't confirm the output type. The scope of 'current browser window' is ambiguous, and prerequisites are missing, leaving the agent uncertain.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are zero parameters, and the schema coverage is 100% (trivially). The description adds minimal meaning by specifying 'current browser window' as the implicit input. A baseline of 4 is appropriate given no parameters to document.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('capture') and resource ('current browser window') with a clear output format ('PNG image'). It is distinct from sibling tools like 'navigate' or 'inspect_page' which serve different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 screenshot versus alternatives. Despite having sibling tools (e.g., inspect_page, wait_for), no exclusions or context is given. An agent must infer use case from tool purpose alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

selectSelect optionB

Choose an option of an HTML element by visible text, value or index.

ParametersJSON Schema

Name	Required	Description
`by`	Yes	How to identify the option.
`frame`	No	Optional iframe/frame to switch into first. One level of nesting is supported.
`value`	Yes	Option text, value, or zero-based index.
`selector`	Yes

TDQS

B3.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It discloses that selection is based on visible text, value or index, which is helpful. However, it doesn't mention side effects (e.g., whether the change triggers JavaScript events), error handling (e.g., what if option not found), or scope (e.g., operates within current page context).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that efficiently communicates the core action and identification methods. It is front-loaded with the key verb and resource. No waste, though it could optionally add a brief usage hint without breaching conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 4 parameters with nested objects and no output schema, the description is somewhat complete but lacks coverage of return behavior (e.g., what happens on success/failure), frame handling nuances, and edge cases. For a selection action in a browser automation context, more behavioral detail would be helpful.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 75%, meaning most parameters are documented in the schema. The description adds that selection can be by 'visible text, value or index', which maps to the 'by' enum, and that the 'value' parameter can be text or zero-based index. This provides modest added meaning beyond the schema, but the 'frame' and 'selector' objects remain documented primarily in schema, not description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'choose' and resource 'HTML <select> element', specifying three identification methods (visible text, value, index). This distinguishes it from sibling tools like click or type, though it doesn't explicitly contrast with them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use by saying 'choose an option of an HTML <select> element', which suggests this is for dropdown selections. However, it does not provide explicit when-not-to-use guidance, mention prerequisites (e.g., element must exist), or compare with alternatives like click on an option directly.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

switch_windowSwitch windowA

Switch to another browser window or popup. Use target:"newest" after an action that opens a window, or index to select a window by its zero-based position.

ParametersJSON Schema

Name	Required	Description
`index`	No	Zero-based window index.
`target`	No	Switch to the newest window.
`timeoutMs`	No	How long to poll for a new window. Defaults to IE_MCP_TIMEOUT_MS.

TDQS

A3.8/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It mentions polling behavior via timeoutMs parameter but does not state if switching is destructive, if it requires a window to exist, what happens if the window is closed, or any state changes. The description does not disclose potential side effects or preconditions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short and front-loaded with the core purpose in the first sentence. The second sentence adds specific usage hints. It could potentially omit 'or popup' as redundant with 'window', but overall concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 3 unrequired parameters, no output schema, no annotations, the description covers the basic purpose and usage hints. However, it lacks details on return values, error scenarios (e.g., window not found), or behavior when switching to a window that fails to load.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description adds context for the 'target' parameter (use after action that opens window) and 'index' (zero-based position), but the timeoutMs parameter meaning is already clear from schema. No additional semantic value beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool switches to another browser window or popup, specifying the verb 'switch' and the resource 'browser window or popup'. It distinguishes itself from sibling tools like browser_start, browser_close, and navigate by focusing on window selection rather than creation, closure, or navigation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool: after an action that opens a window, use target 'newest', or use index to select by position. It implicitly distinguishes from sibling tools by indicating this is for window focus rather than content navigation or page interaction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

typeType textA

Type text into an input or textarea. Set clear to false to append instead of replacing.

ParametersJSON Schema

Name	Required	Description
`text`	Yes	Text to send to the element.
`clear`	No	Clear the field first. Default true.
`frame`	No	Optional iframe/frame to switch into first. One level of nesting is supported.
`selector`	Yes

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that the tool can clear or append text via the 'clear' parameter, which is good. However, it does not mention potential side effects (e.g., triggering change events), error conditions (element not found), or behavior when the element is not a text input. This is adequate but not comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise at one sentence plus one usage tip. Every word earns its place, clearly stating the action and a key parameter behavior. No filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description should ideally mention return values (e.g., success indicator, element state). It doesn't, leaving that unclear. With nested objects (selector, frame) and no explanation of selector strategies beyond the schema enums, it completes the basic usage but misses context on what happens after typing (e.g., waits for stability, triggers events).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is high at 75%, so the schema documents most parameters well. The description adds value by explaining the 'clear' boolean behavior (append vs replace) beyond the schema's default value note. It doesn't add to 'selector' or 'frame' parameters, which are already well-described in the schema, so this is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool types text into an input or textarea, using a specific verb and resource. It distinguishes from siblings like 'click' or 'select' by targeting text entry specifically, but doesn't differentiate from a potential 'send_keys' equivalent if one existed among siblings, so a slight deduction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a key usage guideline: set clear to false to append instead of replacing text. This gives basic advice on when to use a parameter. However, it lacks guidance on when to use this tool versus alternatives like clicking an element first or waiting, and doesn't mention prerequisites (e.g., element must be visible/interactable).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

wait_forWait for conditionA

Wait until a condition holds. present/visible/enabled/text require a selector; text/url/title require text, which is matched as a substring. Use this instead of sleeping after an action.

ParametersJSON Schema

Name	Required	Description
`text`	No	Expected substring for text/url/title conditions.
`type`	Yes	Condition to wait for.
`frame`	No	Optional iframe/frame to switch into first. One level of nesting is supported.
`selector`	No
`timeoutMs`	No	Timeout in milliseconds. Defaults to IE_MCP_TIMEOUT_MS.

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description explains key behavioral traits: that present/visible/enabled/text require a selector, text/url/title require text matched as substring, and that it waits for the condition. With no annotations provided, the description carries the full burden of transparency. It lacks details on timeout behavior or error handling, but covers core usage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with two sentences, front-loading the key purpose and condition types. Every sentence adds value, avoiding any redundancy. The structure is efficient for an AI agent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (5 parameters, nested objects, no output schema), the description is adequate. It explains the core waiting concept and parameter dependencies. However, it lacks details on return values or what happens on timeout/failure, which the schema alone doesn't cover. The sibling 'inspect_page' might share similar conditions, but no differentiation is made.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 80%, so the schema already documents most parameters well. The description adds value by clarifying the relationship between condition types and required parameters (e.g., 'present/visible/enabled/text require a selector; text/url/title require text'). This bridges gaps between parameters, though it does not detail the 'frame' parameter beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool waits until a condition holds, with specific verb+resource ('Wait for condition'). It lists the condition types and distinguishes itself from sleeping after an action, which differentiates it from sibling tools like 'click' or 'navigate'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use this tool ('Use this instead of sleeping after an action'), providing clear guidance on avoiding poor alternatives. However, it does not specify when not to use it or which sibling would be more appropriate for different scenarios, such as synchronous checks.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

10 tool updatesv0.1.0Aug 19, 2026
- First observedbrowser_close
- First observedbrowser_start
- First observedclick
- First observedinspect_page
- First observednavigate
- First observedscreenshot
- First observedselect
- First observedswitch_window
- First observedtype
- First observedwait_for

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.8/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: session management (start/close), navigation, inspection, interaction (click, type, select), window switching, waiting, and screenshot. No two tools overlap in functionality.

Naming Consistency3/5

The naming pattern is inconsistent: some tools use a 'browser_' prefix (browser_start, browser_close), while others are bare verbs (navigate, click, type) or compound snake_case (inspect_page, switch_window, wait_for). This mix of styles could cause confusion.

Tool Count5/5

With 10 tools, the set is well-scoped for browser automation. It covers session lifetime, navigation, element interaction, inspection, window handling, and waiting without being bloated or too thin.

Completeness3/5

The tools cover fundamental browser actions but miss common features like back/forward navigation, JavaScript execution, alert handling, or cookie management. The set is functional for basic scenarios but has notable gaps for comprehensive automation.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Airbyte AgentsOAuth
io.github.airbytehq
Let AI agents query data and act across all your business apps via MCP.
Data Platforms AI & Machine Learning RAG Systems
2
weavzOAuth
io.weavz
Governed app access for AI agents: 1,000+ apps & 12,000+ tools via Code Mode MCP.
Agent Orchestration Developer Tools
2
Aginx Browser A
net.aginx
Stealth web browser for agents: search, fetch, click, download and type in persistent MCP sessions.
Browser Automation Agent Orchestration
28114
Bitrix24 BOAuth
io.github.bitrix24
MCP server enabling AI agents to manage Bitrix24 features via standardized protocol
ERP Systems Project Management Communication
2

Related MCP Servers

Selenium MCP Server
nayakprashant
A
license
A
quality
C
maintenance
Exposes Selenium WebDriver as an MCP server, enabling AI agents and LLMs to control real browsers for automation tasks like navigation, element interaction, and screenshot capture.
Updated 6 months ago (2026-03-22 10:31 UTC)
22
3
MIT
Selenium MCP Server
Browser Automation Web Scraping
PhungXuanAnh
A
license
Not graded
quality
B
maintenance
An MCP server for web automation using Selenium WebDriver, enabling AI assistants to navigate, interact with elements, take screenshots, and manage browser storage.
Updated 8 days ago (2026-08-31 07:29 UTC)
11
MIT
ie-mcp
Browser Automation Web Scraping
thomfilg
A
license
A
quality
C
maintenance
Enables LLMs to drive Edge in IE mode for automating legacy IE-only web applications, supporting tasks like clicking, filling forms, and data extraction via Selenium.
Updated 2 months ago (2026-07-22 16:05 UTC)
28
MIT
selagent
Browser Automation Web Scraping Testing & QA Tools
akshay-rajan
A
license
Not graded
quality
D
maintenance
A Selenium-based MCP server that exposes browser automation tools for navigation, interaction, form filling, and assertions, enabling AI agents to control web browsers through natural language.
Updated 5 months ago (2026-04-09 16:04 UTC)
GPL 3.0

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/sumikof/iedriver-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

ie-mode-mcp

Table of Contents

1. Quick Start

2. Prerequisites

3. Windows Pre-configuration

3.1 Enable Edge IE Mode

3.2 IEDriver Required Settings

4. Installation and Build

5. Environment Variables

6. Startup Methods

Manual Startup (for verification)

Normal Operation

7. Registration with AI Agent

8. Tool Reference

Common: Selector

Common: frame (iframe is one level)

browser_start

navigate

inspect_page

click

type

select

wait_for

switch_window

screenshot

9. Usage Examples

Basic Loop

Example: Search for customer "Yamada Taro" and open detail screen

Example: Operate inside an iframe

Example: Operate a popup and return to the original window

10. Errors and Troubleshooting

Recovery from DRIVER_LOST

11. Logging

12. Troubleshooting

13. Development

14. Limitations

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

`browser_start`

`navigate`

`inspect_page`

`click`

`type`

`select`

`wait_for`

`switch_window`

`screenshot`

Recovery from `DRIVER_LOST`