YotoMCP Local
This server provides local Yoto account authentication and read-only MYO card/device access via MCP.
Start and complete the Yoto OAuth Authorization Code + PKCE login flow locally.
Check local authentication status without exposing tokens.
Log out by deleting the local token record.
List the authenticated user's MYO cards.
Retrieve a single MYO card by ID.
List linked Yoto players and their status.
No write, delete, or upload tools are exposed in this schema.
Click on "Deploy 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., "@YotoMCP Local list my Yoto cards"
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.
YotoMCP Local
A security-focused local Yoto MCP server using Yoto's official TypeScript SDK and the official OAuth Authorization Code + PKCE flow.
0.2.0
This release adds resumable operations, job manifests, card fingerprints and dry-run previews, bounded background progress, and deterministic resolution of existing Yoto user/public icons. It does not upload generated images.
Related MCP server: mcp-yoto
Security design
MCP stdio only; no HTTP listener is exposed.
The login callback binds only to
127.0.0.1and validates the OAuthstateand PKCE verifier.Tokens are stored locally with a 0700 directory and 0600 file; tools never return tokens.
Read-only tools are enabled by default.
Write operations require
YOTO_ENABLE_WRITES=true.Uploads additionally require
YOTO_AUDIO_ROOT, reject symlink escapes, accept only MP3/M4A files, and enforce a size limit.Icon resolution reads existing Yoto user/public catalogs; it does not upload icon files.
Card updates verify expected snapshots and read back the resulting audio/icon references.
Presigned uploads require HTTPS, reject redirects, and never attach a Bearer token.
Multiple accounts are not supported, reducing accidental cross-account operations.
Available Tools
Tool name | Description |
| Start the local Yoto Authorization Code + PKCE login flow and return the browser URL. |
| Complete the pending PKCE login after the browser redirects to the local callback. |
| Show local authentication status without returning tokens. |
| Delete the locally stored Yoto token record without calling a remote API. |
| List the authenticated user's MYO cards. Read-only. |
| Retrieve one MYO card by ID. Read-only. |
| List linked Yoto players and their status. Does not control or modify devices. |
| Create an empty MYO card. Disabled by default; requires |
| Permanently delete an MYO card. Disabled by default; requires |
| Upload an MP3/M4A file from |
| Create a playlist from local audio and resolve existing Yoto icons by title. |
| Start a resumable append operation and return an |
| Read background operation progress and per-track status. |
| Request cancellation of a background operation. |
| Read a local resumable job manifest. |
| Destructively remove chapters after an expected count with exact confirmation and readback. |
Build
Node 20+ is required. First create a Public Client in the Yoto Developer Dashboard and register:
http://127.0.0.1:8787/callback
npm ci --ignore-scripts
npm run typecheck
npm run buildTest
Run the offline test suite and dependency audit:
npm run checkThe tests do not authenticate with Yoto or call the Yoto API. They cover safe configuration defaults, conditional write-tool exposure, delete confirmation, token-file permissions and removal, and audio path restrictions.
Run
YOTO_CLIENT_ID='your-public-client-id' node dist/index.jsAfter startup, call yoto_auth_start to receive the login URL. Complete login in the browser, then call yoto_auth_complete.
To enable writes and audio uploads:
YOTO_CLIENT_ID='your-public-client-id' \
YOTO_ENABLE_WRITES=true \
YOTO_AUDIO_ROOT="$HOME/YotoAudio" \
YOTO_MANIFEST_ROOT="$HOME/YotoJobs" \
node dist/index.jsWhen writes are enabled, the OAuth client must allow user:content:view,
user:content:manage, user:icons:manage, family:devices:view, and
offline_access. Existing tokens may require a new OAuth consent after scope
changes.
Before production use, validate with a test account, test cards, and a dedicated audio directory. Never place a client secret, access token, or refresh token in configuration files, the repository, MCP messages, or logs.
Available Tools
7 toolsyoto_auth_completeA
Finish the pending local PKCE login after the browser callback arrives.
Inputs: no named parameters.
yoto_auth_startA
Start Yoto Authorization Code + PKCE login. Open the returned URL, then call yoto_auth_complete.
Inputs: no named parameters.
yoto_auth_statusARead-only
Show whether this local server has a Yoto refresh token, without returning the token.
Inputs: no named parameters.
yoto_get_cardARead-only
Read one MYO card by ID. No write operation.
Inputs: cardId (required).
yoto_list_cardsARead-only
Read the authenticated user’s MYO cards. No write operation.
Inputs: no named parameters.
yoto_list_devicesARead-only
Read linked Yoto player names and status. Does not control or modify devices.
Inputs: no named parameters.
yoto_logoutADestructive
Delete the local Yoto token record. This does not call a remote API.
Inputs: no named parameters.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 7 tools
Each tool has a clearly distinct purpose: auth workflow steps are separate, card operations are get vs list, device listing is unique, and logout is standalone. No two tools could be confused.
All tools use snake_case with a yoto_ prefix, but the auth tools vary in structure (auth_status, auth_complete, auth_start) while others follow verb_noun (get_card, list_cards, list_devices). Minor deviation from a uniform verb_noun pattern.
Seven tools are well-scoped for a local Yoto integration focused on authentication and read-only access. Each tool earns its place without redundancy.
The auth lifecycle (start, complete, status, logout) is fully covered, and read operations for MYO cards and devices are present. Minor gaps include no search/filter for cards and no detailed device inspection, but the core read-only scope is well served.
Maintenance
Related MCP Connectors
MCP server for Yoto: manage cards, tracks, icons and family devices from any MCP client.
Manage Fly.io apps, Machines, volumes, secrets, Managed Postgres, and Sprites with OAuth.
OAuth 2.1 short-link tools for AI agents with scoped tokens, approvals, audit logs, and revocation.
Four public utilities plus seven OAuth-protected Remote read tools for paired Nymrel devices.
Related MCP Servers
- AlicenseAqualityDmaintenanceEnables audio uploads and MYO card creation for Yoto players directly from the terminal, using OAuth authentication and Warp AI integration.63MIT
- FlicenseNot gradedqualityBmaintenanceConnects a Yoto library to Claude and ChatGPT so parents can browse and build MYO cards, add tracks, set pixel-art icons, and check player status through natural language. It handles Yoto sign-in via OAuth and stores tokens encrypted so nothing readable is retained.-
- FlicenseNot gradedqualityAmaintenanceExposes an OAuth-gated suite of 38 tools that let web-based AI chat clients securely operate a local machine, covering files, shell, search, Git, SQLite, browser automation, DevTools, background tasks, localhost services, clipboard, notifications, ports, and Postman. A strict command whitelist and configurable folder allowlist keep that broad local access governed rather than unrestricted.-
- FlicenseNot gradedqualityAmaintenanceExposes an OAuth-gated suite of 38 tools that lets web-based AI clients read and edit files, run whitelisted shell commands, search content, use Git and SQLite, drive browsers and DevTools, and reach localhost or LAN services, clipboard, notifications, ports, Postman, and long-running background tasks on your own machine. Everything runs locally with security controls such as folder scoping, command whitelisting, rate limits, and a call log.-