Skip to main content
Glama
DB-25

arc-control-mcp

by DB-25
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Open URL

open_url

Open a URL in Arc via automation, launching it if needed and placing tabs in a dedicated agent window instead of the user's active window. Waits for user inactivity; retry if busy.

Instructions

Open a URL in Arc. Launches Arc if needed. New tabs go into one dedicated agent window (placed on a second display when there is one), never the user's own window, and the user's focused window is put back if Arc raised another. Waits until the user has stopped typing or moving the mouse, and fails with userActive true if they never pause: retry later. Pass activate to bring the tab to the front.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesURL to open
spaceNoSpace id or title to open into, overriding the agent space
tab_idNoWith new_tab false, the tab to navigate. Required in that mode unless this agent already has a tab of its own, since navigating the tab the user is looking at is refused.
new_tabNoOpen a new tab. Set false to navigate an existing tab instead.
activateNoBring Arc to the front and leave the new tab selected. Visible to the user, so it waits for them to pause.
little_arcNoOpen a Little Arc window. Fire and forget: Arc does not expose these afterwards.
timeout_msNoHow long to wait for loading. Capped at 30000ms so the call cannot outlive a client's request timeout. To wait longer, call this again.
wait_until_loadedNoWait for the page to finish loading before returning

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.4.0
    • changedInput schema / properties / activate / description
      Previous value: -"Bring Arc to the front and leave the new tab selected"New value: +"Bring Arc to the front and leave the new tab selected. Visible to the user, so it waits for them to pause."
    • changedInput schema / properties / tab_id / description
      Previous value: -"With new_tab false, the tab to navigate"New value: +"With new_tab false, the tab to navigate. Required in that mode unless this agent already has a tab of its own, since navigating the tab the user is looking at is refused."
    • changedInput schema / properties / timeout_ms / description
      Previous value: -"How long to wait for loading. Capped at 30000ms, because a longer call is killed by the client before it can answer. To wait longer, call wait_for_load again: repeated short waits each hand back a real readyState and url, which one long wait does not."New value: +"How long to wait for loading. Capped at 30000ms so the call cannot outlive a client's request timeout. To wait longer, call this again."
  2. First observedv0.3.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations only declare the generic profile (not read-only, open-world, not idempotent, not destructive). The description adds substantial context the annotations cannot convey: dedicated agent window placement on a second display, restoration of the user's focused window, the pause-until-idle gating, the userActive failure mode, and the activate side effect.

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?

Purpose and launch behavior are front-loaded, and nearly every sentence carries load-bearing operational facts. It is somewhat dense in a single paragraph and could be segmented, but there is no wasted filler.

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?

For an open-world, non-idempotent action with no output schema, the description covers launch, window targeting, idle-wait semantics, the failure signal, retry advice, and activation. The schema fully covers parameters, so nothing an agent needs to call this correctly is missing.

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 coverage is 100%, so the schema already documents all eight parameters, including the nuanced tab_id and timeout_ms notes. The description only echoes activate ('Pass activate to bring the tab to the front'), which the schema already states, so it adds little beyond the baseline.

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 opens with a specific verb+resource ('Open a URL in Arc') and immediately scopes behavior ('Launches Arc if needed'), making it trivially distinguishable from siblings like close_tab, get_current_tab, or reload_tab. An agent knows exactly what this tool does without opening the schema.

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?

It gives clear operational context: tabs land in a dedicated agent window, the user's focused window is restored, and on userActive failure the guidance is 'retry later'. It also notes when to pass activate. However, it names no alternative sibling tools and states no explicit when-not-to-use exclusion, so it stops short of a 5.

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

Deploy Server

Other Tools