Skip to main content
Glama
RapierCraft

alterlab-mcp-server

by RapierCraft
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

alterlab_refresh_session

Rotate session cookies and reset failure counters to reactivate a session after browser re-authentication. Omit cookies to only reset failure counters.

Instructions

Refresh a session by rotating its cookies and resetting failure counters. This is the preferred way to update cookies after re-authenticating in your browser. The session status is reset to active. If cookies are omitted, only the failure counters are reset.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cookiesNoNew cookies to replace the old ones. If omitted, only failure counters are reset. Cookies as a {name: value} object (e.g. {"session-id": "abc123"}) or as a list (max 100) of cookie objects with metadata: {name, value, domain?, path?, secure?, httpOnly?, sameSite?, expires?}.
headersNoUpdated custom headers to include with the session
session_idYesUUID of the session to refresh

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.9.0
    • removedInput schema / properties / cookies / additionalProperties
      Removed value: -{
-  "type": "string"
-}
    • addedInput schema / properties / cookies / anyOf
      Added value: +[
+  {
+    "additionalProperties": {
+      "type": "string"
+    },
+    "type": "object"
+  },
+  {
+    "items": {
+      "additionalProperties": true,
+      "properties": {
+        "domain": {
+          "type": "string"
+        },
+        "expires": {
+          "type": "number"
+        },
+        "httpOnly": {
+          "type": "boolean"
+        },
+        "name": {
+          "minLength": 1,
+          "type": "string"
+        },
+        "path": {
+          "type": "string"
+        },
+        "sameSite": {
+          "type": "string"
+        },
+        "secure": {
+          "type": "boolean"
+        },
+        "value": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "name",
+        "value"
+      ],
+      "type": "object"
+    },
+    "maxItems": 100,
+    "type": "array"
+  }
+]
    • changedInput schema / properties / cookies / description
      Previous value: -"New cookie key-value pairs to replace the old ones. If omitted, only failure counters are reset."New value: +"New cookies to replace the old ones. If omitted, only failure counters are reset. Cookies as a {name: value} object (e.g. {\"session-id\": \"abc123\"}) or as a list (max 100) of cookie objects with metadata: {name, value, domain?, path?, secure?, httpOnly?, sameSite?, expires?}."
    • removedInput schema / properties / cookies / type
      Removed value: -"object"
  2. First observedv1.5.0

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the full behavioral burden and does well: it discloses the mutation (cookie rotation), the side effect of resetting status to active, and the fallback behavior when cookies are omitted. It omits auth/permission requirements and reversibility, so not a full 5.

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?

Three sentences, front-loaded with the core action, then usage context, then the edge-case behavior. No filler and each sentence adds distinct information.

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 3-param mutation tool with nested objects and no annotations or output schema, the description adequately conveys what changes and when. It could still note authentication prerequisites or what the refreshed session returns, keeping it short of 5.

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 three parameters (including the cookies conditional and format). The description largely restates the omit-cookies behavior that the schema already encodes, adding 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?

States a specific verb (refresh) and resource (session) and enumerates the concrete effects: rotating cookies, resetting failure counters, and setting status to active. The phrase 'preferred way to update cookies' implicitly distinguishes it from sibling tools like alterlab_update_session, letting an agent tell them apart.

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?

Provides a clear when-to-use trigger ('after re-authenticating in your browser') and the conditional path when cookies are omitted. It stops short of naming alternatives or explicit exclusions, so it clears the 4 bar but not the 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