Skip to main content
Glama

manage_session

Manage Robot Framework session lifecycle: initialize sessions, import libraries and resources, set variables, and control 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It comprehensively describes all actions, parameters, their effects, and return values. It notes that test_status and test_message are session tracking metadata and do not affect the generated .robot file, which is an important behavioral detail.

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?

The description is lengthy but well-structured with clear sections for workflows, actions, parameters, returns, and examples. Each action is listed with its parameters and aliases. While it could be more concise, the structure makes it easy to navigate and understand.

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 the complexity of the tool with 24 parameters and 10+ actions, the description is extremely thorough. It covers all actions, parameter details, return format, and provides multiple examples. The context signals indicate high complexity and low schema coverage, and the description fully compensates.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It thoroughly explains each parameter for every action, including examples and usage context. For instance, it describes the scope parameter for set_variables, the template parameter for start_test, and the args parameter for add_data_row with a multi-line example.

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 the tool manages session lifecycle with specific verbs like initialize, configure, and organize. It distinguishes itself from analyze_scenario by stating that manage_session is for explicit session ops on an existing session, while analyze_scenario creates the session. The purpose is unambiguous and well-differentiated.

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 explicitly states when to use manage_session versus analyze_scenario, provides workflows for single and multi-test scenarios, and explicitly warns against calling action='init' right after analyze_scenario. It gives clear guidance on alternatives and appropriate contexts.

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/manykarim/rf-mcp'

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