feat (backend): Add support for MCP servers natively via `CodeActAgent` #7637

ducphamle2 · 2025-04-01T19:56:18Z

This change is worth documenting at https://docs.all-hands.dev/
[] Include this change in the Release Notes. If checked, you must provide an end-user friendly description for your change below

End-user friendly description of the problem this fixes or functionality that this introduces.

Add support for MCP servers via CodeActAgent

TODOs:

Write more tests
Fix to pass tests
Add documentation

Give a summary of what the PR does, explaining any non-trivial design decisions.

This PR enables arbitrary MCP server usage (mainly focused and tested with SSE MCP Servers) by:

Providing MCP servers in config.toml like below:

[mcp-sse]
mcp_servers = ["http://localhost:8000/sse"]

[mcp-stdio]
commands = ["npx"]
args = [["-y", "@oraichain/orai-mcp"]]

When an agent is initialized, it will first pick up the list of MCPs, and integrate them into its list of tools.
When a user request is received, the LLM picks the appropriate tool and forwards it to the runtime via the /execute_action endpoint.
The runtime server will connect with the matching MCP server and call it using the action.arguments
The MCP Server's response will be turned into a MCPObservation instance, and fed into the LLM messages again for the next step.

This design will allow arbitrary MCP servers to be integrated into OpenHands seamlessly without breaking the existing architecture. It will co-exist with the microagents, as two features are different by design.
We can customize how we handle MCP Observations, especially for browser-related MCPs like playwright-mcp.
Some potential limitations (should be addressed in different PRs):
Potential overlap with built-in tools. However, MCP servers can also have overlapping tool names, so this problem depends on the MCP Server devs, not particularly ours.
Need more tests.
No MCP Authentication yet. This can be made via a different PR.
Hasn't utilized the multi-agentic flow yet (different PR).

Link of any specific issues this addresses.

#5781
#7547

This is a different approach compared to this PR: #7620. I am more than happy to collaborate with @ryanhoangt to merge and re-use each other's code if possible.

frontend/src/types/action-type.tsx

ducphamle2 · 2025-04-02T05:51:18Z

Updating to pass the workflow tests

ryanhoangt

Thanks a lot for the contribution, I took a look at the PR and left some questions, the approach does make sense to me! The main concern from my side is there are a lot of new types being created, it'd be great if we could find a way to simplify them.

openhands/mcp/mcp_agent.py

openhands/agenthub/codeact_agent/function_calling.py

openhands/core/config/mcp_config.py

openhands/mcp/mcp_tool_collection.py

openhands/mcp/mcp_base.py

openhands/runtime/run_mcp.py

xingyaoww

This is awesome to see! Let me know if you need anything from my side to merge this PR!

Would love to use MCP directly to test sequential thinking: #7643

neubig

Hello! First, thanks a bunch for the contribution!

Just to clarify, this requires us to have an additional method for customization for MCP servers, right? This contrasts with the approach in #7620, which allows us to re-use our current method for customization, namely micro-agents.

Personally I would prefer keeping the user experience simple and not introduce an additional method of customization. But if there are benefits of this approach over the approach in #7620, I'd be happy to discuss them.

ducphamle2 · 2025-04-02T18:44:03Z

This is awesome to see! Let me know if you need anything from my side to merge this PR!

Would love to use MCP directly to test sequential thinking: #7643

@xingyaoww I'm not entirely familiar with the config flow from the frontend -> backend yet. If possible, users can choose their MCP servers via the frontend, like the LLM API Key, but we still keep the MCP config in the backend as a fallback. If you could help with that It would be great!

xingyaoww · 2025-04-02T19:02:40Z

@ducphamle2 sounds good! I think we can focus on getting the backend code that uses "config.toml" to work first, and then we can start adding it into the settings page.

I think this PR might be in good shape for merge after some comments from @ryanhoangt is addressed ❤️

xingyaoww · 2025-04-02T19:04:47Z

Personally I would prefer keeping the user experience simple and not introduce an additional method of customization. But if there are benefits of this approach over the approach in #7620, I'd be happy to discuss them.

