Model Context Protocol

Give your AI agent robot skills.One hosted MCP server.

Claude, ChatGPT, Gemini, Grok, Cursor, VS Code, Windsurf, Cline and Zed all connect to the same endpoint - and can read the robot learning guides, compare policies, look through your datasets and start a cloud training run for you.

Streamable HTTP · JSON-RPC 2.0 · Protocol 2025-06-18 · optional Bearer key

Find your client Prove it works first

36: tools on the server
26: work without any key
20: clients, copy-paste ready
~3 min: from copy to first answer

Copy the block for your client

Every client on this page has a finished config block, taken from its own documentation.

Paste it and restart the client

Nothing to install and nothing runs on your machine - the server is already hosted here.

Ask it about robots

"Which model fits 150 episodes on an SO-100?" - the agent answers from the real guides and trainer defaults.

Your agent

Claude · ChatGPT · Gemini · Cursor …

POST /api/mcp

JSON-RPC 2.0 over Streamable HTTP

Guides · Policies · Datasets · Training

public tools free, account tools per key

Step 0 · no client needed

Try it before you wire anything up

No config file, no client, no account. This is the protocol itself: a JSON-RPC 2.0 call over Streamable HTTP. It is the fastest way to prove the endpoint is reachable from your machine and to see what the agent will get.

You should get back a JSON object whose result.tools array holds 26 entries, starting with search_docs. Add -H "Authorization: Bearer ayr_live_your_key_here" and the account tools appear in the same list.

bash

curl -sS https://www.ay-robots.com/api/mcp \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

Or the handshake, which answers with the server name and protocol version

bash

curl -sS https://www.ay-robots.com/api/mcp \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize",
       "params":{"protocolVersion":"2025-06-18","capabilities":{},
                 "clientInfo":{"name":"curl","version":"1"}}}'

Setup

Pick your client

20 finished blocks. Every one of them is taken from that client's own documentation and links back to it, because these formats change and a wrong config costs you an evening of looking for the mistake on your side.

Claude Desktop and claude.ai

URL only

VS Code with GitHub Copilot

xAI API (Grok, remote MCP tool)

URL only

OpenAI Responses API

URL only

OpenAI Agents SDK (Python)

URL only

Local server, 7 clients

Needs the CLI

Clients that speak to the hosted server directly

Nothing to install and nothing running on your machine. They need the URL, and the API key only if you want your own data. The names of the keys differ, which is the whole reason there is a separate block per client.

Claude Code

Run this in the project you want the server available in. Claude Code writes the entry itself, and "claude mcp list" shows it afterwards with a health check next to it.

Terminal, in your project folder

Claude Code docs, MCP

bash

# public tools, no account needed
claude mcp add --transport http ay-robots https://www.ay-robots.com/api/mcp

# with your datasets, robots and training runs
claude mcp add --transport http ay-robots https://www.ay-robots.com/api/mcp \
  --header "Authorization: Bearer ayr_live_your_key_here"

Or commit it to the repo, so the whole team gets it

json

{
  "mcpServers": {
    "ay-robots": {
      "type": "http",
      "url": "https://www.ay-robots.com/api/mcp",
      "headers": {
        "Authorization": "Bearer ayr_live_your_key_here"
      }
    }
  }
}

Cursor

Save this file and reload the MCP list in Cursor settings. Drop the headers block to stay on the public tools.

.cursor/mcp.json in the project, or ~/.cursor/mcp.json for every project

Cursor docs, MCP

json

{
  "mcpServers": {
    "ay-robots": {
      "url": "https://www.ay-robots.com/api/mcp",
      "headers": {
        "Authorization": "Bearer ayr_live_your_key_here"
      }
    }
  }
}

Claude Desktop and claude.ai

No file to edit: open Settings, click "Connectors" in the sidebar, then "Add" and "Add custom connector", paste the endpoint and confirm. Same steps in the desktop app and in the browser.

Settings, Connectors, Add custom connector

MCP docs, connect to remote servers

text

https://www.ay-robots.com/api/mcp

The connector dialog takes a URL and OAuth credentials, not a fixed header, so this route gives you the tools that work without a key. For your own datasets and training runs use a client that can send an Authorization header: Claude Code, Cursor, VS Code, Windsurf, Cline, Zed or the Gemini CLI, all below.

VS Code with GitHub Copilot

Put this in the workspace file, or run "MCP: Open User Configuration" from the command palette to get the same block for every workspace.

.vscode/mcp.json

VS Code docs, MCP configuration reference

