The EV3 MCP Server provides remote control and monitoring of a LEGO Mindstorms EV3 brick via Wi-Fi SSH, designed for AI/LLM integration. Key capabilities:
Drive: Move forward/backward with move_forward/move_backward, turn left/right (turn_left/turn_right) using differential drive; tunable speed and duration.
Stop: Immediate motor halt via stop, with safety bypass overriding command locks.
Sound: Play a beep on the EV3 speaker.
Device listing: list_connected_devices shows all attached motors/sensors with port, driver, and mode.
Robot status: robot_status reports dry-run flag, SSH connection, motor port config, busy status, and last error.
AI integration: Serves as backend for MCP-compatible AI clients (e.g., CLI chat, Cursor, Claude Desktop) enabling natural language control.
Configuration: Customizable motor ports, default/max speeds/durations, Python interpreter on the brick, and SSH authentication.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@EV3 MCP Server Move forward for 2 seconds and beep."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Host-side FastMCP stdio server that any MCP client can use to drive a LEGO Mindstorms EV3 over Wi-Fi SSH. MCP stays on your Mac; only thin ev3dev2 code runs on the brick (MicroPython by default).
This repo also includes a CLI chat client that uses Hugging Face Inference Providers (OpenAI-compatible) by default, spawns the local EV3 MCP server, and lets you type natural language like move forward.
CLI chat (ev3-chat / main.py) or Cursor / Claude Desktop
│ stdio MCP tools
▼
ev3_mcp on Mac ──persistent SSH──► EV3 brick (ev3dev2 motors)Related MCP server: Minecraft Dedalus MCP
Python 3.10+
uv (recommended)
EV3 running ev3dev with ev3dev2 (MicroPython preferred; python3-ev3dev2 also works)
SSH reachability from the host (password auth by default)
For the chat CLI: a Hugging Face token with Inference Providers permission (or any OpenAI-compatible endpoint)
cd /path/to/ev3dev_MCP
uv sync
cp .env.example .env # edit only when leaving dry-run / set LLM vars for chatDry-run is on by default (EV3_DRY_RUN=1): no SSH is opened at startup or on tool calls; tools log the would-be remote Python and return fake success shaped like real results. Flip to EV3_DRY_RUN=0 only after EV3_HOST is reachable and EV3_PASSWORD works.
When dry-run is off, the MCP server connects over SSH immediately on startup (eager connect) and logs success or failure. Tool calls still reconnect if the session drops.
Method | Env | Notes |
Password (primary) |
| Default path — set this in |
SSH key (optional fallback) |
| Used only when |
Never commit a real .env.
Variable | Default | Purpose |
|
| Tank drive ports |
|
| Brick interpreter ( |
|
| Default and clamp for |
|
| Default and clamp for |
Drive tools use timed on_for_seconds runs (not infinite spin). Concurrent drive calls are rejected as busy; stop bypasses the lock and clears it.
# stdio MCP server (what clients spawn)
uv run python -m ev3_mcp.server
# or after uv sync / pip install -e .
python -m ev3_mcp.serverThe client spawns ev3_mcp.server over stdio, calls a chat model via Hugging Face’s OpenAI-compatible router, and runs a prompt-toolkit chat loop.
# 1. Put HF_TOKEN in .env (https://huggingface.co/settings/tokens)
# 2. Pick a tool-capable OPENAI_MODEL, then:
uv run main.py
# or
uv run ev3-chat
# or
uv run python -m ev3_chatOptional extra MCP server scripts (same pattern as the reference cli_project):
uv run main.py /path/to/other_mcp_server.pyVariable | Default | Purpose |
| (required) | Hugging Face token (Inference Providers). Also accepts |
|
| HF router; set to |
|
| Tool-capable model id ( |
|
| Spawn EV3 server with |
Tool calling: the EV3 tools only work if the model/provider supports OpenAI-style tools. Prefer instruct models known for function calling; you can append :fastest, :cheapest, or a provider like :groq / :together.
Smoke-test MCP only (no LLM required) — lists the 7 EV3 tools:
uv run mcp_client.py
# or
uv run python -c "from ev3_chat.mcp_client import main; import asyncio; asyncio.run(main())"Tool | Behavior |
| Both motors forward for |
| Same, reverse |
| Differential turn |
| Immediate stop — bypasses command lock |
| Speaker beep |
| Live motors/sensors on the brick (address, driver, mode) |
| Dry-run flag, SSH state, ports, busy, last error |
Copy from mcp.json.example. Point command/args at this repo and set env (keep dry-run until the brick is ready):
{
"mcpServers": {
"ev3": {
"command": "uv",
"args": ["run", "--directory", "/absolute/path/to/ev3dev_MCP", "python", "-m", "ev3_mcp.server"],
"env": {
"EV3_DRY_RUN": "1",
"EV3_HOST": "192.168.1.100",
"EV3_USER": "robot",
"EV3_PASSWORD": "maker"
}
}
}
}Claude Desktop uses the same stdio shape in claude_desktop_config.json.
The MCP process must run on a machine that can SSH to the EV3 (typically your Mac on the same Wi-Fi). Cloud-only agents that cannot spawn a local stdio server cannot drive the brick in v1.
Path | Role |
| FastMCP stdio server |
| CLI chat client ( |
| Thin entry → |
| Thin smoke-test entry (list tools, no LLM) |
Sensors, camera, on-brick MCP, persistent brick daemon, drive-command queuing, SSE/HTTP remote MCP.
Play a short confirmation beep on the EV3 speaker.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action (play a beep), the duration (short), and the purpose (confirmation), which is sufficient for a simple, non-destructive, zero-parameter tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that contains no filler or redundant information. It front-loads the key action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a trivial tool with no parameters and minimal side effects, this description is complete. The presence of an output schema further reduces the need to describe return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there are no parameter semantics to explain. The baseline of 4 applies because the description correctly and completely describes a parameterless operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Play') and resource ('EV3 speaker') to clearly state what the tool does. It also distinguishes itself from the sibling tool set, which contains movement and status commands, by being the only audio feedback tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'confirmation' implies the tool is meant for auditory feedback events, providing clear context for use. It does not explicitly state when not to use it or name alternatives, but given the sibling tools are all movement/status related, there is no competing alternative for beeping.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List motors and sensors currently connected to the EV3 (port address, driver name; sensors also include mode).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It clearly indicates the output contents (port address, driver name, mode) and that it is a read-only listing operation. While it doesn't describe side effects, the word 'List' makes it clear this is non-destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that includes all essential information without waste. It is front-loaded with the primary action and includes the needed details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters, and an output schema exists. The description additionally clarifies the content of the output (port address, driver name, mode), which is helpful. It fully addresses what the agent needs to know for this simple listing operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to explain parameters. The baseline score of 4 applies, and the description appropriately focuses on the return information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: listing motors and sensors connected to the EV3, with specific details (port address, driver name, mode for sensors). This is a specific verb + resource and distinguishes itself from sibling action-oriented tools like move_forward or beep.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly suggests using this tool when you need to know which devices are connected, but it does not explicitly mention when to use it over alternatives or provide exclusions. No sibling tool overlaps directly, but the lack of explicit guidance lowers the score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Drive the EV3 tank motors backward for a timed duration at a given speed percent.
| Name | Required | Description | Default |
|---|---|---|---|
| speed_pct | No | Speed percent 1–max (clamped). Uses default if omitted. | |
| duration_s | No | Seconds to drive (clamped to configured max). Uses default if omitted. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the core behavior (driving backward for a duration at a speed), but does not mention whether the call blocks, if it stops after the duration, or any safety considerations. The clamping behavior is already in the schema, so the description adds minimal extra transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently communicates the core action and key parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter tool with complete schema coverage and an output schema, the description covers the essential action. However, it omits any mention of prerequisites (e.g., robot connected) or relationship to sibling tools, leaving some context implicit. Still, the overall context is sufficient for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters have full descriptions in the schema (speed_pct with range/clamping, duration_s with clamping), achieving 100% coverage. The description only restates these concepts without adding new meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Drive'), a clear resource ('EV3 tank motors'), and explicit direction ('backward'), with additional detail on timing and speed. This unambiguously distinguishes the tool from its sibling 'move_forward'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies use when backward movement is required, providing clear context. However, it does not explicitly reference alternative tools (e.g., 'move_forward') or state when not to use it, so it stops short of full alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Drive the EV3 tank motors forward for a timed duration at a given speed percent.
| Name | Required | Description | Default |
|---|---|---|---|
| speed_pct | No | Speed percent 1–max (clamped). Uses default if omitted. | |
| duration_s | No | Seconds to drive (clamped to configured max). Uses default if omitted. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention whether the robot stops automatically after the duration, whether the command blocks or is asynchronous, or any prerequisites like a connected device. This is a significant gap for a movement control tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that is front-loaded and contains no filler. It efficiently communicates the core purpose without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, the schema covers both parameters, and an output schema exists, so the description does not need to explain return values. However, the lack of behavioral disclaimers and usage guidance prevents a perfect score, though it is still adequate for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes both parameters (speed_pct and duration_s) with details about clamping and defaults. The description adds no additional parameter-specific meaning beyond restating 'speed percent' and 'timed duration', so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: drive the EV3 tank motors forward for a timed duration at a given speed percent. It uses a specific verb and resource, and the sibling names (move_backward, turn_left, etc.) make it unambiguous which tool is being described.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (to move forward) but provides no explicit guidance about when not to use it or which alternative to choose (e.g., move_backward for reverse). It lacks the explicit alternatives or exclusions seen in higher-scoring descriptions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report dry-run flag, SSH connection state, motor ports, busy flag, and last error.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. The word 'Report' explicitly indicates a read-only operation, listing all the data points the agent will receive. It does not explicitly state 'no side effects,' but the verb and scope make the behavioral trait sufficiently clear for a status tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that enumerates the exact content of the report. Every word adds value, with no redundancy or filler. It is as concise as possible while conveying the full purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only status tool with an output schema present, the description adequately covers what the tool reports. It does not need to explain return values given the output schema. It lacks explicit usage guidance, but that is a minor gap for a self-evident status tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
This tool has zero parameters, and the schema coverage is trivially 100%. The description does not need to explain any parameters. Per the baseline for 0 params, the score is 4; no additional parameter semantics are necessary.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with the verb 'Report' and specifies the exact resource (robot status) and its components (dry-run flag, SSH connection state, motor ports, busy flag, last error). This distinctly differentiates it from sibling tools that perform actions like move_forward or stop.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as a diagnostic/status tool among a set of action-oriented siblings, but does not explicitly state when to use it (e.g., before/after commands) or provide exclusions/alternatives. Usage context is clear by inference only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Immediately stop both drive motors. Bypasses the command lock (safety fast path).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It reveals two key behaviors: immediate stopping of both motors and bypassing the command lock (safety fast path). This goes beyond what a simple 'stop motors' description would provide. It does not mention any side effects or the state of the command lock after execution, but for a simple parameterless stop command, the disclosed details are substantive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: two short sentences. The first sentence front-loads the core purpose ('Immediately stop both drive motors'), and the second adds essential safety context. Every word earns its place, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameterless tool with an output schema present, the description covers the essential context: what it does (stops motors) and key behavioral nuance (bypasses command lock). The mention of 'both drive motors' and 'safety fast path' provides sufficient clarity for an agent to select and invoke it correctly. Given the tool's simplicity, the description is complete enough, though it could hypothetically mention whether it works in any state, but that is not a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is empty. Per the rubric, a parameterless tool gets a baseline score of 4. The description does not need to add parameter semantics because there are no parameters to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Immediately stop both drive motors.' This is a specific verb ('stop') with a clear resource ('both drive motors'), distinguishing it from sibling movement commands like move_forward or turn_left. The additional context about bypassing the command lock further clarifies its specific role as a safety stop.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: it is a safety fast path that bypasses the command lock, implying it should be used for immediate or emergency stops, especially when the command lock might otherwise block a stop. It does not explicitly mention alternatives or exclusions, but the safety-specific language makes the intended use case clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Differential turn left (left motor reverse, right forward) for a timed duration.
| Name | Required | Description | Default |
|---|---|---|---|
| speed_pct | No | Speed percent 1–max (clamped). Uses default if omitted. | |
| duration_s | No | Seconds to turn (clamped to configured max). Uses default if omitted. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It usefully reveals the motor actions and timed nature, but it does not mention whether the robot stops after the duration, the command's blocking behavior, or what the output/return value indicates. This leaves some key behavioral aspects unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that leads with the core function ('Differential turn left'), immediately followed by the mechanical detail and duration. No wasteful phrases; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the rich input schema, the description covers the primary behavior (motor reversal, timed turn) and is well-supported by sibling names. It does not explain return values or post-duration behavior, but the output schema (present) likely covers that, making the description sufficient for a basic motion tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with clear descriptions for speed_pct and duration_s, including defaults and clamping. The description adds the 'timed duration' context, but this mainly reinforces the schema rather than adding novel meaning. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states a specific action ('Differential turn left') and clarifies the mechanical execution ('left motor reverse, right forward'), which clearly distinguishes it from siblings like move_forward and turn_right. The mention of 'timed duration' also aligns with the duration_s parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for performing a left turn in place, but it does not explicitly provide alternative tool names (e.g., 'use turn_right for right turns') or state when not to use it. The sibling tool list offers context, but the description itself lacks direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Differential turn right (left motor forward, right reverse) for a timed duration.
| Name | Required | Description | Default |
|---|---|---|---|
| speed_pct | No | Speed percent 1–max (clamped). Uses default if omitted. | |
| duration_s | No | Seconds to turn (clamped to configured max). Uses default if omitted. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the differential drive mechanism, specific motor directions, and that the action is time-limited, which gives useful behavioral insight beyond the bare command name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core action and includes only essential details. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only two parameters, the schema fully documents them, and an output schema exists. The description plus schema provide sufficient context for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers both parameters with clear descriptions, defaults, and clamping behavior. The description adds minimal parameter-specific detail beyond noting 'timed duration,' so it does not exceed the schema baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Differential turn right' clearly identifies the action and scope. The motor behavior '(left motor forward, right reverse)' is a concrete detail that distinguishes it from turn_left and other movement commands.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for executing a right turn with a differential drive, but does not explicitly state when to use this versus alternatives like turn_left or move_forward. No exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0beeplist_connected_devicesmove_backwardmove_forwardrobot_statusstopturn_leftturn_rightEach tool has a clearly distinct purpose: movement commands (forward/backward/turn/stop) are mutually exclusive, and beep, list_connected_devices, and robot_status cover separate concerns. No overlapping functionality.
All tool names use lowercase snake_case and follow a consistent verb-first pattern (move_forward, turn_left, list_connected_devices). Minor variance like 'robot_status' is still in the same style, so the set feels predictable.
With 8 tools, the server is well-scoped for EV3 remote control and status monitoring. Each tool addresses a necessary operation without redundancy or bloat.
The core movement and status operations are covered, including safety stop and device enumeration. A minor gap is the lack of direct sensor reading (e.g., reading a sensor value), but the current surface handles common remote-control workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Remote MCP server for supportsheep: run AI interviews and manage support content for your blog.
MCP server for AI dialogue using various LLM models via AceDataCloud
Use AI models for chat, image, and video generation from Claude Code and other MCP hosts.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/HannaFrangi/ev3dev_MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