@neubig Based on my understanding, I think this PR lays down the foundation work for getting the MCP server configured and having those actions executed. I think it is still feasible for us to do something similar to #7620 where we put some MCP config into some microagent, and pass those config along to backend setting? So we are not actually losing anything? WDYT?

ducphamle2 · 2025-04-02T19:11:09Z

Hello! First, thanks a bunch for the contribution!

Just to clarify, this requires us to have an additional method for customization for MCP servers, right? This contrasts with the approach in #7620, which allows us to re-use our current method for customization, namely micro-agents.

Personally I would prefer keeping the user experience simple and not introduce an additional method of customization. But if there are benefits of this approach over the approach in #7620, I'd be happy to discuss them.

More than happy to contribute! Yes, it is a different approach compared to using micro-agents.

I believe the main benefit of this approach is that the agents will decide when to use the MCP tools instead of explicitly stating how and when to trigger them via microagent knowledge.
We also don't need to have a mapping between microagents and MCP Servers.

We can also do like @xingyaoww said, by adding specific MCP servers for the microagent to use, which is a win-win imo

xingyaoww · 2025-04-02T19:17:34Z

I asked OpenHands to summarize some offline discussion I had with @neubig - hope it provide some context :)

Hi @ducphamle2 and everyone,

Thanks for the great work on this PR! I wanted to provide some context from our Slack discussion about the MCP integration approaches.

We've been discussing two different approaches for MCP integration:

@ryanhoangt's PR (Add support for MCP servers #7620) - Using microagents to call MCP tools via a custom meta-tool
This PR (feat (backend): Add support for MCP servers natively via CodeActAgent #7637) - Exposing MCP tools directly to the LLM as native tools

After discussion, we've decided to move forward with this PR's approach as it:

Treats MCP tools similar to built-in tools, which is how other MCP clients like Claude Desktop or Cursor use MCP servers
Makes it easier to add new tools like sequential thinking without changing much code
Gives the LLM more direct access to tools, potentially improving its ability to use them effectively

@neubig raised a concern about introducing an additional method of customization. I think we can address this by:

First getting the backend code for MCP working with minimal changes
Later, we can integrate this with the microagent system by having microagent configs feed into the MCP config

For next steps, I suggest we:

Clean up the code based on the review comments:
- Simplify the types and classes (use MCP SDK types where possible)
- Rename MCPAgent to avoid confusion with OpenHands agents
- Remove unused methods and files
- Add more robust error handling for function calls
- Remove MCP config from config.template.toml to avoid confusion (as @neubig suggested)
Keep the changes minimal for this initial integration
After this PR is merged, we can work on:
- Adding a frontend UI for configuring MCP servers
- Integrating with the microagent system
- Adding support for more MCP features like authentication

I'm excited to see this merged so we can start using tools like sequential thinking in OpenHands! Let me know if you need any help with the changes.

ducphamle2 · 2025-04-02T19:29:55Z

I asked OpenHands to summarize some offline discussion I had with @neubig - hope it provide some context :)

Hi @ducphamle2 and everyone,

Thanks for the great work on this PR! I wanted to provide some context from our Slack discussion about the MCP integration approaches.

We've been discussing two different approaches for MCP integration:

@ryanhoangt's PR (Add support for MCP servers #7620) - Using microagents to call MCP tools via a custom meta-tool