json

{
  "servers": {
    "ay-robots": {
      "type": "http",
      "url": "https://www.ay-robots.com/api/mcp",
      "headers": {
        "Authorization": "Bearer ayr_live_your_key_here"
      }
    }
  }
}

Windsurf (Cascade)

Windsurf uses "serverUrl" rather than "url" for remote servers, which is the single detail that trips people up when they copy a Cursor block into it.

~/.codeium/windsurf/mcp_config.json

Windsurf docs, Cascade MCP

json

{
  "mcpServers": {
    "ay-robots": {
      "serverUrl": "https://www.ay-robots.com/api/mcp",
      "headers": {
        "Authorization": "Bearer ayr_live_your_key_here"
      }
    }
  }
}

Cline

Set "type" explicitly. Cline falls back to the older SSE transport when the field is missing, and this server speaks Streamable HTTP.

Cline MCP settings, ~/.cline/mcp.json for the CLI

Cline docs, configuring MCP servers

json

{
  "mcpServers": {
    "ay-robots": {
      "type": "streamableHttp",
      "url": "https://www.ay-robots.com/api/mcp",
      "headers": {
        "Authorization": "Bearer ayr_live_your_key_here"
      },
      "disabled": false,
      "autoApprove": []
    }
  }
}

Zed

Zed calls them context servers. Add the block to settings.json, or use Settings, AI, MCP Servers. Leave the Authorization header out and Zed will offer you the standard MCP OAuth flow instead.

Zed settings.json, key "context_servers"

Zed docs, MCP

json

{
  "context_servers": {
    "ay-robots": {
      "url": "https://www.ay-robots.com/api/mcp",
      "headers": {
        "Authorization": "Bearer ayr_live_your_key_here"
      }
    }
  }
}

Gemini CLI

The key is "httpUrl", not "url". You can also let the CLI write the entry for you with the command underneath.

~/.gemini/settings.json for every project, .gemini/settings.json for one

Gemini CLI docs, MCP servers

json

{
  "mcpServers": {
    "ay-robots": {
      "httpUrl": "https://www.ay-robots.com/api/mcp",
      "headers": {
        "Authorization": "Bearer ayr_live_your_key_here"
      }
    }
  }
}

Same thing from the terminal

bash

gemini mcp add --transport http ay-robots https://www.ay-robots.com/api/mcp \
  --header "Authorization: Bearer ayr_live_your_key_here"

ChatGPT

Turn on developer mode under Settings, Security and login. Then open ChatGPT Plugins, press the plus button and point the new app at the endpoint. Developer mode is on Pro, Plus, Business, Enterprise and Education accounts on the web.

Settings, Security and login, Developer mode

OpenAI docs, ChatGPT developer mode

text

https://www.ay-robots.com/api/mcp

Pick "No Authentication" when it asks. The dialog offers OAuth or no authentication, so there is no place to put a bearer key, and you get the tools that work without one.

Grok (grok.com)

Open grok.com/connectors, click "New Connector", choose "Custom" and paste the endpoint. Grok needs the server to be reachable on the public internet, which this one is.

grok.com/connectors, New Connector, Custom

xAI docs, connectors

text

https://www.ay-robots.com/api/mcp

xAI API (Grok, remote MCP tool)

No client involved: you name the server in the tools array and xAI connects to it for you. The key goes in the headers object, which xAI documents as additional headers on every request to the MCP server.

POST https://api.x.ai/v1/responses

xAI docs, remote MCP tools

bash

curl https://api.x.ai/v1/responses \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $XAI_API_KEY" \
  -d '{
  "model": "grok-4.6",
  "input": [{"role": "user", "content": "Which policy should I train on 300 SO-100 episodes?"}],
  "tools": [{
    "type": "mcp",
    "server_url": "https://www.ay-robots.com/api/mcp",
    "server_label": "ay_robots",
    "headers": { "Authorization": "Bearer ayr_live_your_key_here" }
  }]
}'

OpenAI Responses API

Same idea on the OpenAI side: the server goes into the tools array and OpenAI does the MCP call. This block stays on the public tools.

POST https://api.openai.com/v1/responses

OpenAI docs, connectors and MCP

bash

curl https://api.openai.com/v1/responses \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -d '{
  "model": "gpt-5.6-sol",
  "input": "Compare GR00T N1.7 and SmolVLA for an SO-100 arm.",
  "tools": [{
    "type": "mcp",
    "server_label": "ay_robots",
    "server_url": "https://www.ay-robots.com/api/mcp",
    "require_approval": "never"
  }]
}'

