For makers and artists working with embodied AI, the latest update to Reachy Mini means your robots can now access a wider world beyond their immediate hardware. By integrating public Model Context Protocol (MCP) tools, developers can equip their creations with real-time capabilities like web searching and weather checks without rewriting core application code. This shift moves non-physical capabilities to the cloud, allowing for easier sharing and updates while keeping the robot’s trusted local logic intact.
How to add remote tools
Integrating new capabilities is now a single command. To add a tool from the Hugging Face Hub, run:
reachy-mini-conversation-app tool-spaces add pollen-robotics/reachy-mini-weather-tool
Once added, start the application normally:
reachy-mini-conversation-app
The robot can then immediately query external data:
What's the weather in Paris today?
Understanding the tool architecture
When interacting with the robot, the response is not just audio; it is a coordinated system where the robot moves and reacts non-verbally based on the conversation. The “tools” are the specific actions the model can trigger: adjusting head position, playing recorded emotions, or capturing camera frames. Each tool has a distinct name and description that the model reads to determine utility.
Currently, every tool is local Python code shipped within the app, primarily governing the robot’s physical body. The following table outlines the standard built-in functions:
| Tool | Function |
|---|---|
move_head | Queue a change in head pose |
dance / stop_dance | Play or clear a dance from the library |
play_emotion / stop_emotion | Play or clear a recorded emotion clip |
head_tracking | Toggle head-tracking offsets |
camera | Capture a frame and analyze it |
idle_do_nothing | Explicitly remain idle during a turn |
A tool remains inactive until enabled in a specific profile. A profile is a folder containing two critical files: instructions.txt (the prompt) and tools.txt (the list of active tools). The default profile enables the full suite of local functions:
# profiles/default/tools.txt dance stop_dance play_emotion stop_emotion camera idle_do_nothing head_tracking move_head
If a tool name is absent from tools.txt, the model cannot invoke it. Users can also write custom tools by adding a Python file to the profile or the external_tools/ directory, naming it, and listing it in tools.txt.
Solving the friction of local tools
The constraint of requiring every tool to be local Python code works well for hardware interaction but creates friction for stateless capabilities like web searches or lookups. Sharing a tool requires handing over Python files; updating it necessitates re-sending files; and modifying it requires editing the main app even though the capability is separate.
Remote tools solve this by introducing a third category alongside built-in and custom local tools. These remote capabilities live in public Hugging Face Spaces, making them easy to publish, share, and update independently. This architecture is ideal for stateless functions like search or weather, allowing developers to iterate without touching the core app. Because anyone can publish a compatible Space, it fosters a collaborative ecosystem.
Testing the new flow
The initial release includes two canary tools designed to test the new workflow: a search tool and a weather tool. Together, they demonstrate the full feature set: installing from the Hub, discovering remote tools, enabling them per profile, and allowing the realtime backend to call them just like built-in functions.
To use multiple tools simultaneously, add each Space to the same profile:
reachy-mini-conversation-app tool-spaces add pollen-robotics/reachy-mini-search-tool reachy-mini-conversation-app tool-spaces add pollen-robotics/reachy-mini-weather-tool
This allows the robot to search the web and check the weather in a single conversation, mirroring the logic of the canary_web_search_weather profile.
Managing and installing tools
The command line interface provides several options for managing these spaces:
# install + enable in active profile reachy-mini-conversation-app tool-spaces add <owner/space-name> # enable in a specific profile reachy-mini-conversation-app tool-spaces add <owner/space-name> --profile <NAME> # install without enabling reachy-mini-conversation-app tool-spaces add <owner/space-name> --install-only # list installed spaces reachy-mini-conversation-app tool-spaces list # remove an installed space reachy-mini-conversation-app tool-spaces remove <owner/space-name>
The add command validates the Space on the Hub, probes the MCP endpoint, discovers its tools, and appends the tool IDs to the active profile’s tools.txt by default. The active profile is default unless the environment variable REACHY_MINI_CUSTOM_PROFILE is set. Use --install-only to skip enabling.
tools.txtis the gatekeeper: a remote tool is only active if its ID appears in the profile’stools.txt, alongside whatever built-in tools you have enabled.
Installed sources are persisted in installed_tool_spaces.json (managed app mode) or external_content/installed_tool_spaces.json (terminal mode). Each Space receives a local alias derived from its slug, collapsing hyphens, dots, and slashes into underscores:
pollen-robotics/reachy-mini-search-tool → pollen_robotics_reachy_mini_search_tool
Remote tools are then namespaced with a double underscore to prevent collisions with built-in tools:
pollen_robotics_reachy_mini_search_tool__search_web pollen_robotics_reachy_mini_weather_tool__get_day_brief
The implementation also strips redundant Space-name prefixes when possible to create cleaner local IDs. If stripping would cause a collision between two tools from the same Space, the code falls back to the fully namespaced name. Additionally, a duplicate safety check at the registry level ensures Tool.name values are unique across the entire merged tool set, causing the app to fail fast if duplicates are detected.
Profiles for the canary experiment
Two focused profiles were created to isolate the MCP experiment from the full embodied tool set. The first retains expressive tools (emotions, head movement) and adds web search:
# profiles/canary_web_search/tools.txt play_emotion stop_emotion idle_do_nothing move_head pollen_robotics_reachy_mini_search_tool__search_web
The second profile adds the weather tool alongside search:
# profiles/canary_web_search_weather/tools.txt play_emotion stop_emotion idle_do_nothing move_head pollen_robotics_reachy_mini_search_tool__search_web pollen_robotics_reachy_mini_weather_tool__get_day_brief
This small physical toolset ensures Reachy Mini can still react expressively while answering current questions sourced from the web.
Prompt engineering for remote tools
While the plumbing gets the tools to the model, the prompts decide how the model uses them. This was evident in the search-plus-weather canary. A combined question like:
Should I bring a jacket in Bordeaux today, and is there anything major happening downtown tonight?
can be handled in three ways: weather first then search, search first then weather, or both in the same turn. Vague prompts cause the model to serialise calls, creating unnecessary latency. Consequently, the canary prompts became part of the feature itself.
canary_web_search/instructions.txt[default_prompt] ## CANARY WEB SEARCH RULES You have one remote tool for current web information. Use it when the user asks for up-to-date facts, news, live availability, or anything else that may have changed recently. When the search result already answers the question, answer directly in plain language. Lead with the answer, not with tool chatter. For remote lookups that may take a moment, you may give one very short English acknowledgment such as "Let me check that and I'll be right back," then continue. Answer in English unless the user explicitly asks for another language. Mention uncertainty briefly if the result snippet is incomplete or ambiguous. Only mention links when they add value or the user asks for sources. Keep responses short and spoken-style, as if read aloud by a voice assistant. One or two sentences is usually enough. Skip preamble, lists, headers, and filler. Give just the fact or direct answer the user needs.
canary_web_search_weather/instructions.txt[default_prompt]## CANARY SEARCH AND WEATHER RULES
You have two remote tools:
- a weather brief tool for compact day weather at a location
- a web search tool for broader current web informationUse the weather tool for today's conditions, temperature, rain chance, sunrise, sunset, or simple advice like whether to bring a jacket.
Use web search for news, events, business hours, travel information, severe alerts, or broader current context.When the user's question mixes a weather part and a current-info part (for example, "should I bring a jacket in Bordeaux today, and is there anything major happening downtown tonight?"), call both tools in parallel in the same turn. Do not wait for one result before starting the other unless the weather result is needed to narrow the search.
Then merge the results into a single short answer. Cover the weather part first, then the events or news part, in plain connected sentences. Do not label the sections or mention which tool gave which piece.
When the user asks about events, news, or what is happening, give them the actual answer from the search results: name specific events, venues, or headlines. Do not tell the user to check websites, visit listing sites, or look something up themselves. If
Source Read original →Stay ahead of AI. Get the most important stories delivered to your inbox — no spam, no noise.
