Skip to main content
Glama

browser_add_cookie_by_name

Add a cookie to the browser by specifying its name and value for web automation and testing scenarios.

Instructions

Add a cookie to the browser

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesName of the cookie to add
valueYesValue of the cookie to add

Implementation Reference

  • The handler function for the browser_add_cookie_by_name tool, which instantiates CookieService and calls addCookieByName
    async ({ name, value }) => {
      const driver = stateManager.getDriver();
      const cookieService = new CookieService(driver);
      await cookieService.addCookieByName(name, value);
      return {
        content: [{ type: 'text', text: `Added cookie: ${name}` }],
      };
    }
  • Input schema using Zod for the tool parameters: name and value
    {
      name: z.string().describe('Name of the cookie to add'),
      value: z.string().min(1).max(4096).describe('Value of the cookie to add'),
    },
  • Registration of the browser_add_cookie_by_name tool using server.tool, including description, schema, and handler
    server.tool(
      'browser_add_cookie_by_name',
      'Add a cookie to the browser',
      {
        name: z.string().describe('Name of the cookie to add'),
        value: z.string().min(1).max(4096).describe('Value of the cookie to add'),
      },
      async ({ name, value }) => {
        const driver = stateManager.getDriver();
        const cookieService = new CookieService(driver);
        await cookieService.addCookieByName(name, value);
        return {
          content: [{ type: 'text', text: `Added cookie: ${name}` }],
        };
      }
    );
  • Core helper method in CookieService that adds the cookie to the browser using Selenium WebDriver.manage().addCookie
    async addCookieByName(name: string, value: string): Promise<void> {
      await this.driver.manage().addCookie({ name, value });
    }
Behavior2/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 states the action ('Add a cookie') but doesn't mention whether this requires specific permissions, if it's idempotent, what happens on failure, or any side effects (e.g., overwriting existing cookies). For a mutation tool, this leaves significant gaps in understanding its behavior.

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 a single, efficient sentence with zero waste—'Add a cookie to the browser' is front-loaded and directly conveys the core purpose without unnecessary elaboration, making it easy to parse quickly.

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 the tool's complexity (a mutation operation with no annotations and no output schema), the description is insufficient. It lacks details on behavioral traits, error handling, or return values, leaving the agent with incomplete information for safe and effective use in a browser automation context.

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?

The schema description coverage is 100%, with clear descriptions for both parameters ('name' and 'value'). The description doesn't add any semantic details beyond what the schema provides (e.g., cookie format constraints or domain/path defaults), so it meets the baseline score of 3 where the schema does the heavy lifting.

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 'Add a cookie to the browser' clearly states the action (add) and resource (cookie), with 'to the browser' providing context. However, it doesn't differentiate from sibling 'browser_set_cookie_object' (which likely adds cookies via an object format), leaving some ambiguity about when to use this specific tool versus alternatives.

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?

No guidance is provided on when to use this tool versus alternatives like 'browser_set_cookie_object' or 'browser_delete_cookie'. The description lacks context about prerequisites (e.g., browser must be open) or typical use cases, offering minimal help for an agent to make informed decisions.

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/pshivapr/selenium-mcp'

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