OpenAI documents an "authorization" field on the tool that takes an access token. What header it turns into is not spelled out, so we do not put your key in the block above rather than have you debug a guess. If you need the account tools from code, the Agents SDK underneath sets the header itself.

OpenAI Agents SDK (Python)

Here you control the headers yourself, so this is the way to reach the account tools from OpenAI code. The server object goes into the agent as mcp_servers.

Your Python file, pip install openai-agents

OpenAI Agents SDK docs, MCP

python

import asyncio, os
from agents import Agent, Runner
from agents.mcp import MCPServerStreamableHttp

async def main() -> None:
    async with MCPServerStreamableHttp(
        name="AY-Robots",
        params={
            "url": "https://www.ay-robots.com/api/mcp",
            "headers": {"Authorization": f"Bearer {os.environ['AY_ROBOTS_API_KEY']}"},
        },
        cache_tools_list=True,
    ) as server:
        agent = Agent(
            name="Robot assistant",
            instructions="Use the AY-Robots tools to answer.",
            mcp_servers=[server],
        )
        result = await Runner.run(agent, "List my datasets and tell me which are big enough to train on.")
        print(result.final_output)

asyncio.run(main())

Hardware

When the agent should move the arm

The hosted server has no hardware access, by design: it runs in a data centre and your arm is on your desk. The CLI ships a second MCP server that runs over stdio on the machine the arm is plugged into, and that one can home it, calibrate it, record episodes and run a policy back.

It is an addition, not a replacement. Most people wire both into the same client and let the agent pick: the hosted one for facts, datasets and training, the local one for the hardware in front of them.

Get the desktop client

Install, macOS and Linux

bash

curl -fsSL https://www.ay-robots.com/install.sh | sh

Install, Windows PowerShell

powershell

irm https://www.ay-robots.com/install.ps1 | iex

The command every config below runs for you

bash

ay-robots mcp

Claude Code

The double dash separates the options that belong to Claude Code from the command it should run.

Terminal

bash

claude mcp add ay-robots-local -- ay-robots mcp

Claude Code docs, MCP

Claude Desktop

Settings, Developer, Edit Config opens this file. Restart the app after saving.

~/Library/Application Support/Claude/claude_desktop_config.json, or %APPDATA%\Claude\claude_desktop_config.json

json

{
  "mcpServers": {
    "ay-robots-local": {
      "command": "ay-robots",
      "args": ["mcp"]
    }
  }
}

MCP docs, connect to local servers

Cursor

Cursor needs "type" on stdio servers, unlike the remote block above.

.cursor/mcp.json or ~/.cursor/mcp.json

json

{
  "mcpServers": {
    "ay-robots-local": {
      "type": "stdio",
      "command": "ay-robots",
      "args": ["mcp"]
    }
  }
}

Cursor docs, MCP

VS Code with GitHub Copilot

Same file as the remote block, one more entry.

.vscode/mcp.json

json

{
  "servers": {
    "ay-robots-local": {
      "command": "ay-robots",
      "args": ["mcp"]
    }
  }
}

VS Code docs, MCP servers

Windsurf (Cascade)

Stdio servers use command and args here, not serverUrl.

~/.codeium/windsurf/mcp_config.json

json

{
  "mcpServers": {
    "ay-robots-local": {
      "command": "ay-robots",
      "args": ["mcp"]
    }
  }
}

Windsurf docs, Cascade MCP

Zed

Same context_servers key as the remote block.

Zed settings.json

json

{
  "context_servers": {
    "ay-robots-local": {
      "command": "ay-robots",
      "args": ["mcp"],
      "env": {}
    }
  }
}

Zed docs, MCP

Gemini CLI

No httpUrl here, just the command.

~/.gemini/settings.json

json

{
  "mcpServers": {
    "ay-robots-local": {
      "command": "ay-robots",
      "args": ["mcp"]
    }
  }
}

Gemini CLI docs, MCP servers

Authentication

About the API key

Most people should try the server without one first. 26 of the 36 tools need no authentication at all, and that is enough for an agent to explain the platform, compare models and read every guide. A key adds exactly one thing: your own account.

Works with no key at all (26 tools)

search_docs
list_policies
get_policy
compare_policies
list_arms
list_supported_robots
list_guides
get_guide
diagnose_problem
list_fixes
get_fix
define_term
list_terms
estimate_training_cost
get_live_demo
get_arm
get_cli_reference
list_industry_directory
get_started_guide
get_pricing
list_vla_models
get_vla_model
compare_vla_models
search
fetch
list_open_positions

Documentation, policy facts, supported arms, fixes for the failures people actually hit, training cost estimates, pricing and the live demo.

What a key adds (10 tools)

Your datasets, your paired robots, your training runs with their logs and the checkpoints they wrote, plus the ability to start a run once you have confirmed what it costs and to stop one that is not working. Remove the header from the config and the server drops back to the public tools.

Create one under dashboard settings. The value starts with ayr_live_ and is shown exactly once, so paste it straight into the client config. Every authenticated call is scoped to the account that owns the key: a tool can never reach a dataset that belongs to someone else.

Create an API key See the live arm

In practice

What your agent can do with this

The server hands an agent the same facts the site is built on, plus your own account data once you give it a key. Four things people actually use it for:

Ask which model suits your dataset

Describe what you recorded, how many episodes and which arm, and let the agent call the policy tools. It answers with the real trainer defaults, the GPU tier each model needs and the measured inference latency, so you hear why SmolVLA is the cheap first run and where GR00T N1.7 pulls ahead.

Have it read a guide before it answers

The documentation tools return the actual guides, not a summary of them. That is the difference between an agent that tells you to feed GR00T a LeRobot v3.0 dataset and one that knows the trainer rejects it, or between an answer that names 7.4 V for the STS3215 servos and one that costs you a set of servos.

Let it start a run and report back

With an API key the agent can check which of your datasets a model can even read, start the training job and then follow it. Renting a GPU spends real money, so the tool refuses to run until you have confirmed the cost out loud. After that you can ask for the status, the loss, the raw trainer log when it fails, and have it stop a run that is going nowhere, all without opening the dashboard.

Have it list your datasets

Ask which recordings you already have and the agent reads them from your account: episode counts, size, frame rate and processing status. It can pull the details of a single dataset from there, including a time-limited download link for the archive, and tell you whether the thing is big enough to train on.

Reference

Every tool on the server

26 of the 36 tools work without any authentication. The rest read or change data in one account and need a key. Each tool ships MCP annotations, so a client can tell a read from a write before it calls anything: 34 of the 36 only read.

