Our Take
This is a clean separation of concerns: robot body logic stays local and trusted, stateless capabilities (search, weather, lookups) live remote and shareable, and profile files decide what's active.
Why it matters
Embodied AI systems need both responsiveness for hardware control and up-to-date knowledge for reasoning. Splitting those across local and remote execution lets teams ship robot features faster without rebuilding the core app.
Do this week
If you're building a conversational robot: audit which tools belong in-app (hardware, latency-critical) versus remote (knowledge, stateless), then pin your remote tool versions to tested Space commits before deploying to production.
Reachy Mini adds MCP remote tools via Hugging Face Spaces
Pollen Robotics' Reachy Mini conversation app can now invoke tools hosted on public Hugging Face Spaces using Model Context Protocol (MCP) instead of bundling them locally. A single command registers a Space; the robot then calls its tools exactly as it calls built-in ones, but the code stays remote.
Installation is one line: reachy-mini-conversation-app tool-spaces add pollen-robotics/reachy-mini-weather-tool. A profile file (tools.txt) gates which remote tools are active. The implementation includes two canary tools: weather briefing and web search. Remote tools are namespaced with double underscores to avoid collisions with built-in ones.
The app enforces a clear hierarchy. Built-in tools (move_head, play_emotion, camera, head_tracking) stay local and trusted. Custom local tools can live in external_tools/. Remote tools sit in a third tier: shareable, published separately, updated without touching the app itself. All three coexist in one tool registry; tools.txt decides what the model can call in each profile.
No arbitrary code is downloaded. The Space must expose a standard MCP endpoint; installation fails if tool discovery does not succeed. Prompts control whether the model chains calls sequentially or in parallel (the canary_web_search_weather profile explicitly instructs the model to call both weather and search in the same turn when appropriate).
Decoupling hardware from knowledge unlocks faster iteration
Embodied systems face a tension: hardware control needs low latency and local trust, but useful responses often require current information (weather, events, search results). Bundling both into one app means every feature iteration touches the robot's core. Remote tools break that coupling.
For stateless capabilities like weather or web search, publishing as a Hugging Face Space lets the tool author iterate independently. Other robot builders can install it with one command. Multiple Spaces can coexist in the same profile without name collisions. The robot gets new abilities without a new release.
The design also transfers orchestration responsibility to the prompt. A vague instruction will cause the model to serialize tool calls (check weather, then search), adding latency unnecessarily. The canary prompts instruct parallel execution explicitly. This means teams can tune response behavior without code changes, but deterministic orchestration cannot be guaranteed by the prompt alone; that logic should stay in code if it is critical.
Map your tools to execution boundaries before shipping
Start by listing every capability your embodied agent needs: hardware control, knowledge retrieval, I/O, state mutations, and external lookups. Hardware and state-changing operations belong local (move_head, play_emotion, database writes). Stateless queries belong remote (weather, search, translation, fact lookups).
For local tools, define them in external_tools/ or ship them in the app itself if they are essential. For remote tools, publish as a public Gradio Space with a standard MCP endpoint and keep them stateless (no file I/O, no session state). Use profile files to bundle related tools: create one profile for web-search-only interactions, another for search-plus-weather, another for the full embodied toolkit if needed.
Test tool naming collisions early. Remote tools are namespaced with the Space owner and slug (pollen_robotics_reachy_mini_weather_tool__get_day_brief), but the implementation tries to strip redundant prefixes. Run reachy-mini-conversation-app tool-spaces list to confirm final names before shipping. Write prompts that encourage parallel execution for independent tools; if orchestration order is critical, that logic belongs in the backend or the Space itself, not the prompt.
Current limits: private or authenticated Spaces are not supported yet. Non-Gradio Spaces and arbitrary raw MCP URLs cannot be installed. Guaranteed parallel orchestration relies on the model's willingness to obey the prompt, not on the infrastructure. If your use case requires deterministic tool chaining, implement that in code.