EV3 MCP Server

by HannaFrangi

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each 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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 4.1/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![ev3dev_MCP MCP server](https://glama.ai/mcp/servers/HannaFrangi/ev3dev_MCP/badges/card.svg)](https://glama.ai/mcp/servers/HannaFrangi/ev3dev_MCP)

Score Badge

Copy to your README.md:

[![ev3dev_MCP MCP server](https://glama.ai/mcp/servers/HannaFrangi/ev3dev_MCP/badges/score.svg)](https://glama.ai/mcp/servers/HannaFrangi/ev3dev_MCP)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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