RobotMCP

Overview Schema Source Related Servers Discussions Admin

intent_action

Execute high-level actions like click, fill, navigate, or extract, automatically mapping them to the correct keyword for the active automation library.

Instructions

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).

Input Schema

TableJSON Schema

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"). REQUIRED for navigate/click/fill/hover/select/assert_visible/wait_for. Only optional for extract with mode="url" or mode="title". Do not pass the string "null"/"None" — that counts as no target and the call is rejected with the parameter named.
`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. Pass the session_id returned by analyze_scenario or manage_session(action="init") — the session that has your libraries loaded. If omitted, it is inferred ONLY when exactly one session has libraries (the response then carries a "session_note" saying which was used); with several loaded sessions the call is rejected rather than guessed at, and "default" is used only when it is genuinely the loaded one. Omitting it does NOT silently target the session you just created.
`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.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.36.0Sep 26, 2026

changedInput schema / properties / session_id / description

Previous value: -"Session to execute against (uses default if not provided)"New value: +"Session to execute against. Pass the session_id returned by\nanalyze_scenario or manage_session(action=\"init\") — the session that has\nyour libraries loaded. If omitted, it is inferred ONLY when exactly one\nsession has libraries (the response then carries a \"session_note\" saying\nwhich was used); with several loaded sessions the call is rejected rather\nthan guessed at, and \"default\" is used only when it is genuinely the\nloaded one. Omitting it does NOT silently target the session you just\ncreated."

changedInput schema / properties / target / description

Previous value: -"Locator or URL (e.g. \"#submit\", \"text=Login\", \"https://example.com\"). Optional for extract mode=\"url\"/mode=\"title\"."New value: +"Locator or URL (e.g. \"#submit\", \"text=Login\", \"https://example.com\").\nREQUIRED for navigate/click/fill/hover/select/assert_visible/wait_for.\nOnly optional for extract with mode=\"url\" or mode=\"title\".\nDo not pass the string \"null\"/\"None\" — that counts as no target and the\ncall is rejected with the parameter named."

First observedv0.35.0Jul 29, 2026

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description carries the behavioral disclosure burden. It reveals that intent resolution depends on the active library, that extract_text is deprecated and will be removed, and that extract surfaces extracted_value. It does not explicitly warn about side effects of mutating commands or failure modes, but the intent names and 'Execute' wording make the action-oriented behavior reasonably clear.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose in the first sentence, then organized into a concise intent list and a clearly scoped deprecation note. Every sentence earns its place; there is no filler or redundant restating of the tool name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given a complex 13-parameter tool with 100% schema coverage and an output schema, the description provides sufficient context: the core operation, valid intents, deprecation behavior, and library-resolution mechanism. It does not need to repeat parameter constraints already in the schema, though a brief note about requiring a loaded session could have been included in the description itself.

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

Parameters4/5

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

Schema description coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining that extract_text is a deprecated alias for extract with mode='text', that extract is the canonical mode-aware getter, and that extract surfaces extracted_value at the top level. This is meaningful semantic enrichment, particularly around enum choices, warranting a 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Execute a high-level intent that auto-resolves to the correct library keyword.' It enumerates the accepted intents (navigate, click, fill, etc.), and the phrase 'auto-resolves to the correct library keyword' distinguishes this from low-level keyword-execution siblings like execute_step or find_keywords. An agent can tell exactly what the tool is for without opening the schema.

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

Usage Guidelines4/5

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

The description gives clear contextual guidance: it lists valid intents, notes library resolution based on the active session library, and explicitly deprecates extract_text in favor of extract. It does not, however, explicitly contrast this tool with alternatives like execute_flow, execute_batch, or execute_step, nor state when not to use it, so it stops short of a 5.

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