Skip to main content
Glama

set_cookies

Inject cookies to authenticate a Chromium session for Infinite Backlog. Provide a JSON array of name/value/domain/path; only infinitebacklog.net cookies are accepted.

Instructions

Inject cookies for authenticated sessions. JSON array: [{"name":"...","value":"...","domain":".infinitebacklog.net","path":"/"}, ...] Only infinitebacklog.net cookies are accepted.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cookies_jsonYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.1

TDQS

A3.5/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the domain restriction and the required JSON shape, and the output schema covers return values, but it omits whether injected cookies replace or merge with existing session cookies, whether they persist across browser restarts, or any auth/permission requirements.

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?

Three short lines, front-loaded with the action and use case, followed by the concrete payload format and the acceptance constraint. No sentence is wasted, though the format example could arguably be tightened.

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?

For a one-parameter tool with an output schema, the payload format and domain constraint are adequately covered. The main missing context is lifecycle behavior relative to the surrounding browser tools (when in the workflow to inject, and whether it must precede open_site).

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?

With a single parameter at 0% schema description coverage, the description compensates well by giving the exact JSON array structure and the object keys (name/value/domain/path) expected for each cookie. Only minor gaps remain, such as whether additional cookie attributes like expires or secure are honored.

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?

States a specific verb (inject/set) and resource (cookies) with the added scope constraint that only infinitebacklog.net cookies are accepted. An agent can immediately tell this is an authentication-setup action, though it does not name a sibling tool to distinguish itself from the other browser/session tools.

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?

'For authenticated sessions' implies the use case, so the agent can infer this is called to establish a logged-in state. However, there is no explicit when-to-use instruction, no mention of when not to call it, and no reference to alternatives such as open_site or run_browser_use_task.

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