Robonine MCP Server
OfficialClick 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., "@Robonine MCP Serverlist connected robot arms"
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.
Robonine MCP Server
A local MCP server that connects Claude Code (or any MCP-compatible AI assistant) to a Robonine robot arm. The server runs on your machine and relays tool calls to the Robonine web app open in your browser — no robot data passes through any remote server.
How it works
Claude Code ←stdio→ MCP server ←ws://127.0.0.1:60808→ Browser tab → BT/USB → RobotThe MCP server starts a WebSocket server on 127.0.0.1:60808. The Robonine web app connects to it automatically when the MCP Bridge plugin is installed and active. Once connected, Claude Code can read robot state and send motion commands.
Related MCP server: computer-use-mcp
Installation
From GitHub
Claude Code fetches and runs the server automatically — no manual steps needed:
claude mcp add robonine -- npx -y github:roboninecom/robonine-mcpOr add to your MCP host config:
{
"mcpServers": {
"robonine": {
"command": "npx",
"args": ["-y", "github:roboninecom/robonine-mcp"]
}
}
}Local (from this repo)
Build once, then point Claude Code at the compiled file:
cd mcp && npm install && npm run build
claude mcp add robonine -- node /path/to/student-lab/mcp/dist/index.jsSetup in the browser
Open lab.robonine.com (or your local dev instance).
Install the MCP Bridge plugin from the plugin marketplace.
Connect your robot arm.
The browser tab connects to the local MCP server automatically — the MCP Bridge plugin page shows the relay status.
Available tools
Tool | Description |
| List currently connected robot arms |
| Get joint angles and end-effector position |
| Move the arm to specified joint positions |
| Disable torque on all servos |
| List your registered robots |
| List your saved motion paths |
| Read a motion path with all waypoints |
Configuration
Env var | Default | Description |
|
| WebSocket port the browser tab connects to |
If you change the port, set the same value in the MCP Bridge plugin settings.
Available Tools
1 toolcheck_connectionARead-only
Check whether the browser relay (Robonine web app with MCP Bridge plugin) is connected. Returns "connected" or "not connected".
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds that the tool returns 'connected' or 'not connected', which is useful but does not disclose any other behaviors (e.g., whether it triggers any side effects, latency, or error cases). For a simple read check, this is acceptable but not outstanding.
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?
Single sentence front-loads the action and result. No extraneous words, highly efficient.
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 health-check tool with no parameters and no output schema, the description fully explains what it does and its return value. No gaps given the tool's complexity.
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?
No parameters exist, so schema coverage is effectively 100%. The description does not need to add parameter info. The baseline for zero parameters is 4.
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?
Clearly states the tool checks whether the browser relay is connected and returns a status string. The verb 'check' and resource 'connection' are specific, and with no sibling tools, no further differentiation is needed.
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?
No explicit guidance on when to use this tool versus alternatives. The purpose is clear but lacks context like 'use before operations requiring connection', which would help an agent decide when to invoke.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
1 tool update
v1.0.0- First observed
check_connection
TDQS
With only one tool, there is no possibility of ambiguity or confusion between tools.
The single tool name 'check_connection' follows a clear verb_noun pattern, consistent by default.
The server offers only one trivial tool, which is extremely insufficient for any substantive functionality or scope implied by the server name.
The server provides no meaningful operations beyond a connectivity check, leaving all other possible actions completely uncovered.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Remote MCP server for supportsheep: run AI interviews and manage support content for your blog.
Related MCP Servers
- AlicenseNot gradedqualityFmaintenanceA simple MCP server that enables Claude to communicate with locally running LLM models via LM Studio.9MIT
- AlicenseNot gradedqualityAmaintenanceMCP server that enables Claude to control your computer, similar to Anthropic's computer use but easy to set up locally.327356MIT
- FlicenseNot gradedqualityBmaintenanceA lightweight MCP server that bridges Claude AI with local Python execution, enabling personalized greetings and demonstrating local tool integration.-
- AlicenseNot gradedqualityDmaintenanceA local MCP server that connects Claude Desktop to execute custom local code, such as generating custom greetings.16ISC
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/roboninecom/robonine-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server