Skip to main content
Glama
Sign In

mcp-server

by io.alterlab
OverviewDiscussionsAdmin

Start Browser Task

alterlab_task_start
Destructive

Open a browser task that keeps one page and login across calls, then drive it with alterlab_task_act and alterlab_task_observe. Pass start_url and the session handle from alterlab_connect. mode=read (default) blocks every action that changes something on the site; mode=write allows them, and each change waits for the user's approval. The task ends at its TTL.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "start_url": "<start_url>"
    },
    "name": "alterlab_task_start"
  }
}

Input Schema

NameRequiredDescriptionDefault
modeNoread (default) or write
ttl_sNoTask lifetime in seconds
limitsNoBudgets for the task
start_urlYesPage to open first
session_idNoSession handle from alterlab_connect or alterlab_sessions
instructionNoThe user's own words for this task. account_create is refused unless it names the site.
allowed_domainsNoExtra domains the task may visit

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare openWorld, destructive and non-idempotent, but the description adds the crucial policy layer: read mode blocks all mutating actions, write mode permits them only with per-change user approval, and the session terminates at TTL. It leaves open what happens to page state at TTL expiry and whether tasks consume credits.

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?

Four tight sentences, front-loaded with the core identity before the follow-up tools and the mode policy. No filler or restatement of the name.

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?

For a seven-parameter, open-world, destructive task opener with no output schema, the description covers the essentials: session continuity, mode gating, approval workflow and lifetime. Budgets (limits) and domain scoping are left entirely to the schema, which is a modest gap rather than a blocking one.

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, but the description goes beyond the schema's bare "read (default) or write" by explaining what each mode actually permits. It says nothing about ttl_s, limits budgets, instruction or allowed_domains, so four of seven parameters gain no extra meaning.

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?

"Open a browser task that keeps one page and login across calls" states a specific verb and resource plus the defining property (stateful session). It explicitly routes continuation to alterlab_task_act and alterlab_task_observe, so the agent can separate the opener from the drivers among the many siblings.

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 says what to do after starting (drive with act/observe) and how mode gates behavior, including the default. It stops short of naming when not to use this instead of alterlab_scrape, alterlab_screenshot or alterlab_task_vision_act, which matters given the crowded sibling set.

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

All mcp-server toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources