Local MCP server

Let Claude control the robot arm on your desk.The two tools that move it wait for your word.

The ay-robots command-line client carries a local MCP server called ay-robots-local. Register it once and your agent can read the state of a connected SO-100, start and stop a recording, send the arm home and set one joint.

See all 9 tools How the confirmation works

9: Tools the local server exposes. There is no tenth.
5: Of them only read. They move nothing.
2: Motion tools, both refused without confirm: true
8000: The local port the tools call, on 127.0.0.1

The chain

From a sentence in the chat window to a servo on your desk.

Four hops, and only the first leaves your machine.

You ask a question

"Is the arm connected?" The model decides a tool answers that, and picks one of the 9.

The stdio server takes the call

Your client launched it as a child process and speaks JSON-RPC over standard input and output. No port, no key.

The tool calls the local backend

Every tool is an HTTP call to the robotapp backend on port 8000, which the client already runs.

The backend drives the servos

Pairing, calibrated limits and the recording buffer were there before any agent. No second route to the hardware exists.

The full list

All 9 tools, and what each may touch.

5 only read, 2 move hardware, 2 handle the recording buffer. Nothing overwrites calibration: use the arm, do not reconfigure it.

Tool	What it does	Class
get_status	Backend, pairing and hardware status. The first call of a session.	reads
list_devices	The arms and cameras this machine sees, by serial port.	reads
get_joint_positions	Joint angles and gripper state. Read it before a movement and after.	reads
get_recording_status	Whether a recording runs, and how many frames it holds.	reads
list_local_datasets	The datasets recorded on this machine, so nothing is taken twice.	reads
move_home	Moves the arm to its calibrated home pose. Refused without confirmation.	moves
move_joint	Moves one joint to an absolute angle. Refused without confirmation. The backend clamps it into the calibrated range and reports what reached the servo.	moves
start_recording	Opens the buffer with one task description. You still teleoperate; this starts the tape.	records
stop_recording	Saves the take as an episode, or discards it. Discard failures: a saved failure teaches the policy to fail.	records

The safety catch

An agent cannot move your arm by accident.

Both motion tools are refused unless the call carries confirm set to true. Not a system prompt and not a habit the model is asked to keep, but a check in the server. Forget it, and this comes back:

moves

move_joint moves a physical robot arm. Ask the user to confirm, then call again with confirm: true.

An agent that is guessing therefore fails harmlessly and has to ask. The reading tools carry no gate, so the harmless half stays quick.

What the catch is not

A confirmation gate on this server, not a safety controller. It asks whether you meant to move the arm, not what is on your table, and it guards the agent path only: the command line reaches the same backend without passing it.

And what it covers

Both motion tools, checked before the call leaves the server. Underneath, the backend clamps to the calibrated range, caps how far one command may move a joint and honours the emergency stop. No tool here overwrites calibration.

No arm yet? A physical one takes browser commands, no account needed.

Drive one in the browser

Setup

Four steps, and the fourth is a question.

It speaks to the SO-100 and SO-101. If yours already records in the cockpit, three are done.

Install the client

The installer brings the backend and the driver, and the same download page carries the command-line binary that holds the MCP server. Plug the arm in, pair the machine once.

Download the client

Have the backend running

Every tool is an HTTP call to port 8000. An unreachable backend means the arm is not connected or not powered.

What the command line does

Register the stdio server

Two fields: the ay-robots binary as the command, mcp as its one argument. Every client wants them in a different file, which is where copied examples fail.

Get the config block

Ask what the arm is doing

The whole test: the agent calls the status tool and answers in a sentence. Nothing moved, and the wiring is proven.

In practice

Two exchanges that show the shape of it.

Shortened, but the tool names and the refusal are real.

Put it back in the home position.

move_home refused, then move_home with confirm: true

The first call comes back with the confirmation message instead of a movement. You say yes, the second goes through. Two calls for one instruction, on purpose.

I want ten grasps of the red cube. Start the tape and keep count.

start_recording, get_recording_status, stop_recording

The buffer opens with one task description, you teleoperate, and each take is saved or discarded on your word - identical wording across all ten.

The honest part

Claude does not generate the motion.

A language model does not emit joint angles thirty times a second, and this server never asks it to.

A policy produces the actions

GR00T N1.7, pi0.5 and SmolVLA are vision-language-action models, ACT the smaller classic. Trained on episodes of your task, one of them runs in a loop against camera frames and joint states.

The agent is the operator

Read the state, open and close the buffer, park the arm, set one joint: the work of an assistant at the bench.

Which is why it is one joint at a time

The motion tool sets one absolute angle: good for probing a range, useless as a trajectory.

Where the motion actually comes from Can an LLM steer a robot arm at all?The harness around the model

Two servers

This one moves the arm. The hosted one answers questions.

A second MCP server runs on ay-robots.com, and mixing them up is the quickest way to wonder why nothing moves.

What	Local: ay-robots-local	Hosted: ay-robots.com
Where it runs	On your machine, next to the arm	On our servers, nowhere near your arm
How it connects	Over stdio, as a child process of your client	JSON-RPC over HTTP against a published endpoint
What it can touch	The connected arm: status, joints, home, recordings, datasets	Docs, policies, arms, guides and fixes; with an API key also account data and cloud training. Never hardware.

Set up the hosted server

Recording is one step. The rest of the loop is training, serving and evaluating.

See the whole harness

One cable, 9 tools, one confirmation.

Install the client, register one stdio server, then ask your agent what the arm is doing.

Download the client See the config blocks

No arm and no client yet? Start here.