Tool	What it does	Effect	API key
`search_docs` Search the documentation	Full text search across everything AY-Robots publishes: the tutorials under /learn, the SO-100 reference pages under /so-100, the per model policy pages under /policies, the training guides under /train (one per model and arm combination), the head to head comparisons under /compare, the troubleshooting pages under /fix and the glossary under /glossary. Use this to answer questions about recording imitation learning data, the LeRobot dataset format, calibrating an SO-100, picking a policy, training one or running it on hardware. Each hit returns title, URL, slug and kind; pass the slug to get_guide to read the page in full. For a symptom in a user's own words, diagnose_problem is the better entry point, and for a single term, define_term.	Reads only	Not needed
`list_policies` List trainable policies	List every policy the AY-Robots training backend can actually fine tune (GR00T N1.7, GR00T N1.5, Pi0.5, SmolVLA, ACT) with the facts an agent needs to choose one: the trainer key the training API expects, vendor, parameter count, GPU tier, measured inference latency per action step, default hyperparameters, the episode count below which the model tends to disappoint, whether it can run outside the cloud, the accepted dataset format and a one line reason to pick it. Start here when a user asks which model to train.	Reads only	Not needed
`get_policy` Policy details	Everything the catalog knows about one policy, looked up by slug (groot-n1-7, groot-n1-5, pi0-5, smolvla, act) or by trainer key (groot1.7, groot1.5, pi0, smolvla, act). Returns the facts, what the model is good at, where it falls down, an estimated cost for one training run, the URL of its page under /policies and the URLs of the step by step training guides that cover it on each supported arm.	Reads only	Not needed
`compare_policies` Compare two policies	Compare two policies side by side on the catalog facts: vendor, architecture, parameters, GPU tier, inference latency, default hyperparameters, extra knobs the training form exposes, minimum episodes, dataset format, whether each can run outside the cloud, and an estimated cost per run. Also returns the strengths and limits of both and the URL of the written comparison page under /compare when one exists. Takes two policy slugs or trainer keys in any order.	Reads only	Not needed
`list_arms` List robot arms	List every robot arm in the AY-Robots catalog (SO-100, SO-101, Koch v1.1, LeKiwi) with alternative names people search for, who makes it, degrees of freedom, servo type, operating voltage, approximate cost in parts and how completely the platform supports it. This is the full answer to "will my arm work" and it carries the supply voltage, which is the mistake that destroys hardware. list_supported_robots returns the older short form.	Reads only	Not needed
`list_supported_robots` Supported arms, short form	Short list of the supported robot arms: id, name, degrees of freedom, servo type, operating voltage and a one line note, taken from the same catalog the site is built on. Kept for compatibility with existing integrations. list_arms is the fuller tool and adds the alternative names people search for, the maker, the approximate cost in parts, the support level and the number of training guides per arm; get_arm returns one arm with its whole page.	Reads only	Not needed
`list_guides` Index of every page	Index of every page on the site: the tutorials under /learn, the training guides under /train (one per model and arm combination), the policy pages under /policies, the comparisons under /compare, the SO-100 reference pages under /so-100, the troubleshooting pages under /fix and the glossary entries under /glossary. Each entry is slug, title, description, URL and kind. Pass kind to narrow the list. Use this to see what exists, then read a page in full with get_guide.	Reads only	Not needed
`get_guide` Read a page	Read one page of the site in full, rendered as clean markdown: headings, paragraphs, fenced code with its language, bullet and numbered lists, tables, callouts as blockquotes, the step by step section as a numbered list and the FAQ as question and answer pairs. Accepts the slug of a tutorial, training guide, policy page, comparison, SO-100 reference page, troubleshooting page or glossary entry, and also accepts a path or a full URL. Two families can share a slug, for example a reference page and a glossary entry of the same name; pass kind to say which one you mean. This is how an agent reads the documentation instead of guessing at it.	Reads only	Not needed
`diagnose_problem` Diagnose a problem	Diagnose a broken robot, a rejected dataset or a failed training run from a free text description of the symptom, and get the actual fix rather than a link. Pass what the user said, for example "the arm goes limp the moment I press record", "GR00T says my dataset is the wrong version" or "the policy runs but the gripper never closes". It ranks the troubleshooting pages under /fix by symptom line, title, keywords and body text, weighted by the arm and the model if you know them, and returns for every candidate the matching symptom, the short answer, the numbered diagnosis steps with their commands and the hardware warnings from that page. That is enough to walk someone through a dead arm in one call. When nothing matches it returns the areas the troubleshooting pages cover instead of an empty result.	Reads only	Not needed
`list_fixes` Troubleshooting index	Index of every troubleshooting page under /fix, grouped by area: hardware, connection, dataset, training and deployment. Each entry is the slug, the page title, the symptom in the words a user would use, and the URL. Pass area to see one group. Use this to see what is covered, diagnose_problem when you have a symptom and want the fix itself, and get_fix to read one page in full.	Reads only	Not needed
`get_fix` Read a troubleshooting page	Read one troubleshooting page from /fix in full, rendered as clean markdown: the cause, the checks in order, the tables, the callouts and the FAQ. Also returns the structured fields on their own, the symptom, the short answer, the area, which arms and which models the page applies to, the numbered diagnosis steps with their commands and the hardware warnings. Takes a slug from diagnose_problem, list_fixes or search_docs; a path or a full URL works too.	Reads only	Not needed
`define_term` Define a term	Look up one term in the AY-Robots glossary at /glossary. Accepts the slug, the term itself or any spelling people use for it, case insensitive, for example "action chunking", "VLA", "checkpoint" or "LeRobot dataset". Returns the one paragraph definition that can stand on its own, the full explanation as markdown, the related terms and the pages on the site that go deeper. Use it before explaining a piece of robot learning vocabulary in your own words, so the wording matches the rest of the platform. If the word is not in the glossary it returns the closest entries instead of an error.	Reads only	Not needed
`list_terms` Glossary index	The whole AY-Robots glossary as a flat list: slug, term, the spellings each term is also known by, and its one paragraph definition. Use this to see which robot learning vocabulary is defined here before explaining it yourself, then call define_term for the full entry with the longer explanation and the links.	Reads only	Not needed
`estimate_training_cost` Estimate training cost	Estimate what one cloud training run costs for a given policy: the GPU tier the pool requests, the hourly price range for that tier, the expected wall clock duration and the resulting total. Optionally pass a step count to scale the estimate away from the model default, and an episode count to check it against the minimum that model needs. GPUs are rented per hour on a spot market, so the answer is a range and never a quote. Call this before start_training so the user knows what they are agreeing to.	Reads only	Not needed
`get_live_demo` Live SO-100 demo	Describe the public live demo at /live: a real SO-100 robot arm that anyone can drive from a browser, with no account, no install and no hardware of their own. Use this when someone wants to try the platform before buying an arm or signing up. Returns a description and the link for the user to open; there is no remote control API in this MCP server, the driving happens in the browser.	Reads only	Not needed
`get_arm` Robot arm details	Everything about one supported robot arm: the hardware facts from the catalog, the full landing page as markdown, which policies and training guides exist for it, and the troubleshooting pages that apply to it. Accepts the slug (so-100, so-101, koch-v1-1, lekiwi) or a common alternative spelling such as SO-ARM100. Use this when someone asks what an arm is, what it costs, what it runs on, or whether to build one.	Reads only	Not needed
`get_cli_reference` CLI reference	The complete command surface of the ay-robots CLI, generated from the shipped parser rather than from documentation. Call this before telling anyone to run an ay-robots command: several commands people expect do not exist, most importantly there is no train subcommand, because training runs on a rented cloud GPU and is started in the dashboard or through the start_training tool. Returns install commands, every subcommand with its real options, and the known wrong commands with what to do instead.	Reads only	Not needed
`list_industry_directory` Robot learning industry directory	Curated directory of the robot learning industry: teleoperation companies, robot training data companies, VLA and imitation learning labs, humanoid makers, robot arm manufacturers and simulation software. Each entry is a real company with website, HQ country and a one line description. Call without arguments for every category, or pass a category slug for one list. Use this when someone asks who offers teleoperation, who sells robot training data, or which companies build humanoids or VLA models.	Reads only	Not needed
`get_started_guide` Getting started path	Return the ordered getting-started path for a new AY-Robots user with an SO-100: install, pair, calibrate, record, train, run. Includes the exact CLI commands.	Reads only	Not needed
`get_pricing` Pricing	Current AY-Robots pricing for training, inference and teleoperation.	Reads only	Not needed
`list_vla_models` List VLA models	List every vision language action model in the AY-Robots VLA Arena, not only the five this platform can train. Each entry carries developer, release month, category, total parameters, whether the weights are public and under which licence, the weights only GPU memory footprint computed at bf16, published inference latency where one exists, and the best reported result on each of three axes: simulation benchmarks, real robot rollouts and fine tuned tasks. Use this when someone asks which VLA models exist, which one fits a given GPU, or how two unrelated models compare. Optional filters narrow the list.	Reads only	Not needed
`get_vla_model` VLA model details	Everything the VLA Arena knows about one model, looked up by slug or by name. Returns architecture (backbone, action head, action chunk, control rate), parameter count, computed GPU memory at four precisions, the smallest real card that fits it, published latency and memory figures with their sources, the pretraining corpus, supported embodiments, every sourced benchmark result grouped into simulation, real world and fine tuned tasks, strengths, limits, licence, links to paper, code and weights, and the full source list. Use this when someone asks what a specific VLA model needs or what it scored.	Reads only	Not needed
`compare_vla_models` Compare two VLA models	Compare two vision language action models side by side on the facts the arena carries: developer, release month, parameters, licence, backbone, action head, computed and reported GPU memory, published latency, control rate and the benchmark suites both of them report. The suites both models ran are listed separately, because those are the only numbers that can honestly be put next to each other. Takes two slugs or names in any order.	Reads only	Not needed
`search` Search AY-Robots documentation	Search everything AY-Robots publishes about recording imitation learning data with an SO-100 class robot arm, training a policy on a rented GPU and running it back on the arm: tutorials, SO-100 reference pages, per model policy pages, training guides, head to head comparisons, troubleshooting pages and the glossary. Returns id, title and canonical URL per hit; pass an id to the fetch tool to read that page in full. Same corpus and ranking as search_docs, in the result shape ChatGPT deep research and company knowledge expect. Use search_docs instead when you want to filter by page family or need the page descriptions.	Reads only	Not needed
`fetch` Read one AY-Robots page	Retrieve one AY-Robots documentation page in full, as markdown, by the id returned from the search tool. A bare page slug or a full https://www.ay-robots.com/ URL is accepted too. This reads the published AY-Robots site only - it is not a general web fetcher and will not retrieve arbitrary URLs.	Reads only	Not needed
`list_open_positions` List open positions	List the roles AY-Robots is currently hiring for, with what the work actually is and what background helps. Two kinds exist: an internship (Praktikum) around recording imitation learning data on real SO-100 class arms, and a working student role (Werkstudent) on the Next.js and TypeScript platform. Hours, duration, start date, pay and work location are deliberately not published, because they are agreed individually - do not invent them and do not guess a salary. Applications are only accepted through the web form at https://www.ay-robots.com/careers, which takes a CV as a file upload; this server never accepts an application or a document.	Reads only	Not needed
`list_datasets` List your datasets	List the datasets in the authenticated account, newest first: id, name, robot type, episode count, size in megabytes, frame rate and processing status. This is where the dataset id comes from that every training tool asks for, and the episode count is what tells you whether a recording is long enough for the model the user has in mind. For one dataset in full, including a time limited download link, call get_dataset; to find out which models can actually read a dataset, call check_dataset_compatibility. The account is whichever one issued the API key, created at https://www.ay-robots.com/dashboard/client/settings.	Reads only	Required
`get_dataset` Dataset details	Everything the account stores about one dataset, looked up by the id that list_datasets returns. Set include_download_url to true and the answer carries a link to the archive that expires after 15 minutes; that link only exists once the dataset has finished processing and has been archived. Use list_datasets when you do not have the id yet, and check_dataset_compatibility before you recommend a model for this dataset, because the format decides which trainer can read it. Needs an API key from https://www.ay-robots.com/dashboard/client/settings.	Reads only	Required
`list_robots` List your robots	List the robot arms paired to the authenticated account with their id, name, type and current online status. Use it to check that the arm the user is talking about is actually reachable before walking them through recording or through running a policy back. This reads account state and does not touch hardware: no tool on this hosted server moves an arm, that is what the desktop client and its local "ay-robots mcp" server do, and https://www.ay-robots.com/live is a real SO-100 anyone can drive in the browser without an account. Needs an API key from https://www.ay-robots.com/dashboard/client/settings.	Reads only	Required
`list_training_jobs` List training jobs	List the training runs of the authenticated account, newest first, optionally filtered by status. This answers "is my training done yet" in one call and it is where the job id for the other training tools comes from. get_training_job returns one run with its configuration, its metrics and the error message; get_training_logs reads the raw trainer output of that run; list_trained_policies shows the checkpoints that came out of the finished ones. Needs an API key from https://www.ay-robots.com/dashboard/client/settings.	Reads only	Required
`get_training_job` Training job status	The full state of one training run: model, dataset, status, the configuration it was started with, the metrics recorded so far, start and finish time and the error message if it failed. Use this to follow a run that start_training returned, with the job id from that call or from list_training_jobs. When the answer sits in the trainer output rather than in the metrics, get_training_logs reads the log files of the same run, and stop_training ends a run that is still burning GPU hours. Needs an API key from https://www.ay-robots.com/dashboard/client/settings.	Reads only	Required
`start_training` Start a cloud training run	Start a cloud training run on one of the account datasets. THIS SPENDS REAL MONEY: it rents a GPU by the hour on a spot market and bills the account, in the order of 1 to 3 USD for a run on the 24 GB tier (act, smolvla) and 4 to 12 USD on the 80 GB tier (pi0, groot1.5, groot1.7), scaling with the step count. Call estimate_training_cost first, tell the user the range, and only pass confirm_spend: true once they have agreed out loud; without it this tool returns the estimate instead of starting anything. check_dataset_compatibility beforehand avoids the expensive failure mode where a run dies minutes in because the trainer cannot read the dataset format, and get_training_job, get_training_logs and stop_training take it from there. Needs an API key from https://www.ay-robots.com/dashboard/client/settings.	Spends money	Required
`stop_training` Stop a training run	Stop a training run that is still queued or running: the rented GPU pod is destroyed and the run is recorded as CANCELLED. This is the tool for "cancel it, the loss is flat" and for a run that was started by mistake, because every further minute is billed to the account. It cannot be undone and it refunds nothing that was already used; checkpoints written before the stop stay in the bucket and still show up in list_trained_policies. Find the id with list_training_jobs filtered to RUNNING, and read get_training_job or get_training_logs first if you are not certain the run is lost. Needs an API key from https://www.ay-robots.com/dashboard/client/settings.	Stops a paid run	Required
`get_training_logs` Training run logs	Read what a training run actually printed. Called with just a job id it lists the log objects of that run with their size; called with file it returns the tail of one of them, usually train.log, which is where a crashed run says why it died. Use it when get_training_job reports FAILED without a useful message, or when a run looks stuck: the metrics carry numbers, the log carries the traceback. Job ids come from list_training_jobs or from the start_training answer, and an API key from https://www.ay-robots.com/dashboard/client/settings.	Reads only	Required
`check_dataset_compatibility` Check dataset compatibility	Check, before any GPU is rented, which datasets of the account a given model can actually read. The dataset version is the trap: GR00T N1.7 and N1.5 load LeRobot v2.0 and v2.1 and reject a v3.0 dataset, while ACT, SmolVLA and Pi0.5 run through lerobot and need v3.0, so one recording can be perfect for one model and unusable for the other. The desktop client writes v2.0, which is why GR00T works on a fresh recording and the lerobot family may need a converted copy first. Call this before start_training: a mismatch otherwise kills the run minutes in, when the GPU is already rented and billing. Needs an API key from https://www.ay-robots.com/dashboard/client/settings.	Reads only	Required
`list_trained_policies` List trained policies	List the trained policies of the account: the checkpoint directory, the name it carries, the model it came from, the dataset it was trained on, whether the checkpoint is complete enough to run and when it was last written. Use it after a run to confirm there is something to deploy and to get the checkpoint name for "ay-robots run" on the desktop client. list_training_jobs shows the runs themselves, including the ones that produced nothing, and get_training_job says why. Needs an API key from https://www.ay-robots.com/dashboard/client/settings.	Reads only	Required