This PR (feat (backend): Add support for MCP servers natively via CodeActAgent #7637) - Exposing MCP tools directly to the LLM as native tools

After discussion, we've decided to move forward with this PR's approach as it:

Treats MCP tools similar to built-in tools, which is how other MCP clients like Claude Desktop or Cursor use MCP servers

Makes it easier to add new tools like sequential thinking without changing much code

Gives the LLM more direct access to tools, potentially improving its ability to use them effectively

@neubig raised a concern about introducing an additional method of customization. I think we can address this by:

First getting the backend code for MCP working with minimal changes

Later, we can integrate this with the microagent system by having microagent configs feed into the MCP config

For next steps, I suggest we:

Clean up the code based on the review comments:

Simplify the types and classes (use MCP SDK types where possible)

Rename MCPAgent to avoid confusion with OpenHands agents

Remove unused methods and files

Add more robust error handling for function calls

Remove MCP config from config.template.toml to avoid confusion (as @neubig suggested)

Keep the changes minimal for this initial integration

After this PR is merged, we can work on:

Adding a frontend UI for configuring MCP servers

Integrating with the microagent system

Adding support for more MCP features like authentication

I'm excited to see this merged so we can start using tools like sequential thinking in OpenHands! Let me know if you need any help with the changes.

Thank you for the acknowledgement and all the comments! We'll resolve the issues asap (in the next couple of days probably) so we can merge this PR, will let you know if I need help from your end!

xingyaoww

Awesome work! It is already SO much cleaner 🙏 Left a few nit / questions

openhands/core/setup.py

openhands/server/session/session.py

openhands/core/schema/action.py

bensheed · 2025-04-06T10:58:24Z

I am so excited for this feature!

enyst · 2025-04-06T11:21:16Z

It's an awesome feature and a lot of work going into it, thank you for doing this @ducphamle2 !

Is the PR ready for review again?

ducphamle2 · 2025-04-06T19:25:19Z

@enyst no problem, glad I could help!

Yes it is ready for another round. Im eager to get this PR merged, as me and my team are also actively implementing custom features using MCP on the repo

xingyaoww

Hey great work!

I take a look at this PR this afternoon and tried to:

revert some unnecessary change
merge from main
refactor MCPStdioConfig so we can define new tools in a cleaner way in config.toml
break mcp.py into multiple files so hopefully it make things cleaner

This new change would allow us to define tools like this in config.toml which looks slightly cleaner:

[mcp-sse]
mcp_servers = ["http://localhost:8000/sse"]

[mcp-stdio.tools]
filesystem = { command = "npx", args = ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/dir"] }
brave-search = {command = "docker", args = ["run", "-i", "--rm", "-e", "BRAVE_API_KEY", "mcp/brave-search"], env = {"BRAVE_API_KEY" = "xxx"}}

I put those changes into this PR: oraichain#8, which will merge into your branch (this PR). Feel free to take a look and LMK if you have any concerns!

One primary concern I have with existing implementation is that for stdio MCP tools, the backend assume we have the environment setup for it, but often time we don't (e.g., see log below, the docker/npx command failed - so the tool initialization also failed).

17:57:28 - openhands:ERROR: client.py:119 - Error connecting to npx: [Errno 2] No such file or directory: 'npx'
Traceback (most recent call last):
  File "/Users/xingyaow/Projects/All-Hands-AI/OpenHands/openhands/mcp/client.py", line 107, in connect_stdio
    await asyncio.wait_for(connection_task, timeout=timeout)
  File "/opt/homebrew/Caskroom/mambaforge/base/envs/oh/lib/python3.12/asyncio/tasks.py", line 520, in wait_for
    return await fut
           ^^^^^^^^^
  File "/Users/xingyaow/Projects/All-Hands-AI/OpenHands/openhands/mcp/client.py", line 129, in _connect_stdio_internal
    stdio_transport = await self.exit_stack.enter_async_context(
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/homebrew/Caskroom/mambaforge/base/envs/oh/lib/python3.12/contextlib.py", line 659, in enter_async_context
    result = await _enter(cm)
             ^^^^^^^^^^^^^^^^
  File "/opt/homebrew/Caskroom/mambaforge/base/envs/oh/lib/python3.12/contextlib.py", line 210, in __aenter__
    return await anext(self.gen)
           ^^^^^^^^^^^^^^^^^^^^^
  File "/Users/xingyaow/Library/Caches/pypoetry/virtualenvs/openhands-ai-wqN7FI_O-py3.12/lib/python3.12/site-packages/mcp/client/stdio.py", line 100, in stdio_client
    process = await anyio.open_process(
              ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/xingyaow/Library/Caches/pypoetry/virtualenvs/openhands-ai-wqN7FI_O-py3.12/lib/python3.12/site-packages/anyio/_core/_subprocesses.py", line 184, in open_process
    return await get_async_backend().open_process(
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/xingyaow/Library/Caches/pypoetry/virtualenvs/openhands-ai-wqN7FI_O-py3.12/lib/python3.12/site-packages/anyio/_backends/_asyncio.py", line 2552, in open_process
    process = await asyncio.create_subprocess_exec(
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/homebrew/Caskroom/mambaforge/base/envs/oh/lib/python3.12/asyncio/subprocess.py", line 224, in create_subprocess_exec
    transport, protocol = await loop.subprocess_exec(
                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/homebrew/Caskroom/mambaforge/base/envs/oh/lib/python3.12/asyncio/base_events.py", line 1743, in subprocess_exec
    transport = await self._make_subprocess_transport(
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/homebrew/Caskroom/mambaforge/base/envs/oh/lib/python3.12/asyncio/unix_events.py", line 211, in _make_subprocess_transport
    transp = _UnixSubprocessTransport(self, protocol, args, shell,
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/homebrew/Caskroom/mambaforge/base/envs/oh/lib/python3.12/asyncio/base_subprocess.py", line 36, in __init__
    self._start(args=args, shell=shell, stdin=stdin, stdout=stdout,
  File "/opt/homebrew/Caskroom/mambaforge/base/envs/oh/lib/python3.12/asyncio/unix_events.py", line 820, in _start
    self._proc = subprocess.Popen(
                 ^^^^^^^^^^^^^^^^^
  File "/opt/homebrew/Caskroom/mambaforge/base/envs/oh/lib/python3.12/subprocess.py", line 1026, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "/opt/homebrew/Caskroom/mambaforge/base/envs/oh/lib/python3.12/subprocess.py", line 1955, in _execute_child
    raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: 'npx'
  File "<frozen runpy>", line 198, in _run_module_as_main
  File "<frozen runpy>", line 88, in _run_code
  File "/Users/xingyaow/Projects/All-Hands-AI/OpenHands/openhands/core/cli.py", line 208, in <module>
    loop.run_until_complete(main(loop))
  File "/opt/homebrew/Caskroom/mambaforge/base/envs/oh/lib/python3.12/asyncio/base_events.py", line 674, in run_until_complete
    self.run_forever()
  File "/opt/homebrew/Caskroom/mambaforge/base/envs/oh/lib/python3.12/asyncio/base_events.py", line 641, in run_forever
    self._run_once()
  File "/opt/homebrew/Caskroom/mambaforge/base/envs/oh/lib/python3.12/asyncio/base_events.py", line 1986, in _run_once
    handle._run()
  File "/opt/homebrew/Caskroom/mambaforge/base/envs/oh/lib/python3.12/asyncio/events.py", line 88, in _run
    self._context.run(self._callback, *self._args)
  File "/Users/xingyaow/Projects/All-Hands-AI/OpenHands/openhands/core/cli.py", line 113, in main
    mcp_tools = await fetch_mcp_tools_from_config(config.mcp)
  File "/Users/xingyaow/Projects/All-Hands-AI/OpenHands/openhands/mcp/utils.py", line 109, in fetch_mcp_tools_from_config
    mcp_clients = await create_mcp_clients(
  File "/Users/xingyaow/Projects/All-Hands-AI/OpenHands/openhands/mcp/utils.py", line 73, in create_mcp_clients
    await client.connect_stdio(
  File "/Users/xingyaow/Projects/All-Hands-AI/OpenHands/openhands/mcp/client.py", line 119, in connect_stdio
    logger.error(f'Error connecting to {command}: {str(e)}')
  File "/opt/homebrew/Caskroom/mambaforge/base/envs/oh/lib/python3.12/logging/__init__.py", line 1568, in error
    self._log(ERROR, msg, args, **kwargs)
  File "/opt/homebrew/Caskroom/mambaforge/base/envs/oh/lib/python3.12/logging/__init__.py", line 1684, in _log
    self.handle(record)

17:57:28 - openhands:INFO: utils.py:79 - Connected to MCP server via stdio with command npx
17:57:28 - openhands:INFO: utils.py:68 - Initializing MCP tool [brave-search] for [docker] with stdio connection...
17:57:28 - openhands:ERROR: client.py:119 - Error connecting to docker: [Errno 2] No such file or directory: 'docker'
Traceback (most recent call last):
  File "/Users/xingyaow/Projects/All-Hands-AI/OpenHands/openhands/mcp/client.py", line 107, in connect_stdio
    await asyncio.wait_for(connection_task, timeout=timeout)
  File "/opt/homebrew/Caskroom/mambaforge/base/envs/oh/lib/python3.12/asyncio/tasks.py", line 520, in wait_for
    return await fut
           ^^^^^^^^^
  File "/Users/xingyaow/Projects/All-Hands-AI/OpenHands/openhands/mcp/client.py", line 129, in _connect_stdio_internal
    stdio_transport = await self.exit_stack.enter_async_context(
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/homebrew/Caskroom/mambaforge/base/envs/oh/lib/python3.12/contextlib.py", line 659, in enter_async_context
    result = await _enter(cm)
             ^^^^^^^^^^^^^^^^
  File "/opt/homebrew/Caskroom/mambaforge/base/envs/oh/lib/python3.12/contextlib.py", line 210, in __aenter__
    return await anext(self.gen)
           ^^^^^^^^^^^^^^^^^^^^^
  File "/Users/xingyaow/Library/Caches/pypoetry/virtualenvs/openhands-ai-wqN7FI_O-py3.12/lib/python3.12/site-packages/mcp/client/stdio.py", line 100, in stdio_client
    process = await anyio.open_process(
              ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/xingyaow/Library/Caches/pypoetry/virtualenvs/openhands-ai-wqN7FI_O-py3.12/lib/python3.12/site-packages/anyio/_core/_subprocesses.py", line 184, in open_process
    return await get_async_backend().open_process(
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/xingyaow/Library/Caches/pypoetry/virtualenvs/openhands-ai-wqN7FI_O-py3.12/lib/python3.12/site-packages/anyio/_backends/_asyncio.py", line 2552, in open_process
    process = await asyncio.create_subprocess_exec(
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/homebrew/Caskroom/mambaforge/base/envs/oh/lib/python3.12/asyncio/subprocess.py", line 224, in create_subprocess_exec
    transport, protocol = await loop.subprocess_exec(
                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/homebrew/Caskroom/mambaforge/base/envs/oh/lib/python3.12/asyncio/base_events.py", line 1743, in subprocess_exec
    transport = await self._make_subprocess_transport(
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/homebrew/Caskroom/mambaforge/base/envs/oh/lib/python3.12/asyncio/unix_events.py", line 211, in _make_subprocess_transport
    transp = _UnixSubprocessTransport(self, protocol, args, shell,
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/homebrew/Caskroom/mambaforge/base/envs/oh/lib/python3.12/asyncio/base_subprocess.py", line 36, in __init__
    self._start(args=args, shell=shell, stdin=stdin, stdout=stdout,
  File "/opt/homebrew/Caskroom/mambaforge/base/envs/oh/lib/python3.12/asyncio/unix_events.py", line 820, in _start
    self._proc = subprocess.Popen(
                 ^^^^^^^^^^^^^^^^^
  File "/opt/homebrew/Caskroom/mambaforge/base/envs/oh/lib/python3.12/subprocess.py", line 1026, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "/opt/homebrew/Caskroom/mambaforge/base/envs/oh/lib/python3.12/subprocess.py", line 1955, in _execute_child
    raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: 'docker'
  File "<frozen runpy>", line 198, in _run_module_as_main
  File "<frozen runpy>", line 88, in _run_code
  File "/Users/xingyaow/Projects/All-Hands-AI/OpenHands/openhands/core/cli.py", line 208, in <module>
    loop.run_until_complete(main(loop))
  File "/opt/homebrew/Caskroom/mambaforge/base/envs/oh/lib/python3.12/asyncio/base_events.py", line 674, in run_until_complete
    self.run_forever()
  File "/opt/homebrew/Caskroom/mambaforge/base/envs/oh/lib/python3.12/asyncio/base_events.py", line 641, in run_forever
    self._run_once()
  File "/opt/homebrew/Caskroom/mambaforge/base/envs/oh/lib/python3.12/asyncio/base_events.py", line 1986, in _run_once
    handle._run()
  File "/opt/homebrew/Caskroom/mambaforge/base/envs/oh/lib/python3.12/asyncio/events.py", line 88, in _run
    self._context.run(self._callback, *self._args)
  File "/Users/xingyaow/Projects/All-Hands-AI/OpenHands/openhands/core/cli.py", line 113, in main
    mcp_tools = await fetch_mcp_tools_from_config(config.mcp)
  File "/Users/xingyaow/Projects/All-Hands-AI/OpenHands/openhands/mcp/utils.py", line 109, in fetch_mcp_tools_from_config
    mcp_clients = await create_mcp_clients(
  File "/Users/xingyaow/Projects/All-Hands-AI/OpenHands/openhands/mcp/utils.py", line 73, in create_mcp_clients
    await client.connect_stdio(
  File "/Users/xingyaow/Projects/All-Hands-AI/OpenHands/openhands/mcp/client.py", line 119, in connect_stdio
    logger.error(f'Error connecting to {command}: {str(e)}')
  File "/opt/homebrew/Caskroom/mambaforge/base/envs/oh/lib/python3.12/logging/__init__.py", line 1568, in error
    self._log(ERROR, msg, args, **kwargs)
  File "/opt/homebrew/Caskroom/mambaforge/base/envs/oh/lib/python3.12/logging/__init__.py", line 1684, in _log
    self.handle(record)

I'm start to think if we can simplify the implementation a lot if we:

stop support stdio-based server
and use tools like https://github.com/supercorp-ai/supergateway to convert any studio to SSE server
But even this, I imagine we'll need to wait until the server is fully initialized before we can get the tool list, right?

xingyaoww · 2025-04-06T22:45:48Z

I think the main pain point is coming from: We need to know what the existing tools are BEFORE we initialize the runtime.

And if we want to support "mcp-stdio", it means we need to initialize the client first, which probably means we need to have stuff like "docker"/"npx" installed locally for the backend to use.

But lots of users are using OpenHands via docker run openhands - this means we need to configure "docker"/"npx" inside every OpenHands app docker we built, which doesn't seem realistic to me. Even if the user has npx/docker configured outside docker, they'll have to use Development workflow if they want the backend to use those stdio directly. This seems to require a lot of documentation and makes things overly complicated than they should, IMO.

I just tried https://github.com/supercorp-ai/supergateway locally and it seems to me that it is not super hard to use.

Maybe we can:

Only support SSE-based MCP
Add in documentation that user can use stdio MCP via tools like https://github.com/supercorp-ai/supergateway
This also allow us to simplify the config a lot
Also means better user experience, for example, user can just docker run OpenHands and provide a good SSE server endpoint point to host machine like http://host.docker.internal:8000/sse - and everything will just work out-of-box

We are just making an assumption that: the MCP SSE server should be ONLINE BEFORE the agent start. Which I don't think it is too bad?

xingyaoww · 2025-04-06T22:46:44Z

@ducphamle2 LMK what you think! I can also help with these changes by sending in PRs to your branch if that helps 🙏

ducphamle2 · 2025-04-07T01:36:36Z

@xingyaoww I agree with removing the stdio server!. Tbh, I have never been a fan of stdio-based MCPs. I always use SSE MCP cuz it is very like Plug and Play, and the MCP client doesn't have to care about the MCP's runtime environment. I included stdio because I thought you would prefer it like Claude Desktop / Cursor supporting both standards.

The MCP team is cooking a new upgrade for the SSE, which is Streamable HTTP -> people will mostly use it instead of stdio IMO.
Lemme take a look at your PR. Thank you so much for helping!

AtAFork · 2025-04-09T15:03:48Z

Quick thought/suggestion (although I don't know how difficult implementation of all this is):

A lot of the most popular MCP servers are Stdio and I think a lot of folks won't use open hands if they have to jump through another hoop to get them working in that way. Is there a way to integrate this tool below? I've been using it, and it's a brilliant way to organize MCP servers. MetaMCP itself is an MCP, so I think you would just need to handle the case where that is Stdio.

https://github.com/metatool-ai/metatool-app

xingyaoww · 2025-04-09T15:08:41Z

Hey @AtAFork, i do plan to add smth like mcp-hub (https://github.com/ravitemer/mcp-hub) that will handle both stdio and sse that live inside the runtime container -- this allow us to support both stdio and sse while the backend only assume support for SSE.
This will probably happen in future PR -- stay tuned!

xingyaoww · 2025-04-09T15:12:47Z

And thanks for recommending metamcp! https://github.com/metatool-ai/mcp-server-metamcp?tab=readme-ov-file#using-as-an-sse-server did a quick look here, and it seems they also support some sort of "SSE server" - but that's dependent on the MetaMCP "app" which is probably overkill for the OpenHands usecase for now.

But with MCP+SSE implemented in this PR, user can just start their own metamcp server with SSE, and then directly plugin that SSE link -- so there's actually no need to support stdio for metaMCP

ducphamle2 · 2025-04-09T16:35:07Z

Wow thanks for sharing the metamcp and mcp hub! I have been waiting for the official mcp registry from the mcp team, but it is taking them a bit long

xingyaoww

These comments should be non-blocking! Otherwise this code LGTM!

I can approve this PR after I get this to work locally

openhands/mcp/utils.py

tests/test_run_mcp.py

…e-mcp

xingyaoww · 2025-04-09T17:41:40Z

@ducphamle2 Ok this is good to go!!

Just need this final PR into this branch oraichain#17 that:

Merge from main
Remove stale test
Refactor client connection in action_execution_client

I just tested locally, and things seem to be working!

[mcp]
mcp_servers = ["http://localhost:8000/sse"]

ducphamle2 · 2025-04-09T17:45:21Z

@xingyaoww merged!

xingyaoww

Super excited for this - Thanks a lot for your contribution @ducphamle2!

I imagine there are a few improvements we could make going forward:

simplify the MCP Config: we don't need another SSE config anymore since we only support SEE now
Improve the FE UI for MCP action/execution, as well as showing the current list of tools the agent has access to
Support STDIO by adding a default MCP server inside runtime

ducphamle2 · 2025-04-09T18:08:22Z

Thanks @xingyaoww, glad I could help!

On our main branch, we have improved the MCP UI significantly. If I have time, I will create another PR for that. If not, I trust that the OpenHands community can easily improve the UI!

…t` (All-Hands-AI#7637) Co-authored-by: trungbach <[email protected]> Co-authored-by: quangdz1704 <[email protected]> Co-authored-by: Xingyao Wang <[email protected]>

ducphamle2 changed the title ~~Add support for MCP servers via CodeActAgent~~ Add support for MCP servers natively via CodeActAgent Apr 1, 2025

enyst reviewed Apr 1, 2025

View reviewed changes

frontend/src/types/action-type.tsx Outdated Show resolved Hide resolved

ducphamle2 force-pushed the feat/pr-mcp-upstream branch 2 times, most recently from 93ea7a2 to 82e2500 Compare April 2, 2025 05:48

ducphamle2 changed the title ~~Add support for MCP servers natively via CodeActAgent~~ feat: Add support for MCP servers natively via CodeActAgent Apr 2, 2025

ducphamle2 changed the title ~~feat: Add support for MCP servers natively via CodeActAgent~~ feat (backend): Add support for MCP servers natively via CodeActAgent Apr 2, 2025

ryanhoangt reviewed Apr 2, 2025

View reviewed changes

xingyaoww reviewed Apr 2, 2025

View reviewed changes

xingyaoww mentioned this pull request Apr 2, 2025

Add search engine feature #7262

Closed

neubig reviewed Apr 2, 2025

View reviewed changes

ducphamle2 force-pushed the feat/pr-mcp-upstream branch from 2a76ff9 to eda6369 Compare April 2, 2025 19:21

ducphamle2 force-pushed the feat/pr-mcp-upstream branch from f66cf4d to a4fe4fe Compare April 3, 2025 05:23

xingyaoww reviewed Apr 3, 2025

View reviewed changes

openhands/core/setup.py Outdated Show resolved Hide resolved

openhands/server/session/session.py Outdated Show resolved Hide resolved

openhands/core/schema/action.py Show resolved Hide resolved

ducphamle2 force-pushed the feat/pr-mcp-upstream branch 2 times, most recently from a472380 to f78727b Compare April 6, 2025 02:51

xingyaoww reviewed Apr 6, 2025

View reviewed changes

ducphamle2 force-pushed the feat/pr-mcp-upstream branch from 930388b to ca7bd14 Compare April 7, 2025 01:47

xingyaoww and others added 6 commits April 8, 2025 14:51

simplify

23764a3

fix import

106cb36

refactor MCP config

bdf1a49

fix: remove mcp stdio & pass tests

f58bbf6

fix: change mcp config to 'mcp'

9f84f61

chore: move mcp tool call to execution client instead of server

385f197

ducphamle2 force-pushed the feat/pr-mcp-upstream branch from 9d006ca to 385f197 Compare April 8, 2025 21:51

ducphamle2 added 2 commits April 8, 2025 14:55

chore: remove unused file

84dcf6e

fix: lint python

4183974

xingyaoww reviewed Apr 9, 2025

View reviewed changes

openhands/mcp/utils.py Outdated Show resolved Hide resolved

tests/test_run_mcp.py Outdated Show resolved Hide resolved

tests/test_run_mcp.py Outdated Show resolved Hide resolved

xingyaoww added 3 commits April 9, 2025 13:16

Merge commit '588b9f34be6596357fba5200513de1d2eaa847de' into xw/updat…

5e27f5a

…e-mcp

remove test run mcp

369a1ab

persist mcp client

e39dc8b

Merge pull request #17 from All-Hands-AI/xw/update-mcp

b66e04d

xingyaoww approved these changes Apr 9, 2025

View reviewed changes

xingyaoww enabled auto-merge (squash) April 9, 2025 18:23

xingyaoww disabled auto-merge April 9, 2025 19:52

xingyaoww enabled auto-merge (squash) April 9, 2025 19:52

xingyaoww merged commit 35d49f6 into All-Hands-AI:main Apr 10, 2025
15 of 18 checks passed

ryanhoangt mentioned this pull request Apr 10, 2025

Add support for MCP servers #7620

Closed

6 tasks

This was referenced Apr 13, 2025

Fix failures in Circle CI #7841

Closed

Allow us to use MCP servers to extend OpenHand's functionality #5781

Closed

feat (backend): Add support for MCP servers natively via CodeActAgent #7637

feat (backend): Add support for MCP servers natively via CodeActAgent #7637

Uh oh!

Conversation

ducphamle2 commented Apr 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

ducphamle2 commented Apr 2, 2025

Uh oh!

ryanhoangt left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

xingyaoww left a comment

Choose a reason for hiding this comment

Uh oh!

neubig left a comment

Choose a reason for hiding this comment

Uh oh!

ducphamle2 commented Apr 2, 2025

Uh oh!

xingyaoww commented Apr 2, 2025

Uh oh!

xingyaoww commented Apr 2, 2025

Uh oh!

ducphamle2 commented Apr 2, 2025

Uh oh!

xingyaoww commented Apr 2, 2025

I asked OpenHands to summarize some offline discussion I had with @neubig - hope it provide some context :)

Uh oh!

ducphamle2 commented Apr 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

I asked OpenHands to summarize some offline discussion I had with @neubig - hope it provide some context :)

Uh oh!

xingyaoww left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

bensheed commented Apr 6, 2025

Uh oh!

enyst commented Apr 6, 2025

Uh oh!

ducphamle2 commented Apr 6, 2025

Uh oh!

xingyaoww left a comment

Choose a reason for hiding this comment

Uh oh!

xingyaoww commented Apr 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

xingyaoww commented Apr 6, 2025

Uh oh!

ducphamle2 commented Apr 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

AtAFork commented Apr 9, 2025

Uh oh!

xingyaoww commented Apr 9, 2025

Uh oh!

xingyaoww commented Apr 9, 2025

Uh oh!

ducphamle2 commented Apr 9, 2025

Uh oh!

xingyaoww left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

xingyaoww commented Apr 9, 2025

Uh oh!

ducphamle2 commented Apr 9, 2025

feat (backend): Add support for MCP servers natively via `CodeActAgent` #7637

feat (backend): Add support for MCP servers natively via `CodeActAgent` #7637

ducphamle2 commented Apr 1, 2025 •

edited

Loading

ducphamle2 commented Apr 2, 2025 •

edited

Loading

xingyaoww commented Apr 6, 2025 •

edited

Loading

ducphamle2 commented Apr 7, 2025 •

edited

Loading