Skip to main content
Glama

pilot_import_cookies

Import cookies from a Chromium browser to transfer authenticated sessions to a headless browser, avoiding re-login and gaining access to protected pages.

Instructions

Import cookies from a real Chromium browser (Chrome, Arc, Brave, Edge, Comet) by decrypting the browser's cookie database and adding them to the headless session. Use when the user wants to transfer authentication state from their real browser, avoid re-login, access authenticated pages, or work with session cookies from an existing browser profile.

Parameters:

  • browser: Browser name to import from — "chrome", "arc", "brave", "edge", or "comet". Auto-detects if omitted

  • domains: Array of cookie domains to import (e.g., [".github.com", ".google.com"]). Omit to import ALL cookies (up to max_cookies)

  • profile: Browser profile name to read cookies from (default: "Default"). Use list_profiles to see available profiles

  • list_browsers: Set to true to list installed Chromium browsers on the system instead of importing

  • list_profiles: Set to true with browser to list available profiles for that browser

  • list_domains: Set to true with browser to list cookie domains available in that browser's database

Returns:

  • Import mode: Count of cookies imported, per-domain breakdown, and count of any that failed to decrypt

  • list_browsers mode: List of installed browser names

  • list_profiles mode: List of profiles with display names

  • list_domains mode: Top 50 cookie domains with counts

Errors:

  • "No Chromium browsers found": No supported browsers are installed. Check the system.

  • "Browser not found": The specified browser is not installed. Use list_browsers to see available options.

  • "Cookie database not found": The browser's cookie file does not exist at the expected path. Check the profile name.

  • Decryption failures: Some cookies may fail to decrypt (e.g., on Linux without keyring access). The count is reported.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
browserNoBrowser name (chrome, arc, brave, edge, comet). Auto-detects if omitted.
domainsNoCookie domains to import (e.g. [".github.com"]). Omit to import ALL cookies.
max_cookiesNoMax cookies to import when domains is omitted (default: 500)
profileNoBrowser profile name (default: "Default")
list_browsersNoList installed browsers instead of importing
list_profilesNoList available profiles for the specified browser
list_domainsNoList cookie domains available in the browser
Behavior4/5

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

With no annotations, the description carries full burden. It explains the decryption process, lists return values for each mode, and documents common errors including decryption failures on Linux. It doesn't cover potential side effects (e.g., impacting existing cookies) but the import operation is clearly described.

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

Conciseness3/5

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

The description is somewhat verbose with a paragraph and multiple bullet lists. While well-structured, it could be more concise. The purpose paragraph is front-loaded, but the extensive error list adds length.

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 no output schema, the description sufficiently covers return values for all modes and common errors. Parameters are all documented with practical examples. The tool's behavior across different modes (import vs. list) is fully explained.

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% with descriptions. The description adds extra context: browser auto-detection, domains as array, profile default, and list flags. It also explains the behavior of omitted parameters (e.g., import all cookies if domains omitted).

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 that the tool imports cookies from real Chromium browsers by decrypting their database, providing a specific verb (import) and resource (cookies from real browser). It distinguishes from sibling tools like pilot_cookies and pilot_auth by focusing on transferring authentication state from a local browser.

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 gives explicit use cases: 'transfer authentication state from their real browser, avoid re-login, access authenticated pages, or work with session cookies.' It also mentions modes like list_browsers for discovery, but doesn't explicitly contrast with alternatives.

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

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/TacosyHorchata/Pilot'

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