Docs / Contact / getting-started/local-dev-mcp

Build Faster with the Local Dev MCP Server

tendrl-dev-mcp is a local MCP server that lets your AI assistant (Claude Desktop, Cursor, VS Code with Copilot, or any MCP client) flash firmware, upload code, and provision MicroPython devices through natural language.

Paired with Contact's hosted MCP server, you can go from "I have a new ESP32 in my hand" to "my entity is registered, the device is flashed, the SDK is installed, and it's publishing validated messages" without leaving your editor.

Prefer a UI?

The same flashing, provisioning, and file-editing works without an AI assistant. Run tendrl-dev-mcp web for a local browser console, or open an MQTT entity in the Contact dashboard and use its Device tab (paste the entity's API key, or rotate it there if you lost it). See MicroPython Getting Started.

What it changes

Without the dev MCP, registering a new device looks like:

Open the dashboard, create an entity, generate an API key, copy it
pip install esptool, find the right firmware .bin, flash it
Open a serial REPL, write WiFi config + API key to the device
Clone the SDK, push files over serial
Write main.py, upload it, reboot

With the dev MCP plus the Contact MCP, you say:

"Set up this ESP32 as a temperature sensor that publishes to Contact every

30 seconds, with validation rules for temperature between -40 and 85."

…and the AI orchestrates the entity creation, key issuance, firmware flash, SDK install, config writing, and code upload across both servers.

Install

One command — it detects your platform, verifies checksums, and puts tendrl-dev-mcp on your PATH:

bash


# macOS / Linux
curl -fsSL https://app.tendrl.com/api/public/tools/dev-mcp/v1/latest/install.sh | sh

powershell


# Windows
powershell -c "irm https://app.tendrl.com/api/public/tools/dev-mcp/v1/latest/install.ps1 | iex"

Direct per-platform downloads are listed on the Resources page, alongside SHA256SUMS.txt for verifying one.

Single binary, no runtime deps. macOS, Linux, and Windows.

For firmware operations:

ESP32: pip install esptool
Pico W: brew install picotool (macOS) or apt install picotool (Linux)

Configure your MCP client

Point your client at the local binary plus the Contact hosted MCP server. Example for VS Code (.vscode/mcp.json):

json


{
  "servers": {
    "tendrl-dev": {
      "type": "stdio",
      "command": "/path/to/tendrl-dev-mcp"
    },
    "contact": {
      "type": "http",
      "url": "https://app.tendrl.com/contact/mcp",
      "headers": { "Authorization": "Bearer YOUR_CONTACT_API_KEY" }
    }
  }
}

Claude Desktop and Cursor use the same shape under their respective MCP config keys (mcpServers).

Tools you'll use most

The local dev server exposes hardware operations:

Tool	Use case
`list_serial_ports`	"What devices are plugged in?"
`detect_board`	Confirm board type and current MicroPython version
`flash_micropython`	Flash firmware to an ESP32 or Pico W
`install_client`	Install the Tendrl SDK over WiFi (mip)
`upload_sdk`	Install the Tendrl SDK over serial (no WiFi needed)
`write_config`	Write API key + WiFi credentials to the device
`upload_file`	Push application code
`run_script`	Execute MicroPython on the device, get stdout back
`reset_device`	Reboot
`serial_monitor`	Read serial output for debugging
`capture_frame`	"What is the camera looking at?" Returns a real image from an OpenMV board
`start_camera_preview`	"Let me watch the camera": live MJPEG at a local URL, over USB, no cloud
`stop_camera_preview`	Stop the preview, release the port
`start_serial_log`	"Let me watch the log": live device stdout at a local URL over USB
`stop_serial_log`	Stop the serial log, release the port
`provision_device`	Flash, configure, install, and verify a board in one call
`diagnose_device`	"Why is this device offline?" Checks board, config, WiFi, memory, serial

The Contact hosted MCP exposes create_entity, create_api_key, list_messages, register_device, and more, so the AI can do the account-side setup before touching hardware.

A typical first-device session

code


You: I have a fresh ESP32 plugged in. Set it up as the temperature sensor
     "kitchen-01" publishing to Contact, with WiFi creds for "MyNetwork".

AI:  [tendrl-dev: list_serial_ports] → /dev/cu.usbserial-0001
     [tendrl-dev: detect_board] → ESP32, no MicroPython
     [contact:    create_entity name=kitchen-01]
     [contact:    create_api_key entity=kitchen-01] → tk_abc123...
     [tendrl-dev: flash_micropython port=/dev/cu.usbserial-0001]
     [tendrl-dev: write_config api_key=tk_abc123... wifi_ssid=MyNetwork ...]
     [tendrl-dev: install_client] → SDK installed via mip
     [tendrl-dev: upload_file path=main.py content=...]
     [tendrl-dev: reset_device]
     [contact:    list_messages entity=kitchen-01] → first message received

That's a working device, registered and validated in Contact, in one prompt. No dashboard clicking, no copying API keys, no firmware lookups.

When to use it

Bringing up a new device for the first time
Re-flashing or recovering a misbehaving device
Provisioning a fleet: the AI can loop through every connected port
Debugging from your editor: run_script and serial_monitor give

you a REPL without leaving the chat

Iterating on main.py: the AI rewrites and uploads as you describe

changes in plain English

When it doesn't work

Almost every failure here is the serial port, not the board.

Symptom	Cause and fix
`list_serial_ports` shows nothing	The board isn't in a data-capable USB port, or the cable is charge-only. Try a different cable first — it is the single most common cause.
A tool fails saying the port is busy or in use	Something else still holds it: a camera preview, a serial log, an open REPL in another terminal, or a stray `mpremote`. Call `stop_camera_preview` / `stop_serial_log`, close other sessions, and retry.
Permission denied on `/dev/tty…` (Linux)	Your user isn't in the `dialout` group. Add yourself and log out and back in.
Flashing can't reach the boot ROM	The board needs to be in bootloader mode, and some boards need the BOOT button held while connecting.
Two probes in a row behave differently	Device state carries over between runs. Call `reset_device` between operations rather than assuming a clean slate.

For anything past the serial layer — a board that flashes fine but never appears online, SDK installs that fail over Wi-Fi, camera and provisioning errors — see Device troubleshooting, which covers those in depth.

Full reference

See the Local Dev Server reference for the complete tool list, board compatibility matrix, and full-stack configuration that adds Strand and Surface MCP servers for end-to-end workflow orchestration with security scanning.

← Back to Contact docs