Enables mobile automation testing using AppiumLibrary, allowing AI agents to create and execute mobile app tests.
Enables AI agents to create, execute, and manage Robot Framework test suites from natural language, including stepwise execution and final test generation.
Provides tools to write and run Selenium-based web automation tests using SeleniumLibrary within Robot Framework.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@RobotMCP Create a test suite for saucedemo.com login and checkout"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Plain English in, real Robot Framework tests out — with an AI agent doing the typing.
RobotMCP (rf-mcp) is a Model Context Protocol (MCP) server that hands your coding
agent the keys to Robot Framework. The agent discovers keywords, runs steps live
against Browser, Selenium, Appium, Requests, a database, or the desktop, sees what
actually happens, and — once the steps pass — writes you a clean .robot suite.
No guessed locators, no hallucinated keywords, no "works on my machine". Built on
Robot Framework: open source, and always evolving.
New to rf-mcp? Jump to Getting Started. Want the full picture? See the MCP tool reference, configuration, and worked examples.
📺 Video Tutorial
Intro
https://github.com/user-attachments/assets/ad89064f-cab3-4ae6-a4c4-5e8c241301a1
Three commands and a sentence. That's the whole setup.
# Everything (Browser, Selenium, Appium, Requests, Database)
uv tool install "rf-mcp[all]"
# ...or just what you need — API testing is pure Python, nothing else to do:
uv tool install "rf-mcp[api]"This puts a robotmcp command on your PATH. Extras decide which test libraries come
along — see the extras table under Installation.
robotmcp init # detects libraries, prints the MCP config to paste
robotmcp install # registers rf-mcp into the agents it findsrobotmcp install writes the right MCP config for Claude Code, Codex, GitHub
Copilot, opencode, Gemini CLI, Kilo Code, goose, and Cursor — each in its own
format, without touching your other servers. Prefer to do it by hand? Every agent
accepts:
{ "mcpServers": { "robotmcp": { "command": "robotmcp" } } }{
"servers": {
"robotmcp": {
"type": "stdio",
"command": "uv",
"args": ["run", "-m", "robotmcp.server"],
"env": { "UV_COMPILE_BYTECODE": "1" }
}
}
}
UV_COMPILE_BYTECODE=1precompiles the dependency tree at install time. Without it, the first server launch after an install/upgrade pays several seconds of.pyccompilation before the MCP handshake completes (some clients time out and show the server as unavailable). It is a one-time, install-time cost.
Start the MCP server with HTTP transport:
uv run -m robotmcp.server --transport http --host 127.0.0.1 --port 8000Then configure your AI agent:
{
"servers": {
"robotmcp": {
"type": "http",
"url": "http://localhost:8000/mcp"
}
}
}claude mcp add rf-mcp -- uvx rf-mcpUse #robotmcp to create a TestSuite and execute it step wise.
Create a test for https://www.saucedemo.com/ that:
- Logs in to https://www.saucedemo.com/ with valid credentials
- Adds two items to cart
- Completes checkout process
- Verifies success message
Use Selenium Library.
Execute the test suite stepwise and build the final version afterwards.That's it. rf-mcp walks the agent through discovery, live execution, and suite generation — you just describe the test.
Related MCP server: Robot Framework MCP Server
Guide | What's inside |
Install, wire into your agent, run your first test | |
Every tool rf-mcp exposes to the agent — parameters, returns, when to reach for it | |
Every | |
Copy-pasteable web / API / mobile / desktop / BDD / data-driven walkthroughs | |
Teach rf-mcp about your own Robot Framework libraries | |
Steer the agent's behavior per project |
The Quick Start covers the recommended path (uv tool install). This
section has the extras table, alternative install methods, and the full agent-registration
details.
Extras decide which Robot Framework libraries come along:
Extra | Adds | Post-install |
| RequestsLibrary | none |
| SeleniumLibrary + Browser | Selenium: none (Selenium Manager fetches the driver); Browser: |
| AppiumLibrary | Appium server (external) |
| DatabaseLibrary | a DB driver |
| PlatynUI native desktop (Windows/Linux) | Python 3.12+ |
| Django dashboard | — |
| Persistent semantic memory (sqlite-vec + model2vec) |
|
| all Robot Framework libraries above (includes | as above |
Browser Library also needs Playwright browsers — run robotmcp init --browsers (or
rfbrowser init) once, inside rf-mcp's own environment. Node.js is only needed for Browser.
pip install "rf-mcp[all]" # pip instead of uv
uv add "rf-mcp[all]" && uv sync # into an existing uv project
# From source (development)
git clone https://github.com/manykarim/rf-mcp.git && cd rf-mcp
uv sync --all-extras --devPre-built images (headless for CI, plus a VNC image for visual debugging):
docker pull ghcr.io/manykarim/rf-mcp:latest # headless
docker run -p 8000:8000 -p 8001:8001 ghcr.io/manykarim/rf-mcp:latest # HTTP + frontend
docker run -it --rm ghcr.io/manykarim/rf-mcp:latest uv run robotmcp # STDIO
docker pull ghcr.io/manykarim/rf-mcp-vnc:latest # X11 desktop over VNC/noVNC
docker run -p 8000:8000 -p 8001:8001 -p 5900:5900 -p 6080:6080 ghcr.io/manykarim/rf-mcp-vnc:latestHeadless bundles Chromium, Firefox ESR and the Playwright browsers. VNC ports: 8000 (MCP HTTP), 8001 (frontend), 5900 (VNC), 6080 (noVNC — http://localhost:6080/vnc.html).
robotmcp list # supported agents + what's detected/registered
robotmcp install # interactive: registers into detected agents
robotmcp install --agents claude-code,codex,gemini
robotmcp install --agents all --scope user
robotmcp install --dry-run # show the plan, write nothing
robotmcp uninstall # safe, reversible removalSupported agents (each written in its own file/format, other MCP servers preserved):
Claude Code, OpenAI Codex, GitHub Copilot, opencode, Gemini CLI, Kilo Code, goose,
Cursor (plus pi, listed as planned until its config convention is confirmed).
Uses your project's environment. Install into a project that has its own set-up
environment (uv, poetry, pdm, pipenv, rye, hatch, or a plain .venv) and rf-mcp is wired to
run against that environment — so it sees your project's libraries, keywords and resources,
not just its bundled ones. It launches the resolved command and verifies your libraries are
reachable before writing the config; a blind or broken command is refused. A global
uvx / uv tool install still serves every project with no per-project setup. Point it with
-C <dir>, opt into installing rf-mcp into the project env with --into-project, and run
robotmcp doctor --project-dir <dir> to see which of your libraries the launch reaches.
Scope. Installs default to --scope project (writes into the current project, e.g.
./.mcp.json) where the agent supports it; use --scope user for a global (home-directory)
install. goose only supports user scope; GitHub Copilot only supports project scope.
Safe & reversible. Every change is recorded in a hash-tracked manifest
(~/.local/state/robotmcp/install-manifest.json). robotmcp uninstall removes only entries
unchanged since install — a hand-edited entry is left in place and reported, and unrelated
servers are never touched. Prefer to edit config yourself? Add
{ "mcpServers": { "robotmcp": { "command": "robotmcp" } } }.
Extend RobotMCP with custom libraries via the plugin system. Two discovery modes are available:
Entry points (robotmcp.library_plugins) for packaged plugins.
Manifest files (JSON) under .robotmcp/plugins/ for workspace overrides.
See the Library Plugin Authoring Guide for detailed instructions and explore the sample plugin in examples/plugins/sample_plugin to get started quickly.
RobotMCP ships with an optional Django-based dashboard that mirrors active sessions, keywords, and tool activity.
Install frontend extras
pip install rf-mcp[frontend]Start the MCP server with the frontend enabled
uv run -m robotmcp.server --with-frontendDefault URL: http://127.0.0.1:8001/
Quick toggles: --frontend-host, --frontend-port, --frontend-base-path
Environment equivalents: ROBOTMCP_ENABLE_FRONTEND=1, ROBOTMCP_FRONTEND_HOST, ROBOTMCP_FRONTEND_PORT, ROBOTMCP_FRONTEND_BASE_PATH, ROBOTMCP_FRONTEND_DEBUG
Connect your MCP client (Cline, Claude Desktop, etc.) to the same server process—the dashboard automatically streams events once the session is active.
To disable the dashboard for a given run, either omit the flag or pass --without-frontend.
RobotMCP sends server-level instructions to LLMs via the MCP initialize response, guiding them to discover keywords before executing them. This significantly reduces failed tool calls and wasted tokens, especially for smaller LLMs.
Three environment variables control instruction behavior:
Variable | Values | Default |
|
|
|
|
|
|
| Path to | (none, required when mode=custom) |
|
|
|
| set to | (off) |
Output & logging. The MCP stdio channel (stdout) carries only JSON-RPC; all logs and a one-line readiness banner go to stderr. Logging defaults to
WARNINGso the client is not flooded — setROBOTMCP_LOG_LEVEL=INFO/DEBUGto troubleshoot. Logging never blocks execution (it is drained on a background thread with drop-on-overflow), and fd 1 is never redirected out from under the transport.
Template | ~Tokens | Best For |
| ~40 | Capable LLMs (Claude Opus, GPT-4) — brief reminder only |
| ~400 | Mid-range LLMs (Claude Sonnet, GPT-4o) — balanced workflow guide |
| ~600 | Smaller LLMs (Claude Haiku, GPT-4o-mini) — step-by-step with examples |
| ~350 | Web-only testing scenarios |
| ~300 | API-only testing scenarios |
{
"servers": {
"robotmcp": {
"type": "stdio",
"command": "uv",
"args": ["run", "-m", "robotmcp.server"],
"env": {
"ROBOTMCP_INSTRUCTIONS": "default",
"ROBOTMCP_INSTRUCTIONS_TEMPLATE": "detailed"
}
}
}
}Set ROBOTMCP_INSTRUCTIONS=custom and provide a file via ROBOTMCP_INSTRUCTIONS_FILE. Custom files support {available_tools} placeholder substitution. Allowed extensions: .txt, .md, .instruction, .instructions. If the file is missing or fails validation, the server falls back to the standard template automatically.
See docs/INSTRUCTION_TEMPLATES_GUIDE.md for the full guide.
https://github.com/user-attachments/assets/8d87cd6e-c32e-4481-9f37-48b83f69f72f
RobotMCP ships with robotmcp.attach.McpAttach, a lightweight Robot Framework library that exposes the live ExecutionContext over a localhost HTTP bridge. When you debug a suite from VS Code (RobotCode) or another IDE, the bridge lets RobotMCP reuse the in-process variables, imports, and keyword search order instead of creating a separate context.
Example configuration with passed environment variables for Debug Bridge
{
"servers": {
"RobotMCP": {
"type": "stdio",
"command": "uv",
"args": ["run", "src/robotmcp/server.py"],
"env": {
"ROBOTMCP_ATTACH_HOST": "127.0.0.1",
"ROBOTMCP_ATTACH_PORT": "7317",
"ROBOTMCP_ATTACH_TOKEN": "change-me",
"ROBOTMCP_ATTACH_DEFAULT": "auto"
}
}
}
}{
"servers": {
"RobotMCP": {
"command": "docker",
"args": ["run", "-i", "--rm", "ghcr.io/manykarim/rf-mcp:latest", "uv", "run", "robotmcp"],
"env": {
"ROBOTMCP_ATTACH_HOST": "127.0.0.1",
"ROBOTMCP_ATTACH_PORT": "7317",
"ROBOTMCP_ATTACH_TOKEN": "change-me",
"ROBOTMCP_ATTACH_DEFAULT": "auto"
}
}
}
}Import the library and start the serve loop inside the suite that you are debugging:
*** Settings ***
Library robotmcp.attach.McpAttach token=${DEBUG_TOKEN}
*** Variables ***
${DEBUG_TOKEN} change-me
*** Test Cases ***
Serve From Debugger
MCP Serve port=7317 token=${DEBUG_TOKEN} mode=blocking poll_ms=100
[Teardown] MCP StopMCP Serve port=7317 token=${TOKEN} mode=blocking|step poll_ms=100 — starts the HTTP server (if not running) and processes bridge commands. Use mode=step during keyword body execution to process exactly one queued request.
MCP Stop — signals the serve loop to exit (used from the suite or remotely via RobotMCP attach_stop_bridge).
MCP Process Once — processes a single pending request and returns immediately; useful when the suite polls between test actions.
MCP Start — alias for MCP Serve for backwards compatibility.
The bridge binds to 127.0.0.1 by default and expects clients to send the shared token in the X-MCP-Token header.
Start robotmcp.server with attach routing by providing the bridge connection details via environment variables (token must match the suite):
export ROBOTMCP_ATTACH_HOST=127.0.0.1
export ROBOTMCP_ATTACH_PORT=7317 # optional, defaults to 7317
export ROBOTMCP_ATTACH_TOKEN=change-me # optional, defaults to 'change-me'
export ROBOTMCP_ATTACH_DEFAULT=auto # auto|force|off (auto routes when reachable)
export ROBOTMCP_ATTACH_STRICT=0 # set to 1/true to fail when bridge is unreachable
uv run python -m robotmcp.serverWhen ROBOTMCP_ATTACH_HOST is set, execute_step(..., use_context=true) and other context-aware tools first try to run inside the live debug session. Use the new MCP tools to manage the bridge from any agent:
attach_status — reports configuration, reachability, and diagnostics from the bridge (/diagnostics).
attach_stop_bridge — sends a /stop command, which in turn triggers MCP Stop in the debugged suite.
Prompt:
Use RobotMCP to create a test suite and execute it step wise.
It shall:
- Open https://demoshop.makrocode.de/
- Add item to cart
- Assert item was added to cart
- Add another item to cart
- Assert another item was added to cart
- Checkout
- Assert checkout was successful
Execute step by step and build final test suite afterwards
Create in BDD style and use Keywords with embedded arguments when applicableResult: BDD-style Robot Framework test suite with Given/When/Then keywords, embedded arguments, and extracted variables.
Prompt:
Use RobotMCP to create a test suite and execute it step wise.
It shall:
- Open https://saucedemo.com
- Login with different user/password combinations
- Assert message or login
Execute step by step and build final test suite afterwards
Create in datadriven style and add multiple test rows with different scenarios
Use Test Template setting in suiteResult: Data-driven Robot Framework test suite with Test Template and parameterized rows for each login scenario.
Prompt:
Use RobotMCP to create a TestSuite and execute it step wise.
It shall:
- Launch app from tests/appium/SauceLabs.apk
- Perform login flow
- Add products to cart
- Complete purchase
Appium server is running at http://localhost:4723
Execute the test suite stepwise and build the final version afterwards.Result: Mobile test suite with AppiumLibrary keywords and device capabilities.
Prompt:
Read the Restful Booker API documentation at https://restful-booker.herokuapp.com.
Use RobotMCP to create a TestSuite and execute it step wise.
It shall:
- Create a new booking
- Authenticate as admin
- Update the booking
- Delete the booking
- Verify each response
Execute the test suite stepwise and build the final version afterwards.Result: API test suite using RequestsLibrary with proper error handling.
Prompt:
Create a xml file with books and authors.
Use RobotMCP to create a TestSuite and execute it step wise.
It shall:
- Parse XML structure
- Validate specific nodes and attributes
- Assert content values
- Check XML schema compliance
Execute the test suite stepwise and build the final version afterwards.Result: XML processing test using Robot Framework's XML library.
rf-mcp exposes its capabilities to the agent as MCP tools, grouped by purpose: planning & orchestration, session & execution, discovery & documentation, observability & diagnostics, suite lifecycle, locator guidance, visual validation, and optional persistent memory.
Full reference: docs/MCP_TOOLS.md — every tool with its parameters, returns, and when to reach for it. Your agent reads these descriptions directly; you rarely need to call them by hand.
Prompt:
Use RobotMCP to create a test suite and execute it step wise.
It shall:
- Open https://demoshop.makrocode.de/
- Add item to cart
- Assert item was added to cart
- Add another item to cart
- Assert another item was added to cart
- Checkout
- Assert checkout was successful
Execute step by step and build final test suite afterwards
Create in BDD style and use Keywords with embedded arguments when applicableResult: RobotMCP executes each step, inspects the DOM between actions, and generates a BDD-style suite with Given/When/Then keywords:
*** Test Cases ***
Demoshop BDD Purchase Workflow
Given the demoshop is open
When the user adds the first product to cart
Then the cart should contain 1 item
When the user adds the second product to cart
Then the cart should contain 2 items
When the user proceeds to checkout
And the user fills in the checkout form
And the user places the order
Then the order confirmation should be displayed
*** Keywords ***
the demoshop is open
New Browser chromium
New Context
New Page ${DEMOSHOP_URL}
the user adds the first product to cart
Click ${FIRST_PRODUCT_BUTTON}During stepwise execution, use bdd_group and bdd_intent on execute_step to control how steps are grouped into behavioral keywords. Call build_test_suite(bdd_style=True) at the end.
Prompt:
Use RobotMCP to create a test suite and execute it step wise.
It shall:
- Open https://saucedemo.com
- Login with different user/password combinations
- Assert message or login
Execute step by step and build final test suite afterwards
Create in datadriven style and add multiple test rows with different scenarios
Use Test Template setting in suiteResult: RobotMCP builds a parameterized suite using Test Template with named data rows:
*** Settings ***
Library Browser
Test Template Verify Login
*** Test Cases *** USERNAME PASSWORD EXPECTED
Valid User standard_user secret_sauce Products
Locked Out User locked_out_user secret_sauce locked out
Invalid Password standard_user wrong_pass Username and password do not matchUse manage_session(action="start_test", template="Verify Login") to set the template keyword, then manage_session(action="add_data_row", test_name="Valid User", args=["standard_user", "secret_sauce", "Products"]) to add each row.
RobotMCP includes optimizations for small and medium-sized LLMs (8K-32K context windows) that reduce token overhead and improve tool call accuracy.
Control which tools are visible to the LLM based on the workflow phase. Smaller models see fewer, more compact tools:
manage_session(action="set_tool_profile", tool_profile="browser_exec")Profiles: browser_exec, api_exec, discovery, minimal_exec, full. Reduces tool description overhead from ~7,000 to ~1,000 tokens. Can also be set via the ROBOTMCP_TOOL_PROFILE environment variable.
Control response detail level to reduce token consumption. Available on most tools via the detail_level parameter:
minimal – Essential output only (60-80% token reduction)
standard – Balanced output (default)
full – Complete detailed output
Set a default via ROBOTMCP_OUTPUT_VERBOSITY=compact|standard|verbose.
get_session_state supports incremental responses that only return sections that changed since the last call:
# First call returns full state (version 1):
get_session_state(session_id="...", sections=["variables", "page_source"])
# Subsequent calls return only what changed:
get_session_state(session_id="...", mode="delta", since_version=1)In mode="auto" (the default), the server automatically returns delta responses when a previous version exists. This reduces token usage by 50-80% for multi-step workflows where only variables or page content change between steps.
Large outputs (HTML page source, execution logs, stack traces) are automatically externalized into fetchable artifacts instead of being inlined in the response:
# Response includes artifact_id instead of full content:
{"result": "...", "artifact_id": "abc123", "artifact_hint": "Full page source available via fetch_artifact"}
# Fetch when needed:
fetch_artifact(artifact_id="abc123")This keeps tool responses compact while preserving access to full output on demand.
The intent_action tool provides a library-agnostic entry point for common test actions. Instead of requiring the LLM to know library-specific keyword names and locator syntax, it expresses intent:
intent_action(intent="click", target="text=Login", session_id="...")
intent_action(intent="fill", target="#username", value="testuser", session_id="...")The server resolves intent + target to the correct keyword and locator format for the session's active library (Browser, SeleniumLibrary, or AppiumLibrary).
When intent_action(intent="navigate") fails because no browser or page is open, the server automatically opens the browser/page and retries:
Browser Library: executes New Browser + New Page (or just New Page if browser exists)
SeleniumLibrary: executes Open Browser about:blank chrome
The response includes fallback_applied: true and fallback_steps count. Saves 2-4 tool calls per session.
The execute_batch tool executes multiple keywords in a single MCP call, reducing N round-trips to 1. Steps can reference results from earlier steps via ${STEP_N} variables:
execute_batch(session_id="...", steps=[
{"keyword": "Go To", "args": ["https://example.com"]},
{"keyword": "Get Title", "assign_to": "title"},
{"keyword": "Should Be Equal", "args": ["${STEP_2}", "Example Domain"]}
], on_failure="recover")If a step fails, resume_batch lets you insert fix steps and retry from the failure point.
When a Browser Library keyword fails because the selector matches multiple elements (Playwright strict mode), the error response includes a hint suggesting >> nth=0 (zero-based index) or >> visible=true selector chains, with concrete examples using the actual keyword name and element count.
All action/mode/strategy parameters use Literal types, producing enum constraints in the JSON Schema. This eliminates hallucinated values (e.g., action="setup" instead of action="init"). All values accept case-insensitive input.
Common small LLM mistakes are corrected server-side:
JSON-stringified arrays ("[\"Browser\"]") are parsed to native arrays
Comma-separated strings ("Browser,BuiltIn") are split into lists
Deprecated keywords (GET) are mapped to current equivalents (GET On Session)
Configurable server-level instructions guide LLMs to follow the "discover-then-act" pattern. Choose a template sized for your LLM's capability — from minimal (~40 tokens) for Claude Opus to detailed (~600 tokens) for Claude Haiku. See Instruction Templates above.
RobotMCP can learn from past sessions and recall successful patterns, locators, and error fixes — reducing trial-and-error for repeated testing scenarios.
Memory is powered by sqlite-vec (vector search) and model2vec (256-dimensional embeddings). When enabled, the server:
Stores successful step sequences, working locators, and error→fix mappings after each tool call
Recalls relevant memories and injects them as hints into tool responses (e.g., execute_step failures include previous fixes, get_session_state includes previously successful step patterns)
Learns across sessions — the warm database persists between server restarts
pip install rf-mcp[memory]
# or
uv pip install rf-mcp[memory]Enable via environment variables:
{
"servers": {
"robotmcp": {
"type": "stdio",
"command": "uv",
"args": ["run", "-m", "robotmcp.server"],
"env": {
"ROBOTMCP_MEMORY_ENABLED": "true",
"ROBOTMCP_MEMORY_DB_PATH": "./memory.db"
}
}
}
}When memory is enabled, five additional tools become available:
Tool | Description |
| Recall previously successful step sequences. Call before building new test steps to reuse proven patterns. |
| Recall known fixes for an error. Call immediately when |
| Recall working locators for a UI element. Call before DOM inspection for familiar elements. |
| Store domain knowledge (e.g., site structure, auth flows) for future recall. |
| Check memory availability and statistics at session start. |
Memory hints are automatically injected into existing tool responses — no LLM cooperation required:
execute_step failures: Previous fixes and working locators are included in the error response
get_session_state: Previously successful step patterns for the scenario are included
analyze_scenario: Recalled step sequences from past sessions are suggested
All memory lookups have a 50ms timeout to avoid impacting response latency.
Tested across 8 scenarios (72 opencode invocations, 3 iterations each) with qwen/qwen3-coder:
Scenario Type | Best Result | Memory Recall Rate |
Complex web flows (checkout) | -23% calls, -22% tokens | 3/3 iterations |
Exploration-heavy browsing | -44% calls on best iteration | 3/3 iterations |
API error recovery | -3% calls ±3% (tightest CI) | 3/3 iterations |
Memory benefits are strongest for complex, multi-step scenarios where past locators and step sequences reduce exploratory tool calls.
rf-mcp runs with sensible defaults; when you need to tune it, everything is an environment variable away — instruction templates, the attach bridge, output/token economy, memory, the frontend dashboard, PlatynUI desktop safety, and more.
Full reference: docs/CONFIGURATION.md — every
ROBOTMCP_* variable with its accepted values and default, plus the robotmcp
CLI flags and subcommands.
We welcome contributions! Here's how to get started:
Fork the repository
Clone your fork locally
Install development dependencies: uv sync
Create a feature branch
Add comprehensive tests for new functionality
Run tests: uv run pytest tests/
Submit a pull request
v0.34.0 – Native desktop automation (rf-mcp[desktop], PlatynUI, Windows-ready); project-aware installer that uses your project's own libraries; leaner agent instructions; cold-start hang, Windows dry-run deadlock and generated-suite path fixes; tool profiles restored on FastMCP 3
v0.31.1 – Packaging cleanup (exclude tests/examples from sdist)
v0.31.0 – BDD/data-driven generation, namespace architecture fixes, persistent memory, 71-88% token reduction
v0.30.1 – FastMCP 3.x compatibility layer
v0.30.0 – Small LLM optimization (tool profiles, intent action, response optimization, type constraints)
v0.29.0 – Instruction templates, multi-test sessions, batch execution, smart timeouts
Apache 2.0 License - see LICENSE file for details.
⭐ Star us on GitHub if RobotMCP helps your test automation journey!
Made with ❤️ for the Robot Framework and AI automation community.
Analyze a natural-language scenario into structured intent and create a session.
WORKFLOW: This is the single front door — your FIRST tool call for any test scenario. It CREATES the session, so do NOT also call manage_session(action="init") for the same scenario (that causes redundant session churn). Reuse the returned session_id in every later call.
What this tool does:
Creates a new session with unique session_id (or reuses provided one)
Analyzes scenario to detect context (web/api/mobile/desktop)
Auto-configures libraries based on scenario text
Returns session_id for use in ALL subsequent tool calls
CRITICAL: Save the session_id from the response and use it in all other tool calls.
| Name | Required | Description | Default |
|---|---|---|---|
| context | No | Application context (e.g., "web", "mobile", "api", "desktop"); defaults to "web". An explicit context="desktop" DETERMINISTICALLY forces a native desktop (PlatynUI) session regardless of scenario wording — phrasing or word order cannot flip it to mobile/Appium. Use it for Linux/GNOME desktop GUI scenarios. | web |
| scenario | Yes | Human-language description of the task to automate. | |
| session_id | No | Optional existing session id to reuse; if omitted, a new one is created. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It details session creation, context detection, library auto-configuration, and session_id reuse. However, it does not mention error conditions or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with headings and bullet points, but slightly lengthy. Every sentence contributes meaning, though some rephrasing could reduce verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description covers the essential workflow, session reuse, and deterministic context handling. It could be improved by mentioning error handling or prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
100% schema coverage means parameters are documented. The description adds value by explaining the deterministic behavior of context parameter (e.g., context='desktop' forces PlatynUI) and optional session_id reuse.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is the 'single front door' tool for any test scenario, creating a session and analyzing scenario into structured intent. It explicitly distinguishes from manage_session by warning not to call both.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit workflow: 'FIRST tool call for any test scenario' and advises against redundant manage_session calls. Also explains when to reuse session_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a Robot Framework test suite from previously executed steps.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Optional test tags. | |
| bdd_style | No | Generate BDD-style suite with a Keywords section. When True, steps are grouped into behavioral keywords (Given/When/Then) and a ``*** Keywords ***`` section is appended to the generated .robot content. | |
| test_name | Yes | Name for the generated test case. | |
| session_id | No | Session containing executed steps; auto-resolves if empty/invalid. | |
| output_path | No | Optional absolute path to persist the generated .robot suite to disk directly (UTF-8; parent directories created). ALWAYS use this to save a suite — do NOT write ``rf_text`` via the ``Create File`` keyword: Robot Framework resolves ``${variables}`` and interprets ``\n``/``\t`` escapes inside the argument, which silently corrupts the suite content (assigned vars collapse to their runtime values, escaped newlines become raw line breaks). Writing here goes through plain file I/O and preserves the generated text byte-for-byte. When set, the response includes ``output_path`` and ``output_bytes`` (or ``output_error`` on a write failure — the build still succeeds). | |
| documentation | No | Optional test case documentation. | |
| data_driven_mode | No | How to render data-driven (template) test cases. "auto" (default) — auto-detect: named rows → suite_template, else per_test. "per_test" — [Template] per test case with data rows (current behavior). "suite_template" — Test Template in Settings, each named row is a separate test case with individual pass/fail in reports. | auto |
| include_pre_start | No | Whether to adopt exploratory steps executed BEFORE start_test into the generated test body. Default False excludes them (the response reports ``excluded_pre_start_count`` + a summary) so the suite reflects only intended in-test interactions. Set True to preserve the prior adoption behavior. | |
| remove_library_prefixes | No | Whether to strip library prefixes from keywords. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavioral traits. It fails to mention that the tool may write to disk via 'output_path', whether it mutates session state, or what the expected output contains. The description is too sparse to inform safe usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. While brevity is good, it sacrifices necessary detail; a slightly more informative description could improve this score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 9 parameters and the existence of an output schema, the description is too terse. It does not explain the generated artifact, the role of the session, or the available configuration options (e.g., data_driven_mode, bdd_style). The agent is left to infer behavior from parameter descriptions alone, which is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds no extra meaning beyond the general purpose; all parameter details are in the schema. No credit is earned for adding semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a Robot Framework test suite from previously executed steps, which is a specific and distinct purpose. However, it does not explicitly differentiate from sibling tools like 'run_test_suite' or 'analyze_scenario', missing an opportunity for clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. The description does not mention prerequisites (e.g., a session with executed steps) or contraindications, leaving the agent without context for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify that specified Robot Framework libraries can be imported/installed.
Recommended as step 3 after analyze_scenario and recommend_libraries; use the recommended names to avoid unnecessary checks.
| Name | Required | Description | Default |
|---|---|---|---|
| libraries | Yes | Library names to verify (preferably from recommend_libraries output). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only says 'verify', giving minimal behavioral insight. Does not disclose side effects, authentication needs, or what happens on failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences with front-loaded purpose. No redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the basic operation for a simple verification tool. Could include more about return format (though output schema exists) or scope, but sufficient given low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage for the single parameter. Description adds value by suggesting using output from recommend_libraries, which aids correct usage beyond raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'verify' and resource 'Robot Framework libraries can be imported/installed'. Distinguishes from siblings like recommend_libraries which recommends rather than verifies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states it is step 3 after analysis and recommendation, with advice to use recommended names to avoid unnecessary checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute multiple RF keywords in one call with recovery and variable chaining.
Reduces N MCP round-trips to 1. Steps run sequentially; each step's return value is available to later steps via ${STEP_N} references in arguments. Both 0-based (${STEP_0} = first step) and 1-based (${STEP_1} = first step) indexing are accepted. When ambiguous, 1-based is preferred.
| Name | Required | Description | Default |
|---|---|---|---|
| steps | Yes | List of step dicts, each with: - keyword (str, required): RF keyword name - arguments (list[str], optional): Positional arguments, may contain ${STEP_N} (both 0-based and 1-based indexing supported). This is the canonical key (parity with execute_step). The legacy alias ``args`` is also accepted; supplying BOTH with different values is a validation error. - label (str, optional): Human-readable label - timeout (str, optional): Per-step RF timeout (e.g., "10s") - assign_to (str, optional): Variable name to capture return value (e.g., "cart_count") NOTE: batch steps do NOT support ``bdd_group``/``bdd_intent`` — use per-step ``execute_step(bdd_group=..., bdd_intent=...)`` for BDD grouping. A step missing ``keyword`` returns an actionable validation error. | |
| on_failure | No | Policy on step failure: - "stop": abort immediately - "retry": retry without recovery logic - "recover" (default): attempt tiered recovery before giving up On DESKTOP (PlatynUI) sessions, retries are restricted to failures where the input provably never fired (element-not-found); any other desktop failure records immediately instead of blindly re-firing a click/keystroke, and retries run with a capped descriptor-resolution timeout so a bad locator cannot burn the whole budget. | recover |
| session_id | Yes | Session to execute within (must exist or be auto-created). | |
| timeout_ms | No | Total batch time budget in milliseconds (1000-600000, default 120000). | |
| max_recovery_attempts | No | Max recovery retries per failed step (1-10, default 2). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains sequential execution, variable chaining with indexing, on_failure policies (stop, retry, recover), and desktop-specific retry restrictions. It also notes beta API stability. This comprehensively addresses behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two paragraphs. It front-loads the core benefit, then covers key behavioral details. Every sentence adds value. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple steps, failure handling, variable chaining) and that an output schema exists, the description is complete. It covers usage, failure policies, and limitations (no BDD grouping). The session auto-creation mention is in the schema, but the description otherwise suffices.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are documented. The description adds context beyond the schema: details on variable chaining syntax, on_failure policies, desktop retry logic, and that missing keyword returns validation error. This adds meaningful value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes multiple RF keywords in one call with recovery and variable chaining. It distinguishes from sibling tools like execute_step (single step) and resume_batch (resuming). The purpose is specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use: to reduce round-trips by batching steps sequentially. It also says when not to use: BDD grouping per step is not supported, use execute_step for that. This provides clear context and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute structured flow (if/for/try) within a session.
| Name | Required | Description | Default |
|---|---|---|---|
| items | No | Items to iterate when structure="for". | |
| rethrow | No | Whether to rethrow after except/finally. | |
| item_var | No | Variable name to bind each item in for-each loops. | item |
| condition | No | Expression for if/conditional flows. | |
| structure | Yes | Flow type ("if", "for", "try"). | |
| try_steps | No | Steps for the try block (when structure="try"). | |
| else_steps | No | Steps for the else branch (if). | |
| session_id | Yes | Session id to run the flow in. | |
| then_steps | No | Steps for the main branch (if/loop body/try block). | |
| except_steps | No | Steps for the except block. | |
| finally_steps | No | Steps for the finally block. | |
| max_iterations | No | Maximum iterations for for-each loops. | |
| except_patterns | No | Error patterns to match for except handling. | |
| stop_on_failure | No | Whether to stop loop/branch execution on first failure. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states 'Execute structured flow' with no disclosure of behavioral traits such as side effects, error handling, authentication needs, or rate limits. The description is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core purpose. It is concise but could benefit from additional context without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (14 parameters, control flow structures), the description is incomplete. It lacks information about how flows execute, output schema details, and important constraints. The description does not adequately prepare an agent for correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 14 parameters have descriptions in the schema. The tool description adds no additional meaning beyond what the schema already provides. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'execute' 'structured flow' and specifies the flow types (if/for/try) within a session. This distinguishes it from siblings like 'execute_step' which likely executes a single step, and 'execute_batch' which runs a batch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing to run control flow logic, but does not provide explicit guidance on when to use this tool versus alternatives like 'execute_step' or 'execute_batch'. No exclusions or comparisons are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a single Robot Framework keyword (or Evaluate) within a session.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | "keyword" (default) or "evaluate" (runs BuiltIn.Evaluate). | keyword |
| record | No | Override the record gate that decides whether a successful step is appended to session.steps for build_test_suite output. - None (default): auto-classify. Read-only inspection keywords (Get Title, Log, etc.) are NOT recorded; everything else IS. Carve-outs that always record: ``assign_to`` is set, or a named test is currently open (after start_test). - True: force-record this step regardless of classification. - False: drop this step regardless of classification. The decision is surfaced as ``recorded: bool`` in the response. | |
| keyword | Yes | Keyword name (Library.Keyword supported). Use find_keywords to discover correct keyword names before calling. | |
| arguments | No | Keyword arguments; positional and named (`name=value`) supported. | |
| assign_to | No | Variable name(s) to assign the result to (string or list). CRITICAL: Use this to capture results for later steps. Example: assign_to="response" captures ${response} variable | |
| bdd_group | No | Optional group name for BDD keyword generation. Steps with the same bdd_group are clustered into a single behavioral keyword when build_test_suite(bdd_style=True) is called. Example: bdd_group="add product to cart" | |
| bdd_intent | No | BDD intent prefix for the group: "given", "when", "then", "and", "but". Used with bdd_group to assign Given/When/Then prefixes in the generated BDD test suite. | |
| expression | No | Expression for mode="evaluate"; falls back to keyword/first argument. | |
| session_id | No | Session to execute in; resolves default if omitted. | default |
| timeout_ms | No | Optional timeout in milliseconds for keyword execution. If not provided, uses smart defaults based on keyword type: - Element actions (Click, Fill): 5000ms - Navigation (Go To, New Page): 60000ms - Read operations (Get Text): 2000ms - API calls (GET, POST): 30000ms Set to 0 or negative to disable timeout. | |
| use_context | No | Whether to run inside RF native context; defaults via config/attach. | |
| detail_level | No | Response verbosity: "minimal" | "standard" | "full". | minimal |
| scenario_hint | No | Optional scenario text to auto-configure libraries on first call. | |
| raise_on_failure | No | If True, raise on failure; otherwise return error in payload. | |
| pre_validate_timeout_ms | No | Override the pre-validation gate's timeout for this single call. Pre-validation is the fast ~500ms-default check that verifies an element is visible / enabled before the keyword runs; it auto-retries once with a 200ms backoff on transient failures. - None (default): use ``ExecutionConfig.PRE_VALIDATION_TIMEOUT`` (500ms) for slow-loading pages this is sometimes too tight. - A positive int (e.g. 2000): extend the gate to this many milliseconds for this call only. Useful when a page legitimately takes ~1–2s to settle. - 0 or negative: skip pre-validation entirely for this call (last resort — also disables the keyword timeout). Failure responses include a ``pre_validate_timeout_hint`` entry explaining how to use this when the gate trips. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully convey behavioral traits. It only states the basic action but omits critical behavior: how it handles failures (unless parameter 'raise_on_failure' is understood), the recording logic (controlled by 'record' parameter), variable assignment via 'assign_to', and timeout behavior. These are left entirely to the input schema, which the agent must parse independently.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is clear and front-loaded with the primary action. It is concise and avoids unnecessary words. However, it could benefit from a brief note about the most important parameters (e.g., keyword is required) or a link to related documentation, but overall it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high complexity (15 parameters, output schema, and many optional behaviors), the description is incomplete. It does not explain the overall workflow, such as how sessions work, how to capture results, or how the recording decision affects test suite generation. Even though an output schema exists, the description should provide a high-level overview of the tool's capabilities and typical use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the burden on the description is lower. The description does not add any parameter meaning beyond what the schema provides – it does not explain, e.g., that 'mode' switches between keyword and evaluate, or that 'assign_to' captures results. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the core action: executing a single Robot Framework keyword or Evaluate function within a session. The verb 'Execute' and resource 'single Robot Framework keyword (or Evaluate)' are specific, and the context 'within a session' further clarifies the scope. This distinguishes it from sibling tools like 'execute_batch' which runs multiple steps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives like 'execute_batch' or 'find_keywords'. It does not mention prerequisites, such as needing a session to be created first, or any exclusions. The usage context is only implied by the tool name and description, but no direct comparisons or conditions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discover Robot Framework keywords using multiple strategies.
WHEN TO USE THIS TOOL:
ALWAYS before calling execute_step with an unfamiliar keyword
When you're unsure of exact keyword name or spelling
To discover what keywords are available in imported libraries
When error says "No keyword with name 'X' found"
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Optional maximum number of results to return. | |
| query | Yes | Search text or intent description. Examples: "click a button", "validate json", "get*request" | |
| context | No | Scenario context (e.g., "web", "mobile", "api") used by semantic discovery. | web |
| strategy | No | Discovery approach: - "semantic": Hybrid keyword search combining name/doc pattern matching, tag/action-class classification, and (when installed) sentence-transformers embedding similarity. For best semantic ranking, install the optional extra: ``uv add robotmcp[semantic]``. Without the extra, falls back to pattern + tag + difflib SequenceMatcher ranking; the strategy is still useful but ranking quality is reduced. - "pattern": Glob/regex matching (best when you know partial name) - "catalog": List all available keywords. This is a LITERAL substring filter on keyword/library names — a multi-word natural-language query will return 0; use library_name= to list a library (e.g. "PlatynUI"/"PlatynUI.BareMetal"), or strategy="semantic" for intent matching. - "session": List keywords from session's loaded libraries | semantic |
| session_id | No | Required for strategy="session" to search the live RF namespace. | |
| library_name | No | Optional library filter applied to ALL strategies. When set, restricts results to the named library and its compatible siblings (e.g., library_name="Browser" excludes SeleniumLibrary but keeps BuiltIn, Collections, String). Takes precedence over the session's explicit_library_preference when both are present. Catalog strategy additionally scopes the underlying lookup to this library. | |
| current_state | No | Optional state payload to improve semantic matching. | |
| strict_library | No | OBS-33 — when True AND a library preference is set (via ``library_name`` or session ``explicit_library_preference``), exclude EVERY library that isn't the preferred one. Default behaviour (False) preserves "compatible siblings" — BuiltIn / Collections / String / DateTime etc. remain visible alongside the preferred library. Use strict mode to scope discovery tightly to a single library (e.g., pattern ``"Get*"`` + ``library_name="Browser"`` + ``strict_library=True`` → Browser keywords only, no BuiltIn helpers). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description fully explains the tool's behavior including strategy fallbacks, library filtering, and strict mode. This is comprehensive for a non-destructive discovery tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear heading, bullet points for when-to-use, and concise explanations. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, output schema existence, and the complexity of strategies, the description covers all necessary aspects. It explains parameter interplay and use cases completely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by explaining the strategy parameter in detail and how library_name interacts with strategies, going beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool discovers Robot Framework keywords using multiple strategies. It distinguishes from siblings like execute_step (which runs keywords) by explicitly stating when to use this tool before executing an unfamiliar keyword.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'WHEN TO USE THIS TOOL' section provides explicit guidance: always before calling execute_step with an unfamiliar keyword, when unsure of exact name, to discover available keywords, and when an error indicates a keyword is not found.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get keyword/library docs or parse a signature. Call this before execute_step when you know the keyword name but not its arguments.
Modes: "keyword" (default — document one keyword), "library" (list a library's keywords), "session" (resolve against the live session namespace), "parse" (parse a signature string). Pass session_id to scope the lookup to that session's libraries.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | One of "keyword" (default), "library", "session", or "parse". | keyword |
| arguments | No | Optional arguments to parse when mode="parse". | |
| session_id | No | Optional session id. - mode="keyword" / "global" (OBS-19): when provided without ``library_name``, restricts the keyword lookup to libraries imported in that session (plus neutral helpers like BuiltIn, Collections). When the keyword exists only in other libraries, the response carries a library-mismatch error + plugin-generated alternative hint instead of the keyword doc. Sessions without ``session_id`` get the global lookup (cross-library matches[]). - mode="session" / "namespace": required to address the live RF namespace. - **Externalisation gate (OBS-21)**: any mode with ``session_id`` provided enables artifact externalisation for large payloads (``library.doc``, ``library.keywords``, ``keyword.doc``, ``matches``). Without ``session_id``, payloads stay inline regardless of size — there's no artifact store to write to, so sessionless callers get the full content. Preserves backwards compat. | |
| keyword_name | No | Keyword to document (required for modes "keyword"/"session"/"parse"). | |
| library_name | No | Library to document (required for mode "library"; optional for keyword mode — explicit per-call scope that takes precedence over session-derived scope). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: modes, session scoping, artifact externalization based on session_id, and error handling (library-mismatch with alternative hint). It provides comprehensive behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-structured, and front-loaded with the core purpose. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, 4 modes, session scoping), the description covers all necessary context. An output schema exists, so return values are handled externally. The description is complete for a lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining usage patterns for modes and session_id, complementing the schema's parameter details. However, most parameter semantics are already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get keyword/library docs or parse a signature.' It specifies multiple modes and distinguishes itself from siblings like `find_keywords` and `execute_step`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Call this before execute_step when you know the keyword name but not its arguments.' It also lists modes, but could improve by contrasting with `find_keywords` for alternative scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Provide locator/selector guidance for Browser, SeleniumLibrary, AppiumLibrary, PlatynUI.BareMetal, or RequestsLibrary.
For API testing, call with library="requests" (or "api") to get a RequestsLibrary request/response cookbook — session setup, response-field access (${resp.json()["field"]}), the $resp-in-Evaluate rule, Status Should Be, JSON body/headers, the Cookie token header, and expected_status= for non-2xx — BEFORE writing Evaluate-based assertions.
For VISUAL validation, call with library="visual" (or "screenshot") to learn WHEN a screenshot beats the DOM/ARIA tree (canvas/image text, layout/overlap, obscured elements, color, charts) and the dual read-back pattern — useful for any UI library (Browser/Selenium/Appium/PlatynUI) when a multimodal model drives rf-mcp.
| Name | Required | Description | Default |
|---|---|---|---|
| library | No | Target library ("Browser", "SeleniumLibrary", "AppiumLibrary", "PlatynUI.BareMetal", or "RequestsLibrary"/"api"). Case-insensitive. | browser |
| keyword_name | No | Optional keyword name for context-specific hints. | |
| error_message | No | Optional error text to tailor guidance (e.g., from a failed keyword). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes what guidance is returned (cookbook, patterns) but does not disclose side effects, authorization needs, or limitations. Adequate but leaves some behavioral traits implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with clear sections for API testing and visual validation, front-loading the purpose. Somewhat verbose but earns its length by providing valuable context. Could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of handling multiple libraries, the description is sufficiently complete for an agent to understand when and how to use the tool. Output schema exists, so return values are documented there. Covers main use cases well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage for all 3 parameters. Description adds context by explaining the 'cookbook' for API and visual scenarios but does not significantly enhance parameter semantics beyond the schema descriptions. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool provides locator/selector guidance for several libraries (Browser, SeleniumLibrary, AppiumLibrary, PlatynUI.BareMetal, RequestsLibrary) and distinguishes between API testing and visual validation use cases. It is specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description gives explicit when-to-use guidance: for API testing call with library='requests' before assertions; for visual validation call with library='visual' for screenshot vs DOM. Provides context but does not explicitly mention when not to use or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve aggregated session state for debugging and visibility.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | auto | |
| sections | No | Specific data blocks to include (e.g., summary, page_source, variables, application_state, ui_tree). ui_tree (desktop/PlatynUI sessions only): accessibility-tree snapshot. Lists applications; pass application names via elements_of_interest to expand their subtrees (bounded depth, ADR-025). | |
| session_id | Yes | Active session identifier to inspect. | |
| state_type | No | Type of application state to fetch when requesting application_state (dom|api|database|all). | all |
| since_version | No | ||
| dom_chunk_size | No | Maximum size of each DOM chunk when streaming is enabled (minimum 1024 bytes). | |
| include_dom_stream | No | Chunk large page_source payloads into page_source_stream entries for easier transport. | |
| include_reduced_dom | No | Whether to include lightweight semantic DOM (ARIA snapshots) for quick inspection. | |
| elements_of_interest | No | Targeted element identifiers passed to application state collectors. | |
| page_source_filtered | No | When True, returns sanitized/filtered DOM text instead of the full source. | |
| page_source_filtering_level | No | Filtering aggressiveness for DOM output (standard|aggressive). | standard |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'aggregated session state' without detailing side effects, rate limits, or performance implications. It does not state it's read-only or what 'aggregated' entails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence, but it is overly minimal for a tool with 11 parameters. It is concise but sacrifices substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 complex parameters and an output schema, the description lacks completeness. It does not explain what 'aggregated' means, the structure of the return, or how to choose parameter values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 82% (high), so baseline is 3. The description adds no parameter-specific information beyond the schema. It does not elaborate on how to use parameters like mode or sections.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves aggregated session state for debugging and visibility. It is distinct from siblings like manage_session which deals with session lifecycle, but does not explicitly differentiate or mention alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidelines on when to use this tool vs alternatives (e.g., execute_step, manage_session). There is no mention of prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a high-level intent that auto-resolves to the correct library keyword.
Valid intents: navigate, click, fill, hover, select, assert_visible, extract, wait_for.
Also accepted but DEPRECATED:
extract_text — equivalent to extract with mode="text". The
extract verb is the canonical mode-aware getter (text /
attribute / count / value / url / title) and additionally surfaces
extracted_value at the top level of the response. extract_text
will be removed in a future release; prefer intent="extract" for
new code.
The intent is resolved based on the session's active library (Browser/SeleniumLibrary/AppiumLibrary).
| Name | Required | Description | Default |
|---|---|---|---|
| nth | No | Zero-based nth-match index. Disambiguates when multiple elements match the same locator (e.g., an id duplicated across mobile vs desktop nav). Browser library appends ``>> nth=<n>``; SeleniumLibrary appends ``:nth-of-type(<n+1>)`` for CSS locators only (other locator types are unaffected and log a debug-level warning). | |
| mode | No | For ``intent="extract"`` only. Selects what to read from the page; ignored for other intents. "text" — element text content (default) "attribute" — element attribute value (requires attribute_name) "count" — number of matching elements (multi-match OK) "value" — DOM property "value" (input values) "url" — current page URL (no target needed) "title" — current page title (no target needed) The extracted value is surfaced as ``result["extracted_value"]`` and assigned to ``assign_to`` if provided. mode="count" additionally skips pre-validation for this call — counting is the only mode where matching zero/multiple elements is the expected outcome rather than a failure. | text |
| force | No | Use when: the element is visible but Playwright reports it "blocked by another element" — overlay, sticky header, cookie-consent banner, modal backdrop, animation still running. Symptom: ``Click intercepted`` or ``element is not stable`` / ``outside of the viewport`` errors despite the element appearing correct in the ARIA snapshot. Example: a "Submit" button covered by a sticky consent banner the user can't dismiss programmatically. What it does: for a Browser-library click intent, swaps ``Click`` for ``Click With Options force=True``, which skips Playwright's actionability checks. For other libraries / intents whose mapping declares no ``force_keyword``, the flag is silently ignored. Caveat: do NOT use ``force=True`` to drive elements that are genuinely hidden (display:none, visibility:hidden) — that's an anti-pattern; the resulting click won't behave like a real user click. Prefer natural locators first; fall through to ``force=True`` only when an overlay is the genuine cause. | |
| match | No | Select-match strategy for the ``select`` intent. ``"label"`` (default) - match by visible option text. Mirrors RF semantics for ``Select Options By label``. ``"value"`` - match by ``<option value="X">`` attribute. ``"index"`` - match by zero-based integer index. ``"text"`` - synonym for ``"label"`` (most libraries). ``"auto"`` - OPT-IN heuristic. Numeric value -> ``"value"``, otherwise ``"label"``. Use with care: numeric visible labels (years, amounts) mis-route. For SeleniumLibrary, this also picks the dispatched keyword (``Select From List By Label`` / ``Value`` / ``Index``). Ignored for non-select intents. | label |
| value | No | Value for fill/select intents | |
| commit | No | Use when: the page uses Vue, React, Angular reactive forms, jQuery validate, idealForms, formvalidation.io, or any framework that gates validation on the DOM ``change`` event. Symptom: a form submit is rejected with a "required" or validation error despite every visible field appearing correctly filled; the framework's internal model still thinks the inputs are empty because Playwright's ``fill`` didn't fire a real ``change``. What it does: after a successful Browser-library FILL, dispatches a real DOM ``change`` event on the target via Browser's ``Dispatch Event`` keyword. Off by default — the follow-up is best-effort and any failure is logged and ignored (it never escalates a successful fill into a failed step). No effect for non-FILL intents, non-Browser libraries, or failed fills. | |
| intent | Yes | Action verb (e.g. "click", "navigate", "fill", "extract") | |
| target | No | Locator or URL (e.g. "#submit", "text=Login", "https://example.com"). Optional for extract mode="url"/mode="title". | |
| options | No | Additional options (e.g. {"timeout": "10s"}) | |
| assign_to | No | Variable name to capture result (esp. useful for extract: the extracted text/count/attribute is assigned to this var). | |
| session_id | No | Session to execute against (uses default if not provided) | |
| detail_level | No | Response detail level | standard |
| attribute_name | No | Required when ``intent="extract"`` and ``mode="attribute"``; the HTML attribute name to read (e.g. ``"href"``, ``"data-testid"``, ``"value"``). Ignored for other modes. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It explains the resolution mechanism and deprecation, but lacks details on side effects, error handling, permissions, or rate limits. For a tool with 13 parameters and potential mutations, more transparency would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: three sentences that front-load the purpose, list intents, cover deprecation, and explain resolution. Every sentence serves a clear purpose with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (13 parameters, output schema exists, no annotations), the description provides adequate high-level context. It covers intent types, resolution, and deprecation. However, it omits any mention of the output schema or typical response structure, and could include a brief usage example for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already thoroughly documents each parameter. The description adds value by explaining the high-level intent concept and deprecation of extract_text, which enriches understanding beyond the schema. It does not redundantly repeat parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Execute a high-level intent that auto-resolves to the correct library keyword.' It lists valid intents and explains resolution based on the active session library, distinguishing it from sibling tools like execute_step which likely handle lower-level instructions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool by enumerating valid intents (navigate, click, fill, etc.) and explicitly deprecates extract_text in favor of extract. However, it does not explicitly state when not to use it or compare to alternatives like execute_step or execute_batch, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect or control attach bridge configuration.
| Name | Required | Description | Default |
|---|---|---|---|
| action | No | One of: - "status" (default): Check bridge configuration and health - "stop": Send stop command to bridge (sets stop flag) - "cleanup"/"clean": Clean expired sessions and check bridge health - "reset"/"reconnect": Stop bridge and clean all local sessions - "disconnect_all"/"terminate"/"force_stop": Force stop bridge and terminate all | status |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions 'inspect or control' but does not detail side effects, required permissions, or what happens with each action (e.g., stop vs reset). Behavioral traits like destructiveness or rate limits are not disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence without wasted words. However, it is perhaps overly terse and lacks structure to guide the agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 11 enum actions and an output schema (not displayed), the description is insufficient. It does not explain what the tool returns or how to interpret results, leaving gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already includes a description for the action parameter. The tool description adds no additional meaning beyond what the schema provides, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Inspect or control attach bridge configuration,' which gives a general idea of the tool's purpose but is somewhat vague. It does not specify what 'attach bridge' refers to, and among sibling tools there is no direct alternative for comparison, but the purpose is not precise enough to distinguish clearly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 execute_step or manage_session. The description lacks any context about prerequisites or situations that warrant its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect or reload library plugins.
| Name | Required | Description | Default |
|---|---|---|---|
| action | No | One of "list", "reload", or "diagnose". | list |
| plugin_name | No | Plugin name when action="diagnose". |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It only mentions 'inspect or reload', omitting side effects (e.g., reload modifies state) and does not explain the 'diagnose' action or output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise but loses necessary information about the three actions. While front-loaded, it is too brief for a tool with multiple actions and parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and multiple actions, the description fails to mention the 'diagnose' action or the output. It is incomplete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no extra meaning beyond the schema; it does not elaborate on parameters or actions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool inspects or reloads library plugins, which is clear but not fully specific (inspect could mean list or diagnose). It distinguishes from sibling tools as no other tool mentions plugins.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like check_library_availability or get_keyword_info. The description lacks context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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")| Name | Required | Description | Default |
|---|---|---|---|
| args | No | ||
| alias | No | ||
| scope | No | suite | |
| action | Yes | ||
| keyword | No | ||
| profile | No | ||
| scenario | No | ||
| template | No | ||
| libraries | No | ||
| test_name | No | ||
| test_tags | No | ||
| variables | No | ||
| model_name | No | ||
| model_tier | No | ||
| session_id | No | ||
| test_setup | No | ||
| test_status | No | pass | |
| library_name | No | ||
| test_message | No | ||
| tool_profile | No | ||
| resource_path | No | ||
| test_teardown | No | ||
| test_documentation | No | ||
| variable_file_path | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Recommend libraries for a scenario or generate/merge sampling prompts.
WHEN TO USE THIS TOOL:
IMMEDIATELY after analyze_scenario, before execute_step
When you encounter "No keyword with name" errors
To discover which libraries provide needed functionality
This tool analyzes scenario text and suggests relevant libraries, saving you from guessing which libraries to import.
| Name | Required | Description | Default |
|---|---|---|---|
| k | No | Number of samples to request when mode="sampling_prompt" (defaults to 4). | |
| mode | No | "direct", "sampling_prompt", or "merge_samples". | direct |
| context | No | Context such as "web", "mobile", or "api". Defaults to "web". | web |
| samples | No | Sampled recommendations to merge when mode="merge_samples". | |
| scenario | Yes | Natural-language description of the task to automate. | |
| session_id | No | Optional session id to align recommendations with an existing session. | |
| include_keywords | No | When True, include a compact keyword list (names only) for the top recommendation. | |
| apply_search_order | No | When True, applies recommended order to the session. | |
| check_availability | No | When True, checks installability/presence of suggested libs. | |
| use_llm_refinement | No | When True, uses LLM via ctx.sample() to refine recommendations. | |
| available_libraries | No | Optional pre-fetched library metadata to use instead of registry defaults. | |
| max_recommendations | No | Maximum libraries to return (direct mode). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains the tool recommends libraries and generates/merges sampling prompts, but does not disclose side effects, permissions, idempotency, or rate limits. The mention of 'saves you from guessing' hints at behavior but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a one-line summary, then a 'WHEN TO USE' section with bullet points. It is concise yet informative, with no redundant or unnecessary sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (12 parameters, many siblings), the description does a good job covering the main purpose and usage context. It explains the tool's role in the workflow and mentions external triggers. An output schema exists, so return values are covered. Minor gap: no mention of other use cases or limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add significant meaning to individual parameters beyond what's in the schema. The 'WHEN TO USE' section is about usage, not parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Recommend libraries for a scenario or generate/merge sampling prompts.' It also tells the agent it helps discover libraries, which distinguishes it from sibling tools like analyze_scenario (which analyzes but does not recommend).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'IMMEDIATELY after analyze_scenario, before execute_step' and 'When you encounter "No keyword with name" errors'. This gives clear context, though it lacks explicit when-not-to-use alternatives; but the positive guidance is strong enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resume a failed batch from its failure point, optionally inserting fix steps.
After execute_batch returns status=FAIL with a batch_id, call this to:
Re-run the failed step (with optional fix_steps injected before it)
Continue executing remaining steps from the original batch
| Name | Required | Description | Default |
|---|---|---|---|
| batch_id | Yes | The batch_id from a failed execute_batch response. | |
| fix_steps | No | Optional steps to execute before retrying the failed step. Same format as execute_batch steps. | |
| timeout_ms | No | Override remaining timeout budget (uses original if omitted). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains the core behavior (resuming from failure, re-running, injecting steps) but lacks details on idempotency, side effects, authorization requirements, or error handling beyond the basic flow. The behavior is clear enough for an agent to avoid misuse.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short paragraphs: first a one-liner summary, second a concise bullet list of actions. Every sentence is informative, no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of resuming a batch with retry and fix steps, the description covers the main workflow and references execute_batch. It does not explain edge cases (e.g., if fix_steps fail) but the output schema exists to document return values. Minor gap for a tool that modifies state.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value by explaining the context: batch_id comes from failed execute_batch, fix_steps follow the same format, timeout_ms overrides the original. This clarifies usage beyond the schema's basic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it resumes a failed batch from its failure point, with optional fix steps. It uses specific verbs ('resume', 're-run', 'continue') and distinguishes itself from siblings like 'execute_batch' by explicitly referencing the failure scenario.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use: after execute_batch returns status=FAIL with a batch_id. It outlines the actions taken (re-run failed step, inject fix steps, continue remaining). However, it does not explicitly state when not to use or mention alternatives beyond the implied sequence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate or execute a Robot Framework suite.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | "dry"/"validate" for dry run; "full" to execute. Defaults to "full". | full |
| session_id | No | Session containing steps to build/execute; optional if suite_file_path is given. | |
| output_level | No | Response verbosity ("minimal", "standard", "detailed"). | standard |
| suite_file_path | No | Path to an existing .robot file to validate/execute. | |
| include_warnings | No | Whether to include warnings in validation output. | |
| validation_level | No | Dry-run validation depth ("minimal", "standard", "strict"). Default "standard". | standard |
| execution_options | No | RF execution options (variables, tags, loglevel, etc.). For ``suite_file_path`` with dry/validate mode, these are forwarded to Robot (e.g. ``variables``, ``include_tags``, ``exclude_tags``, ``test`` / ``tests``, ``pythonpath``, ``loglevel``). Subprocess cap: ``dry_run_timeout`` (preferred), ``dryrun_timeout``, or ``timeout`` (seconds); default comes from config ``DRY_RUN_TIMEOUT``. | |
| capture_screenshots | No | Enable screenshot capture on failures (if supported). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden for behavioral disclosure. It mentions validate/execute modes but omits side effects, permissions, rate limits, or error handling, leaving significant gaps for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the verb and resource. Every word earns its place, though a bit more structure could improve scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite 100% schema coverage and an output schema, the description is too brief for a tool with 8 parameters and nested objects. It does not explain mode differences, input relationships, or expected behavior beyond a summary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing detailed descriptions for all 8 parameters. The tool description itself adds little beyond stating the tool's purpose, so the schema carries the weight. Baseline score 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool validates or executes a Robot Framework suite, using specific verbs and resource. However, it does not differentiate from siblings like build_test_suite or execute_batch, which are related but distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as execute_step or execute_batch. The description does not specify prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set explicit library search order for keyword resolution.
| Name | Required | Description | Default |
|---|---|---|---|
| libraries | Yes | Library names in priority order (highest first). | |
| session_id | No | Session to apply the search order to. | default |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose side effects, scope (e.g., session persistence), or behavior when libraries are missing. Relies entirely on schema for parameter meaning.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no fluff, but could be slightly more descriptive without losing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema, description does not need return details. However, it lacks context on whether order is appended or replaced, error handling, or immediate effect. Among 18 siblings, more guidance is warranted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds no extra meaning beyond what is in the schema property descriptions (library priority order and session).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool sets an explicit library search order for keyword resolution, which is specific and matches the name. However, it does not differentiate from siblings like manage_library_plugins.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as manage_library_plugins or recommend_libraries. No context on prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Capture a screenshot of the current UI for VISUAL validation (change: visual-inspection-guidance).
Token-cheap by DEFAULT: saves the screenshot to disk and returns the PATH as text — a multimodal agent WITH file access reads that file on demand for checks the DOM/ARIA can't do (canvas/image text, layout/overlap, obscured elements, color, charts). Call get_locator_guidance(library="visual") for when to use it.
Set return_image=true ONLY if your model is multimodal AND cannot read the saved file (e.g. a hosted/remote MCP): the response then includes an image content block. This requires ROBOTMCP_SCREENSHOT_MODE to allow images (image|auto); text-only deployments (mode=file, the default) always return just the path so a text-only model is never sent unsupported image content.
Works across Browser/SeleniumLibrary/AppiumLibrary/PlatynUI (uses the session's screenshot keyword). Degrades cleanly if capture fails.
| Name | Required | Description | Default |
|---|---|---|---|
| filename | No | ||
| session_id | Yes | ||
| return_image | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description fully discloses behavior: default saves to disk and returns path, mode-dependent image return, degradation on failure, and cross-library support. This is comprehensive transparency for a mutable tool without annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured and front-loaded with purpose. While slightly verbose, each sentence adds unique value (use cases, parameter logic, mode details). Minor penalty for length but still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description explains both return formats (path string vs image block). Covers failure behavior, library compatibility, and references another guidance tool. Complete for a screenshot action with 3 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description carries full burden. It explains filename (optional, implied), session_id (required), and return_image with detailed context on when to use true vs false, including mode constraints—far beyond what the schema alone provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool captures a screenshot for visual validation and explicitly lists use cases where DOM/ARIA checks are insufficient (canvas/image text, layout, overlap, color). This distinguishes it from sibling tools like execute_step or get_locator_guidance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: when to use (visual validation), when to set return_image=true (multimodal models unable to read saved file), and references get_locator_guidance('visual') for deeper decision-making. Also warns about text-only deployments not supporting image content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.35.0analyze_scenariobuild_test_suitecheck_library_availabilityexecute_batchexecute_flowexecute_stepfind_keywordsget_keyword_infoget_locator_guidanceget_session_stateintent_actionmanage_attachmanage_library_pluginsmanage_sessionrecommend_librariesresume_batchrun_test_suiteset_library_search_ordervisual_checkEach tool has a clearly distinct purpose, from analysis to execution to session management. Even similar-sounding tools like find_keywords and get_keyword_info are differentiated by their descriptions (discovery vs. documentation).
All tool names follow a consistent verb_noun pattern with underscores, such as execute_step, manage_session, build_test_suite. There is no mixing of conventions or chaotic naming.
With 19 tools, the set is comprehensive but slightly on the higher end. However, each tool serves a specific function in the Robot Framework workflow, so the count is justified and not excessive.
The tool surface covers the full lifecycle: scenario analysis, library management, keyword discovery, execution (single, batch, flow, resume), state inspection, test suite building, running, visual validation, and high-level intents. No obvious gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
MCP server for building and testing AI agents with multi-model experimentation and insights.
MCP server for AI access to SmartBear tools, including BugSnag, Reflect, Swagger, PactFlow, QTM4J.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to control Unreal E…
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