The short version: Reachy Mini's conversation app can now register public, Gradio-based Hugging Face Spaces as remote tools over MCP, adding stateless capabilities like search and weather. It is a software-architecture change, not a new physical capability; body controls stay local, and private or non-Gradio Spaces remain unsupported.
Reachy Mini, the small open robot from Pollen Robotics and Hugging Face, can now call tools hosted in public Hugging Face Spaces over the Model Context Protocol (MCP). The change is described in a Hugging Face blog post, "Adding MCP Tools to Reachy Mini," published June 3, 2026.
The important framing for TheMimic readers: this is not a new physical capability or a claim that Reachy Mini became a humanoid. It is a software architecture change. The robot keeps its local, trusted tools for moving its body, and gains a way to pull in shareable, hosted software capabilities — like weather lookups or web search — without rewriting the robot app.
What Hugging Face changed
According to the post, Reachy Mini's conversation app (reachy-mini-conversation-app) now supports remote tools hosted in Hugging Face Spaces and called over MCP, alongside its existing built-in tools and custom local tools.
Adding a remote tool is a single command. The post's example registers the weather canary Space by running reachy-mini-conversation-app tool-spaces add pollen-robotics/reachy-mini-weather-tool.
After that, starting reachy-mini-conversation-app makes the tool available to the model. The post also documents tool-spaces list and tool-spaces remove <owner/space-name> for managing registered Spaces, plus flags such as --profile <NAME> and --install-only.
Hugging Face names two public canary Spaces maintained by Pollen Robotics:
pollen-robotics/reachy-mini-search-toolpollen-robotics/reachy-mini-weather-tool
API metadata for both Spaces, checked June 4, 2026, shows they are public, built on the Gradio SDK, and tagged reachy-mini-tool, mcp, and mcp-server. The search tool Space reports lastModified of 2026-06-03T13:16:19Z and the weather tool Space 2026-06-03T13:16:12Z, per their Hugging Face API records for the search tool and weather tool.
Why this is different from a robot demo
A lot of robot announcements are about a new physical trick: a fresh grasp, a new gait, a longer autonomous run. This is not that. The change is in tool architecture, and it deliberately keeps two categories of capability apart.
The post describes three tool types now coexisting in the conversation app:
- Built-in robot tools — local and trusted. These include
move_head,dance,stop_dance,play_emotion,stop_emotion,head_tracking,camera, andidle_do_nothing. - Custom local tools — user-added tools living in the app's
external_tools/directory. - Remote MCP tools — capabilities hosted in public Spaces and reached over MCP.
The split matters. Anything that drives the robot's body — head pose, emotion clips, the camera — stays local. Remote tools are positioned for stateless capabilities such as search, weather, and lookups. Hugging Face states the remote tool keeps running in the Space itself, "so no code is downloaded onto your machine." That is a security-relevant design choice, but, as covered below, it is not the same as "remote tools are safe."
This separation echoes a pattern TheMimic has tracked elsewhere in robot software: high-level reasoning and tool calling are increasingly decoupled from validated, low-level robot control. See Gemini Robotics-ER 1.6 for a model-side version of the same idea, where reasoning and tool use sit above the control and safety layers rather than replacing them.
How profiles gate tool access
Reachy Mini's conversation app uses profiles to control behavior, and each profile is defined largely by two files:
instructions.txt— the prompt that guides the model's behavior.tools.txt— the list of enabled tool names.
The tools.txt file is the gatekeeper. Per the post, a remote tool is only active if its ID appears in the profile's tools.txt. If a tool name is not listed there, the model cannot call it, even if the Space is registered. That gives builders per-profile control over which capabilities are live in a given configuration.
Remote tools also get namespaced IDs to avoid collisions. The post shows the search Space's web-search tool resolving to an ID like pollen_robotics_reachy_mini_search_tool__search_web — the Space slug, then a double underscore, then the tool name. Two Spaces can expose a tool with the same short name without clashing.
What works today, and what does not
The post is explicit about scope. Treat the following as Hugging Face's stated support boundary, not as a general "MCP works on robots now" claim.
Supported today:
- Installing public, MCP-compatible Gradio Spaces by slug.
- Running multiple registered Spaces at once.
- Per-profile enablement through
tools.txt. - Namespaced remote tool IDs to prevent collisions.
- Backend-agnostic registration.
- No arbitrary local code download — remote tools execute in the Space.
Not supported:
- Private or authenticated Spaces.
- Non-Gradio Spaces.
- Arbitrary raw MCP URLs or non–Hugging Face MCP servers.
- Guaranteed parallel tool orchestration.
On that last point, the post advises that if deterministic orchestration matters for a use case, that logic should move from the prompt into code. In other words, leaning on the model to reliably sequence or parallelize tool calls is not guaranteed; teams that need ordering guarantees should write the orchestration explicitly.
Why TheMimic readers should care
For people building on small robots, the practical win is a supported, low-friction way to add current-information tools — weather, search, lookups — without forking or rewriting the robot's conversation app. A Space slug and a tools.txt entry is a much shorter path than packaging and shipping new local code to every robot.
It also clarifies the taxonomy, which matters for how TheMimic catalogs this space. Reachy Mini the robot, the conversation app that runs on it, and the MCP tool Spaces it can call are three separate things. The hardware does not change when you add a weather Space; you are extending the software agent layer that sits on top of it.
There is a broader pattern here, too: protocol-shaped extensibility is reaching small developer robots, not just large research platforms or simulation stacks. For the simulation-and-tooling side of robot software, see our coverage of NVIDIA Cosmos Predict 2.5. The common thread is that robot software is increasingly assembled from interoperable parts rather than monolithic, single-vendor stacks.
What to verify before relying on it
The design is reasonable, but builders should confirm the operational details before depending on it:
- Space uptime and endpoint behavior. The canaries run on modest hosted hardware. Check that the Space is up and the MCP endpoint responds before treating a tool as available in production.
- Latency and prompting. Remote calls add round trips. Test whether tool latency and the model's tool-selection prompting are acceptable for your interaction loop.
- Trust in third-party Spaces. Not downloading code locally reduces one risk, but it does not make an arbitrary Space trustworthy. You are still sending inputs to, and acting on outputs from, code you may not control. Evaluate the source and behavior of any Space you enable.
- Which profiles are actually enabled. On a real robot, confirm which profile is loaded and exactly what is in its
tools.txt, since that determines what the model can call.
FAQ
What is Reachy Mini MCP support?
It is the ability for Reachy Mini's conversation app to register public Hugging Face Spaces as remote tools and call them over the Model Context Protocol, alongside its built-in robot tools and any custom local tools.
Does this mean Reachy Mini can use any MCP server?
No. Hugging Face limits support to public, MCP-compatible Gradio Spaces exposing the standard endpoint. Private or authenticated Spaces, non-Gradio Spaces, arbitrary raw MCP URLs, and non–Hugging Face MCP servers are not supported.
Are remote tools downloaded onto the robot?
No. The post states the tool keeps running in the Space itself, so no code is downloaded onto your machine. That said, this reduces one class of risk but does not by itself make a third-party Space safe to trust.
What can the canary tools do?
Pollen Robotics published two public canary Spaces, reachy-mini-search-tool and reachy-mini-weather-tool, demonstrating stateless web search and weather lookups. They are examples of the kind of remote capability the system is designed for.
Is this a humanoid robot capability update?
No. Reachy Mini is a small open robot and developer platform. This update is about software tool access and extensibility, not a new physical capability, autonomy claim, or commercial deployment.
Sources: Hugging Face, "Adding MCP Tools to Reachy Mini" (June 3, 2026); Hugging Face Spaces and API metadata for pollen-robotics/reachy-mini-search-tool and pollen-robotics/reachy-mini-weather-tool (checked June 4, 2026); Reachy Mini on Hugging Face. TheMimic has not independently tested Reachy Mini or these Spaces.
Published by themimic.io — tracking the humanoid robotics industry without the hype.