Machine-readable

For agents that find servers on their own

If you are an assistant reading this page rather than a person: everything you need is machine-readable, and you do not have to parse this HTML.

/.well-known/mcp.json

The discovery document: endpoint, protocol version, authentication model and every tool with its input schema. /mcp.json returns the same thing.

GET /api/mcp

A plain GET on the endpoint answers with the server name, the protocol version and the tool list, so you can look before you speak JSON-RPC.

/llms.txt

The site in one text file, with the MCP endpoint named in it. Useful if you are summarising the platform before you connect to it.

The server also returns an instructions string on initialize, which tells you which tool answers which question and which facts about this platform are easy to get wrong. Read it before you answer from memory.

FAQ

Questions

Do I need an API key to connect?

No. Connect without one and the server serves its public tools: the policy facts, the arm list, the guides, the training cost estimate, the live demo and the pricing. A key only adds the tools that touch your account, which are your datasets, your robots, your training runs with their logs and the checkpoints they produced.

Which clients work with this server?

Anything that speaks MCP over Streamable HTTP with JSON-RPC 2.0. This page carries a finished block for Claude Code, Claude Desktop, Cursor, VS Code with Copilot, Windsurf, Cline, Zed, the Gemini CLI, ChatGPT developer mode, Grok, the xAI and OpenAI APIs and the OpenAI Agents SDK. The endpoint is https://www.ay-robots.com/api/mcp and the protocol version is 2025-06-18. There is nothing to install and nothing to run locally.

