Skip to main content
Glama
dragons96

MCP-Undetected-Chromedriver

by dragons96

browser_press_key

Press specified keys in a Chrome browser controlled by MCP-Undetected-Chromedriver, with optional focus on elements via CSS selector.

Instructions

Press a key on the keyboard

Args:
    key: The key to press - required, (e.g. 'Enter', 'ArrowDown', 'a')
    selector: Optional CSS selector to focus on before pressing the key - optional

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
keyYes
selectorNo

Implementation Reference

  • Implements the browser_press_key tool handler using Selenium's ActionChains to press keys, supporting special keys mapping and optional selector focus. Registered via @mcp.tool() decorator.
    @mcp.tool()
    async def browser_press_key(
            key: str,
            selector: str = None,
    ):
        """Press a key on the keyboard
    
        Args:
            key: The key to press - required, (e.g. 'Enter', 'ArrowDown', 'a')
            selector: Optional CSS selector to focus on before pressing the key - optional
        """
        assert key, "Key is required"
    
        async def press_key_handler(driver: uc.Chrome):
            # 如果提供了选择器,先找到元素并聚焦
            if selector:
                element = driver.find_element(By.CSS_SELECTOR, selector)
                element.click()  # 点击元素以确保聚焦
    
            # 处理特殊键
            special_keys = {
                'Enter': '\ue007',
                'Tab': '\ue004',
                'Escape': '\ue00c',
                'Space': '\ue00d',
                'Backspace': '\ue003',
                'Delete': '\ue017',
                'ArrowUp': '\ue013',
                'ArrowDown': '\ue015',
                'ArrowLeft': '\ue012',
                'ArrowRight': '\ue014',
                'PageUp': '\ue00e',
                'PageDown': '\ue00f',
                'Home': '\ue011',
                'End': '\ue010',
                'F1': '\ue031',
                'F2': '\ue032',
                'F3': '\ue033',
                'F4': '\ue034',
                'F5': '\ue035',
                'F6': '\ue036',
                'F7': '\ue037',
                'F8': '\ue038',
                'F9': '\ue039',
                'F10': '\ue03a',
                'F11': '\ue03b',
                'F12': '\ue03c',
            }
    
            # 映射按键
            key_to_send = special_keys.get(key, key)
    
            # 创建ActionChains对象
            actions = ActionChains(driver)
    
            # 发送按键
            if selector:
                element = driver.find_element(By.CSS_SELECTOR, selector)
                actions.send_keys_to_element(element, key_to_send)
            else:
                actions.send_keys(key_to_send)
    
            # 执行操作
            actions.perform()
    
            if selector:
                return await create_success_response(f"Pressed key '{key}' on element '{selector}'")
            else:
                return await create_success_response(f"Pressed key '{key}'")
    
        return await tool.safe_execute(
            ToolContext(webdriver=await ensure_browser()), press_key_handler
        )
  • The @mcp.tool() decorator registers the browser_press_key function as an MCP tool.
    @mcp.tool()
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 states the action but lacks behavioral details such as whether it simulates a single key press or holds, error handling (e.g., if selector is invalid), performance implications, or what happens after pressing (e.g., page navigation). This leaves gaps for an agent to understand execution nuances.

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 appropriately sized with a clear purpose statement followed by parameter explanations. It uses bullet-like formatting for args, which aids readability. However, the second sentence could be more front-loaded, and some redundancy exists (e.g., repeating 'optional' in the selector description).

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 2 parameters with 0% schema coverage and no annotations or output schema, the description provides basic context but is incomplete. It covers parameter semantics adequately but lacks behavioral transparency, usage guidelines, and details on return values or errors, which are crucial for a tool with potential side effects in a browser environment.

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 0%, so the description must compensate. It adds meaning by explaining 'key' as the key to press with examples (e.g., 'Enter', 'ArrowDown', 'a') and 'selector' as an optional CSS selector to focus on first. This clarifies parameter purposes beyond the schema's minimal titles, though it could provide more detail on key formats or selector usage.

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 action ('Press a key on the keyboard') and specifies the resource (keyboard interaction in a browser context). It distinguishes from siblings like browser_click or browser_fill by focusing on keyboard input rather than mouse actions or form filling. However, it doesn't explicitly contrast with all siblings (e.g., browser_select might also involve keyboard use).

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 usage for keyboard interactions in a browser, and the optional 'selector' parameter suggests it can focus on elements first. However, it lacks explicit guidance on when to use this versus alternatives like browser_fill for text input or browser_click for mouse actions, and no exclusions or prerequisites are mentioned.

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

Install Server

Other Tools

Related Tools

Latest Blog Posts

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/dragons96/mcp-undetected-chromedriver'

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