Robot Framework MCP Server

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
Most tools are clearly distinct by focusing on different test types (e.g., API integration, data-driven, performance monitoring), but there is notable overlap between 'create_advanced_selenium_keywords' and 'create_extended_selenium_keywords'—both generate Selenium-related keywords, which could confuse an agent about which to use for specific Selenium tasks. The descriptions help differentiate them slightly, but the boundaries are fuzzy.
Naming Consistency5/5
All tool names follow a consistent 'create_*' or 'validate_*' verb_noun pattern with snake_case, making them predictable and easy to parse. The naming convention is uniform across all eight tools, with no deviations in style or structure.
Tool Count4/5
With 8 tools, the count is reasonable and well-scoped for a Robot Framework code generation server, covering various test types and a validation tool. It's slightly on the higher side but not excessive, as each tool serves a distinct purpose in test creation, though some overlap exists.
Completeness3/5
The server covers code generation for multiple test scenarios (Selenium, API, data-driven, login, performance) and includes syntax validation, but there are notable gaps: it lacks tools for executing tests, managing test suites, or handling other common Robot Framework operations like variable management or reporting. This limits the workflow to creation-only, which agents might find incomplete for full test automation.
Average 3.4/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that the tool 'Returns .robot file content as text - does not execute,' which clarifies output format and non-execution behavior. However, it lacks details on permissions, rate limits, error handling, or whether it modifies any state. The description is adequate but misses deeper behavioral traits for a code generation 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 highly concise and front-loaded: it states the core purpose in the first clause and adds critical behavioral context in the second. Every sentence earns its place with no wasted words, making it efficient for an AI agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which covers return values), the description doesn't need to explain outputs. However, with 3 parameters, 0% schema coverage, and no annotations, the description is incomplete: it lacks parameter semantics and deeper behavioral context. It's minimally viable but has clear gaps for a code generation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds no information about parameters like 'base_url', 'endpoint', or 'method' beyond what the schema provides. The description mentions 'API integration test' but doesn't explain how parameters relate to test generation, leaving semantics unclear. This fails to compensate for the low coverage.
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's purpose: 'Generate Robot Framework API integration test code' with specific verb ('Generate') and resource ('Robot Framework API integration test code'). It distinguishes from siblings by focusing on API tests rather than Selenium, login, or syntax validation tools. However, it doesn't explicitly differentiate from 'create_data_driven_test' which might also involve API testing.
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 minimal usage guidance: it mentions the tool 'does not execute' the test, which is helpful context. However, it doesn't specify when to use this tool versus alternatives like 'create_data_driven_test' or 'create_performance_monitoring_test', nor does it provide prerequisites or typical scenarios for API integration testing.
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 behavioral disclosure. It states the tool 'Returns .robot file content as text - does not execute,' which clarifies it's a read-only generation tool (no execution or side effects) and specifies the output format. However, it lacks details on permissions, rate limits, error handling, or what happens if inputs are invalid. For a tool with no annotations, this is a minimal but adequate disclosure.
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 highly concise and well-structured in two sentences: the first states the purpose, and the second clarifies the output and non-execution behavior. Every sentence adds value without redundancy, making it front-loaded and efficient for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which should document return values) and no annotations, the description is moderately complete. It covers the core purpose and output format but lacks parameter details and usage context. For a code generation tool with one parameter, this is adequate but leaves gaps in parameter understanding and sibling differentiation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, and the tool description provides no information about parameters. It doesn't mention 'template_type' or explain its purpose, values, or impact on the generated code. With low schema coverage, the description fails to compensate, leaving the parameter undocumented and its semantics unclear.
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's purpose: 'Generate Robot Framework page object model code for login page.' It specifies the verb ('Generate'), resource ('page object model code'), and scope ('for login page'). However, it doesn't explicitly differentiate from sibling tools like 'create_login_test_case', which might also generate login-related code but for different purposes.
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 guidance on when to use this tool versus alternatives. It mentions 'does not execute' to clarify it's a code generation tool, but offers no context on prerequisites, when to choose it over other code generation siblings (e.g., 'create_login_test_case'), or any exclusions. This leaves the agent without usage direction.
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 behavioral disclosure. It adds value by specifying that it 'does not execute code' and returns a 'validation report as text,' which clarifies it's a read-only, non-destructive analysis tool. However, it doesn't cover aspects like error handling, performance limits, or authentication needs, leaving gaps in 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 highly concise and front-loaded, consisting of two clear sentences that directly state the tool's function and key behavioral trait. Every word earns its place, with no redundant or unnecessary information, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (syntax validation), no annotations, and an output schema (which likely handles return values), the description is partially complete. It covers the core purpose and non-execution behavior but lacks details on parameters, error cases, or integration with sibling tools, leaving room for improvement in overall context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, with one parameter 'robot_code' undocumented in the schema. The description adds no information about this parameter (e.g., format, examples, or constraints), failing to compensate for the schema's lack of detail. This leaves the parameter's meaning unclear beyond its name.
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's purpose: 'Validate Robot Framework syntax and provide suggestions.' It specifies the verb (validate), resource (Robot Framework syntax), and outcome (suggestions). However, it doesn't explicitly differentiate from sibling tools (e.g., creation tools), which are focused on generating tests rather than validating syntax, so it falls short of a perfect score.
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 by stating it 'does not execute code,' suggesting it's for static analysis rather than runtime testing. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., for syntax checking vs. creating tests with sibling tools) or any prerequisites, leaving usage context somewhat vague.
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 behavioral disclosure. It states the tool generates code and returns file content as text without execution, which clarifies it's a read-only generation tool (not a write/execution tool). However, it lacks details on permissions, rate limits, error handling, or what happens with invalid inputs. This provides basic transparency but leaves gaps for a mutation-like operation.
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 highly concise and well-structured in a single sentence. It front-loads the core purpose ('Generate Robot Framework data-driven test template code') and efficiently adds key details about the output format and non-execution behavior. Every word earns its place with no redundancy or fluff, making it easy to parse quickly.
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 moderate complexity (generating test code), no annotations, and an output schema present (which likely covers return values), the description is reasonably complete. It specifies the action, output format, and a key behavioral trait (no execution). However, it lacks details on prerequisites (e.g., file format requirements) and doesn't fully address parameter semantics, leaving some contextual gaps.
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?
The description adds no parameter-specific information beyond what the input schema provides. With 1 parameter and 0% schema description coverage, the schema only gives a title ('Test Data File'), default value, and type. The description doesn't explain the parameter's role (e.g., that 'test_data_file' is the source for data-driven tests), leaving semantics unclear. Baseline is 3 due to low parameter count, but it doesn't compensate for the coverage gap.
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's purpose: 'Generate Robot Framework data-driven test template code.' It specifies the verb ('Generate'), resource ('Robot Framework data-driven test template code'), and output format ('.robot file content as text'), distinguishing it from siblings like 'validate_robot_framework_syntax' or 'create_login_test_case'. However, it doesn't explicitly differentiate from all siblings (e.g., 'create_api_integration_test'), which prevents a perfect score.
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 guidance on when to use this tool versus alternatives. It mentions that it 'does not execute,' which hints at a limitation, but doesn't specify scenarios where this tool is appropriate (e.g., for generating test templates from data files) or when to choose other tools like 'create_advanced_selenium_keywords' or 'create_performance_monitoring_test'. Without explicit usage context or exclusions, the score is low.
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 of behavioral disclosure. It states the tool generates keywords and returns .robot file content as text without execution, which clarifies it's a read-only generation tool. However, it lacks details on potential constraints (e.g., rate limits, input validation), error handling, or what constitutes 'advanced' operations, leaving gaps in 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 highly concise and front-loaded, consisting of two clear sentences: one stating the purpose and another clarifying the output and non-execution behavior. Every sentence adds value without redundancy, making it efficient and well-structured.
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 has 0 parameters, 100% schema coverage, and an output schema exists (so return values are documented elsewhere), the description is reasonably complete. It covers the core purpose and output format. However, it could be more complete by defining 'advanced' operations or differentiating from siblings, but for a parameterless tool with good schema support, this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to compensate for any parameter gaps. A baseline of 4 is appropriate since no parameter information is required, and the description doesn't mislead about inputs.
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's purpose: 'Generate Robot Framework keywords for advanced Selenium operations.' It specifies both the verb ('Generate') and resource ('Robot Framework keywords'), and indicates the domain ('advanced Selenium operations'). However, it doesn't explicitly differentiate from sibling tools like 'create_extended_selenium_keywords' or 'create_login_test_case', which prevents a perfect score.
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 minimal usage guidance. It mentions that the tool 'Returns .robot file content as text - does not execute,' which implies it's for code generation rather than execution, but doesn't specify when to use this tool versus alternatives like 'create_extended_selenium_keywords' or 'create_api_integration_test'. No explicit when/when-not instructions or prerequisites are provided.
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 discloses that the tool generates code but does not execute it, which is useful behavioral context. However, it lacks details on potential limitations (e.g., output size, error handling), authentication needs, or rate limits. For a tool with zero annotation coverage, this is a moderate gap.
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 a single, well-structured sentence that efficiently conveys the tool's purpose, scope, and output format. Every word adds value, with no redundancy or fluff. It is front-loaded with key information and appropriately concise for a zero-parameter tool.
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 zero parameters, 100% schema coverage, and presence of an output schema (which handles return values), the description is reasonably complete. It explains what the tool does and the output format. However, it could improve by addressing when to use it versus siblings or noting any constraints, slightly limiting 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?
The tool has zero parameters, and the input schema has 100% description coverage (though empty). The description does not need to compensate for any parameter gaps. It appropriately focuses on the tool's function and output without unnecessary parameter details, earning a high baseline score.
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's purpose: generating extended Robot Framework keywords for specific domains (screenshots, performance monitoring, window management). It specifies the output format (.robot file content as text) and clarifies it does not execute the code. However, it doesn't explicitly differentiate from sibling tools like 'create_advanced_selenium_keywords' or 'create_performance_monitoring_test', which prevents a perfect score.
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 guidance on when to use this tool versus alternatives. With sibling tools like 'create_advanced_selenium_keywords' and 'create_performance_monitoring_test' available, there is no indication of when this tool is preferred, what prerequisites might exist, or any exclusions. This leaves the agent without context for selection.
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 provided, the description carries the full burden of behavioral disclosure. It states the tool generates code and returns file content without execution, which covers basic output behavior. However, it lacks details on permissions needed, error handling, rate limits, or whether the generation is deterministic or customizable beyond the parameters, leaving gaps for a mutation-like 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 front-loaded with the core purpose in the first sentence and adds a critical behavioral note in the second. Every sentence earns its place by clarifying functionality and output without redundancy, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which should cover return values), the description need not explain outputs. However, with no annotations and 0% schema description coverage for parameters, the description is incomplete for a code-generation tool with 4 parameters, as it lacks details on parameter meanings, usage constraints, or behavioral nuances beyond basic output.
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 0%, so the schema provides no parameter details. The description does not explain the parameters at all, failing to compensate for the coverage gap. However, with 4 parameters and no schema descriptions, the baseline is low, and the description adds no value beyond the schema, resulting in a minimal score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Generate Robot Framework test case code') and resource ('for login functionality'), distinguishing it from siblings like create_api_integration_test or create_performance_monitoring_test by focusing on login-specific test generation. It also specifies the output format ('complete .robot file content as text'), which further clarifies its purpose.
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 for generating login test code, but does not explicitly state when to use this tool versus alternatives like create_page_object_login or validate_robot_framework_syntax. It mentions 'does not execute the test,' which provides some context on limitations, but lacks guidance on prerequisites or specific scenarios for selection.
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 behavioral disclosure. It adds value by stating that it 'Returns complete .robot file content as text - does not execute,' which clarifies output format and non-execution behavior. However, it lacks details on permissions, rate limits, error handling, or other operational traits, leaving gaps in behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and front-loaded, consisting of two clear sentences: one stating the generation purpose and another specifying the output and non-execution behavior. Every sentence adds essential information without waste, making it efficient and well-structured for an AI agent.
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 (simple generation with no parameters), high schema coverage (100%), and presence of an output schema, the description is reasonably complete. It covers the core purpose and output format, though it could benefit from more behavioral context (e.g., error cases) and usage guidelines relative to siblings. The output schema likely handles return value details, reducing the need for description elaboration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%. The description does not need to add parameter semantics beyond the schema. A baseline score of 4 is appropriate as it avoids redundancy and focuses on the tool's purpose and output, which is sufficient given the absence of parameters.
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's purpose: 'Generate Robot Framework performance monitoring test code.' It specifies the verb ('Generate'), resource ('Robot Framework performance monitoring test code'), and output format ('.robot file content as text'). However, it does not explicitly differentiate from siblings like 'create_api_integration_test' or 'create_data_driven_test' in terms of performance monitoring vs. other test types, which prevents a score of 5.
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 guidance on when to use this tool versus alternatives. It mentions 'does not execute,' which hints at a non-execution behavior, but does not specify contexts, prerequisites, or exclusions compared to sibling tools like 'create_login_test_case' or 'validate_robot_framework_syntax.' This lack of usage context results in minimal guidance for an AI agent.
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:

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

Score Badge

Copy to your README.md:

[![robotframework-mcp MCP server](https://glama.ai/mcp/servers/sourcefuse/robotframework-mcp/badges/score.svg)](https://glama.ai/mcp/servers/sourcefuse/robotframework-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/sourcefuse/robotframework-mcp'

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