Why does my client want a different key than the example?

Because the clients disagree on names for the same thing. Cursor and Zed take url, Windsurf takes serverUrl, the Gemini CLI takes httpUrl, VS Code nests everything under servers instead of mcpServers and Zed calls the whole section context_servers. Take the block for your client rather than adapting somebody else’s, and follow the source link next to it if your version disagrees with what you see here.

Why can ChatGPT and Claude Desktop not see my datasets?

Both add a remote server through a dialog that takes a URL and an OAuth flow, with no field for a fixed header, so the API key never reaches the server and you get the public tools. Every client that has a headers block in its config, which is most of them, gets the account tools.

How do I check the server is reachable?

Send the curl command on this page: a tools/list call returns the full tool list in one round trip. A plain GET on https://www.ay-robots.com/api/mcp also answers, with the server name, the protocol version and the tools, and https://www.ay-robots.com/.well-known/mcp.json serves the same description as a discovery document.

What is the difference between this server and the one in the CLI?

Hardware. The hosted server reads documentation and account data and starts cloud training, and it has no path to a physical arm. The CLI runs a second MCP server over stdio with "ay-robots mcp", on the machine the arm is plugged into, and that one can drive it. Most people end up with both wired into the same client.

Can an agent start a training run on its own?

It can call the tool, but the tool refuses until you have agreed to the cost: it takes a separate confirmation flag, and without it the call comes back as an error explaining that a run rents a GPU by the hour and bills the account. Treat it the way you would treat any command that spends money.

What can someone see with my API key?

Everything the key is scoped to, which is the account that created it: its datasets, its robots and its training jobs, and it can start runs that the account pays for. Keys are shown once when you create them in dashboard settings, so store the value in the client config and nowhere else.

Try it on a real arm before you wire anything up

There is a real SO-100 online that anyone can drive from the browser, with no signup and no hardware. It is the same arm the datasets and policies on this site were built around.

Download the client Open the live arm