Connect your agent to AY-Robots
One hosted endpoint. Point Claude Code, Claude Desktop or Cursor at it and your agent can read the robot learning guides, compare policies, look through your datasets and start a training run.
- Streamable HTTP
- JSON-RPC 2.0
- Protocol 2025-06-18
- 19 tools without a key
https://www.ay-robots.com/api/mcpWhat 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 start a training job and then poll 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 and the error message if it failed, 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.
Connect in one step
Pick your client, copy the block, done. The API key is optional everywhere: leave it out and you get the public tools, add it as a Bearer token and your account data comes with it.
Claude Code
Run this in the project you want the server available in. Claude Code writes the entry to its own MCP config, and "claude mcp list" shows it afterwards. For your datasets and training jobs, append --header "Authorization: Bearer ayr_live_your_key_here" to the same command.
claude mcp add --transport http ay-robots https://www.ay-robots.com/api/mcpClaude Desktop
The config file lives at ~/Library/Application Support/Claude/claude_desktop_config.json on macOS and %APPDATA%\Claude\claude_desktop_config.json on Windows. Restart the app after saving. Drop the headers block to stay on the public tools, or paste your key into it as a Bearer token. If your version does not read remote servers from that file, add the same endpoint under Settings, Connectors instead.
{
"mcpServers": {
"ay-robots": {
"type": "http",
"url": "https://www.ay-robots.com/api/mcp",
"headers": {
"Authorization": "Bearer ayr_live_your_key_here"
}
}
}
}Cursor
Put this in .cursor/mcp.json in the project root, or in ~/.cursor/mcp.json to have it in every project. Cursor picks the file up when you reload the MCP list in its settings. The headers block is optional and holds the API key as a Bearer token.
{
"mcpServers": {
"ay-robots": {
"url": "https://www.ay-robots.com/api/mcp",
"headers": {
"Authorization": "Bearer ayr_live_your_key_here"
}
}
}
}Raw JSON-RPC (curl)
No config file involved: this is the protocol itself, a JSON-RPC 2.0 tools/list call over Streamable HTTP. It prints every public tool with its input schema, which is the fastest way to prove the endpoint is reachable from your machine. Add -H "Authorization: Bearer ayr_live_your_key_here" and the account tools appear in the same list.
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"}'Clients that discover servers on their own can read /.well-known/mcp.json or /mcp.json. Both return the endpoint, the protocol version, the authentication model and every tool with its input schema.
Every tool on the server
19 of the 25 tools work without any authentication. The rest read or change data in one account and need a key.
| Tool | What it does | API key |
|---|---|---|
search_docs | 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. | Not needed |
list_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. | Not needed |
get_policy | 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. | Not needed |
compare_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. | Not needed |
list_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. | Not needed |
list_supported_robots | Short list of the supported robot arms with degrees of freedom and a one line note. Kept for compatibility with existing integrations; list_arms is the fuller answer and adds alternative names, servo type, operating voltage, approximate cost and support level. | Not needed |
list_guides | 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. | Not needed |
get_guide | 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. | Not needed |
diagnose_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. | Not needed |
list_fixes | 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. | Not needed |
get_fix | 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. | Not needed |
define_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. | Not needed |
list_terms | 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. | Not needed |
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. | Not needed |
get_live_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. | Not needed |
get_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. | Not needed |
list_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. | Not needed |
get_started_guide | 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. | Not needed |
get_pricing | Current AY-Robots pricing for training, inference and teleoperation. | Not needed |
list_datasets | List the datasets in the authenticated account, newest first. | Required |
get_dataset | Details for one dataset. Set include_download_url to get a time-limited link to the dataset archive. | Required |
list_robots | List the robots paired to the authenticated account, with their online status. | Required |
list_training_jobs | List training jobs for the authenticated account, newest first. | Required |
get_training_job | Full status of one training job, including metrics and error details. | Required |
start_training | Start a cloud training run on a dataset. THIS SPENDS REAL MONEY: it rents a GPU by the hour and bills the account. You must confirm with the user first and pass confirm_spend: true. Do not call this speculatively or to explore the API. | Required |
About the API key
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.
Documentation, policy facts, supported arms, training cost estimates, pricing and the live demo. Enough for an agent to explain the platform and recommend a model before anyone signs up.
Your datasets, your paired robots and your training jobs, plus the ability to start a run once you have confirmed what it costs. Remove the header from the config and the server drops back to the public tools.
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 and your training jobs.
Which clients work with this server?
Anything that speaks MCP over Streamable HTTP with JSON-RPC 2.0, which covers Claude Code, Claude Desktop, Cursor and anything built on an MCP 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.
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.
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.
Can the agent move my robot arm?
Not through this server. The hosted tools read documentation and account data and start cloud training, they do not command joint positions. To move an arm, use the desktop client on your own hardware, or drive the arm on /live in the browser.
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 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.