RobotMCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.35.0
Disambiguation5/5
Each 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).
Naming Consistency5/5
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.
Tool Count4/5
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.
Completeness5/5
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.
Average 3.8/5 across 19 of 19 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- 4 of 6 community issues answered or closed in the last 6 months
- 76 commits in the last 12 weeks
- Last stable release on July 24, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose3/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness3/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of 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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It comprehensively describes all actions, parameters, their effects, and return values. It notes that test_status and test_message are session tracking metadata and do not affect the generated .robot file, which is an important behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but well-structured with clear sections for workflows, actions, parameters, returns, and examples. Each action is listed with its parameters and aliases. While it could be more concise, the structure makes it easy to navigate and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool with 24 parameters and 10+ actions, the description is extremely thorough. It covers all actions, parameter details, return format, and provides multiple examples. The context signals indicate high complexity and low schema coverage, and the description fully compensates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It thoroughly explains each parameter for every action, including examples and usage context. For instance, it describes the scope parameter for set_variables, the template parameter for start_test, and the args parameter for add_data_row with a multi-line example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool manages session lifecycle with specific verbs like initialize, configure, and organize. It distinguishes itself from analyze_scenario by stating that manage_session is for explicit session ops on an existing session, while analyze_scenario creates the session. The purpose is unambiguous and well-differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use manage_session versus analyze_scenario, provides workflows for single and multi-test scenarios, and explicitly warns against calling action='init' right after analyze_scenario. It gives clear guidance on alternatives and appropriate contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![rf-mcp MCP server](https://glama.ai/mcp/servers/manykarim/rf-mcp/badges/card.svg)](https://glama.ai/mcp/servers/manykarim/rf-mcp)

Score Badge

Copy to your README.md:

[![rf-mcp MCP server](https://glama.ai/mcp/servers/manykarim/rf-mcp/badges/score.svg)](https://glama.ai/mcp/servers/manykarim/rf-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/manykarim/rf-mcp'

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