Feature Request: MCP Server Support for AI Assistant Integration

[mikeleppane]

Summary

Add an MCP (Model Context Protocol) server to enable AI assistants to lint and fix Robot Framework files conversationally.

What is MCP?

Model Context Protocol is an open standard by Anthropic that lets AI assistants connect to external tools. It's gaining adoption across AI coding tools.

Proposed Functionality

Expose Robocop capabilities as MCP tools:

• robocop_lint - Run linting on files/directories
• robocop_format - Format Robot Framework code
• robocop_explain_rule - Get rule explanations

User Experience

Users could tell their AI assistant:

"Lint my Robot Framework tests and fix the errors"

The AI would invoke Robocop, interpret violations, apply fixes, and verify—all in one flow.

[bhirsz]

I agree we should work towards better integration with AI. How does it align with https://github.com/aaltat/robocop-mcp ? It was recently created by one of our users. Though having it inside robocop may be better as AI may pick it up directly.

There is also #1499 proposal with my be connected as well.

[mikeleppane]

Yeah, I totally forgot that there was this robocop-mcp project. However, we should consider whether this should be directly integrated into robocop project. On a high level it could be something like this:

Structure

src/robocop/
├── mcp/                          # NEW: MCP server package
│   ├── __init__.py               # Package init, version
│   ├── server.py                 # FastMCP server setup & entry point
│   └── tools.py                  # Tool definitions (lint, format, list-rules, etc.)

Dependencies

[project.optional-dependencies]
mcp = ["fastmcp>=2.0"]

[project.scripts]
robocop = "robocop.run:main"
robocop-mcp = "robocop.mcp.server:main"   # NEW entry point

Installation

pip install robotframework-robocop[mcp]

For first-party tooling like this mcp, in-project with optional dependency is the clean pattern.

[mikeleppane]

In addition, if this is integrated into the project, MCP has direct access to the (latest) rules, which it can use to auto-fix problems. So, you don't need to maintain a separate catalog of Markdown files for how to fix a particular issue.

[mikeleppane]

I would be happy to implement this if you see the benefit of adding this to the project. Actually, it does not add very much content to the project and would be "directly" available for the users.

[bhirsz]

When robocop-mcp was initially created I was happy since we were missing MCP support and it covered it. But I have also noticed possible maintenance issuses. For each our release robocop-mcp also had to be updated. In case of breaking changes it also introduces a risk where we may omit some change (as its easier with two tools).

With upcoming fixers we could have hybrid approach where whatever has automatic fix would use it. And for the rest we could have AI friendly string instructions, embedded directly as attribute in rule.

So I'm for trying to implement it in robocop itself. Tagging @aaltat though to also hear about his opinion (since it does rival his project).

[aaltat]

Well, I think this does not have clean winner in either direction. I understand the user need to get everything as one package, but it brings it own complexity.

Pros of join

• It will avoid creating fixes for rules in two places. Although this is pretty minor thing and one which can be solved in many different ways other than joining.
• Rules, well, robocop-mcp will query rules from robocop which is installed. So if there is new/changed/deleted rules, just updating robocop is enough. I see this as solved problem.
• One service to do all

Cons of join

• I actually now do quite a lot manual testing, which is bad and I should solve it, before I release new version of robocop-mcp. Reason being that different LLM behave differently and because LLM responses contains randomness, one can not just assert that LLM does a right thing. There are different solutions to this problem, but involves some research which would be good in this case and paying some money to run a LLM somewhere in cloud.
• Complexity, although doing the MCP server for this purpose was not hard, it adds extra complexity for the robocop. The architecture can be solved, but testing can be tricky thing.

Pros of separation

• Each project has their own clear focus. robocop focus on robotframework test data, fixing and reporting stuff on based on rules. robocop-mcp is addition on top of robocop, which provides agent capabilities for easier fixing for errors in test data.

Cons of separation

• From user perspective the current situation is not perfect. The is clear reason why mcp server should be part of robocop and not a separate project.

Third solution

As an easy and short term workaround, robocop-mcp could be optional dependency for robocop and it can be installed with: pip install robotframework-robocop[mcp].

Decision

Well, I am actually unsure which would be best way to turn. From user perspective joining the projects makes sense and I fully agree on the idea. But it comes with its own complexity and will definitely have a cost (money and time vice) @bhirsz are you coming to https://www.robocon.io/ ? If you are should we discuss there?

[bhirsz]

Edit. I think the post I am replying to disappeared, but leaving the reply.

I also wasn't sure but I do remember why I merged robotidy and robocop and it aligns with many above pros/cons. My question was more on emotional level (interferring with someone baby :)) rather on logical level. Because I knew that once it was asked, we would get MCP inside soon. And I was right as I just released 7.1 with internal MCP server.

Let's observe and see how it works out then, if any solution is clearly better or not. Unfortunately my skills in the area are bit outdated and I'm catching up so I couldn't provide solid decision in solutions anyway.

I wish to, and I'm trying to negotiate with the company. I am contractor so I would need to take absence leave and I am stingy about that pay :) But I really want to finally participate in the conference in person.

[aaltat]

I did peak in the code and I understand your goal for it. It covers more robocop features or would be better word be, it is more versatile. robocop-mcp is to solves one problem only: if there plenty of errors, how not overwhelm LLM context and prioritize what is fixed first. I think the ideal solution is joining the two. But now I am off to bed