Skip to main content
Glama

manage_session

Manage Robot Framework session lifecycle: initialize sessions, import libraries/resources, set variables, and structure multi-test workflows with start/end test actions.

Instructions

Manage session lifecycle: initialize, configure libraries/variables, and organize tests.

For a NEW scenario, prefer analyze_scenario — it is the front door that CREATES the session (and auto-configures libraries). Use manage_session for explicit session ops on an existing session (importing extra libraries/resources/variables, multi-test structure). Do NOT call action="init" right after analyze_scenario — the session already exists; that only causes redundant churn.

Workflows: Single test: analyze_scenario -> execute_step (repeat) -> build_test_suite Multi-test: analyze_scenario -> set_suite_setup -> start_test -> execute_step (repeat) -> end_test -> start_test -> ... -> build_test_suite (action="init" is the explicit alternative when you are NOT starting from analyze_scenario, e.g. driving a bare session directly.)

Actions and parameters (session_id is always required):

init             - Create session and load libraries (explicit entry; for a new
                   scenario prefer analyze_scenario instead).
                   Params: libraries (list of library names),
                           variables (dict or list to pre-set).

import_library   - Add a library to an existing session.
                   Params: library_name, args (constructor args), alias.

import_resource  - Import a Robot Framework resource file.
                   Params: resource_path, args.

set_variables    - Set variables in the session.
                   Params: variables (dict {"NAME": "value"} or list ["NAME=value"]),
                           scope ("test" | "suite" | "global", default "suite").

import_variables - Load variables from a Python variable file.
                   Params: variable_file_path, args (passed to get_variables()).

start_test       - Begin a named test (enables multi-test mode). Local mode only.
                   Params: test_name (required),
                           test_documentation, test_tags,
                           test_setup (dict {"keyword": "...", "arguments": [...]}),
                           test_teardown (same format as test_setup).
                   Alias: start_task.

end_test         - End the current test. Local mode only.
                   Params: test_status ("pass" or "fail", default "pass"),
                           test_message (optional error description).
                   NOTE: test_status and test_message are session tracking metadata.
                   They do NOT affect the .robot file generated by build_test_suite.
                   Alias: end_task.

add_data_row     - Add a data row to the current data-driven (template) test.
                   Requires an active test with template set via start_test.
                   Params: args (list of values matching the template keyword's [Arguments]).
                   Alias: data_row.
                   Example:
                     manage_session(action="start_test", test_name="Cart Test",
                                  template="Add And Verify Product")
                     manage_session(action="add_data_row", args=["Backpack", "1", "$29.99"])
                     manage_session(action="add_data_row", args=["Bike Light", "2", "$39.98"])
                     manage_session(action="end_test")
                   The data rows appear under [Template] in the generated .robot file.

list_tests       - List all tests in the session with their status and step counts.
                   Params: (none).

set_suite_setup    - Set a suite-level setup keyword (appears in *** Settings ***).
                     Params: keyword (required), args (keyword arguments).

set_suite_teardown - Set a suite-level teardown keyword (appears in *** Settings ***).
                     Params: keyword (required), args (keyword arguments).

Returns: Dict with success, session_id, and action-specific details. On failure: error and guidance fields are present.

Examples: Initialize session with libraries: manage_session(action="init", session_id="s1", libraries=["Browser", "BuiltIn", "Collections"])

Set suite-level variables:
    manage_session(action="set_variables", session_id="s1",
                   variables={"BASE_URL": "https://example.com", "TIMEOUT": "30"})

Import a library with constructor arguments:
    manage_session(action="import_library", session_id="s1",
                   library_name="Browser", args=["chromium"])

Load a Python variable file:
    manage_session(action="import_variables", session_id="s1",
                   variable_file_path="config/variables.py",
                   args=["production", "secret_key"])

Start a named test (multi-test mode):
    manage_session(action="start_test", session_id="s1",
                   test_name="Login Test", test_tags=["smoke"],
                   test_setup={"keyword": "Open Browser", "arguments": ["chromium"]})

End the current test:
    manage_session(action="end_test", session_id="s1")

Set suite setup (for generated .robot file):
    manage_session(action="set_suite_setup", session_id="s1",
                   keyword="New Browser", args=["chromium"])

Set suite teardown:
    manage_session(action="set_suite_teardown", session_id="s1",
                   keyword="Close Browser")

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
argsNo
aliasNo
scopeNosuite
actionYes
keywordNo
profileNo
scenarioNo
templateNo
librariesNo
test_nameNo
test_tagsNo
variablesNo
model_nameNo
model_tierNo
session_idNo
test_setupNo
test_statusNopass
library_nameNo
test_messageNo
tool_profileNo
resource_pathNo
test_teardownNo
test_documentationNo
variable_file_pathNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/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 reveals important side effects and constraints: init after analyze_scenario causes redundant churn, end_test status is only session tracking metadata and does not affect the generated .robot file, add_data_row rows appear under [Template], and start_test/end_test are local mode only. This is strong, specific behavioral transparency.

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 long but appropriately structured for a multi-action tool: it opens with the key routing warning, then provides workflows, per-action parameters, return behavior, and examples. Every section is useful, and the most important usage guidance is front-loaded.

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 tool with 24 parameters, no annotations, and zero schema descriptions, the description is unusually comprehensive: it covers workflows, all major actions, return values, failure guidance, and common usage examples. The main gap is the undocumented set_tool_profile/tool_profile-related parameters and a few schema-only fields, leaving some invocation paths unexplained.

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?

The schema has 0% description coverage, so the description compensates in detail for most parameters: each action lists its relevant params, and examples clarify data shapes such as variables, test_setup, and args. However, several schema parameters—profile, tool_profile, scenario, model_name, model_tier, and the set_tool_profile action—are not documented in the description, and template is referenced but not listed under start_test params. This prevents a perfect score.

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 opening sentence states the tool's scope: "Manage session lifecycle: initialize, configure libraries/variables, and organize tests." It then differentiates itself sharply from analyze_scenario, which is the session-creating front door. This makes the tool's purpose and boundaries immediately clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit when-to-use and when-not-to-use guidance: prefer analyze_scenario for new scenarios, do not call action="init" right after analyze_scenario, and use manage_session for explicit session operations on existing sessions. It also provides concrete single-test and multi-test workflows and an explicit alternative for the init action.

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/carlos-eduardo-1984/RobotFrameworkMCP'

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