For AI agents

Reverse engineering with an agent is cheap; doing it twice is waste. Give your agent the OpenDeviceDB MCP server and it will check the directory before it starts, claim the device while it works, and publish what it found when it is done.

Install the MCP server

Claude Code, with the published package (read-only, queries this website):

claude mcp add opendevicedb -- npx -y @opendevicedb/mcp

From a checkout (works today, and is the mode that can write claims and findings):

git clone https://github.com/opendevicedb/opendevicedb
cd opendevicedb && npm install
claude mcp add opendevicedb -e ODB_REPO="$PWD" -- node "$PWD/packages/mcp/src/server.ts"

Node 22.18+ runs the TypeScript sources directly. npm run mcp starts the same server on stdio.

Remote, read-only mode

Without a checkout, point the server at this website's static API with ODB_API_URL. Lookups and searches work; claims and publications need a checkout (ODB_REPO), because writes go through a pull request.

claude mcp add opendevicedb -e ODB_API_URL=https://opendevicedb.org -- npx -y @opendevicedb/mcp

Other MCP clients (Claude Desktop, Cursor, Codex…) take the same server in their JSON config:

{
  "mcpServers": {
    "opendevicedb": {
      "command": "npx",
      "args": [
        "-y",
        "@opendevicedb/mcp"
      ],
      "env": {
        "ODB_API_URL": "https://opendevicedb.org"
      }
    }
  }
}

If both are set, ODB_REPO wins. With neither, the server reads the checkout it runs from.

The workflow

1. Look up — lookup_device with every identifier you have (FCC ID, USB vid:pid, BLE name, Zigbee model, then vendor + model). It says what exists, who is working on it, and what to do next. search_devices explores by name.
2. Claim — nothing usable exists? claim_device with who you are, a contact, the scope ("BLE control protocol") and a duration (30 days by default, 90 max). Others now see the device as in progress.
3. Work — capture, decode, write the SDK or firmware. Host the code and docs in your own repository under an open license.
4. Publish — publish_findings merges interfaces (with an honest confidence), projects, identifiers and verification into the record, validates it against the schema, and refuses content the policy excludes. Flag provenance.ai_assisted truthfully. Publish partial results too: a documented telemetry channel already saves the next person a week.
5. Pull request — the tool prints the exact git / gh pr create commands. A human reviews, CI validates, and the record goes live on the next build.

What agents should know

• Records from imported databases are slim: a name, a status and a link back. Follow the link.
• AI output is not trusted by default. "Verified on hardware" means a replayable test (hardware-replay) was run on a real device with a stated firmware version — nothing less.
• Claims expire. An expired claim is ignored; a live one comes with a contact — use it before duplicating the work.
• Never publish firmware images, vendor code, keys, or anything defeating Remote ID, geofencing, radio limits or other safety functions.

Static API

The same data, as plain JSON (what the server reads in remote mode):

• /api/index.json — every device: id, vendor, model, aliases, category, status, sources, identifiers, claims, verified, updated
• /api/devices/<vendor>/<model>.json — the full merged record, e.g. /api/devices/ryze/tello.json
• /api/sources.json — imported sources with licenses, snapshot dates and counts

The agent skill file shipped with the server (packages/mcp/SKILL.md) is CC0, so other tools can embed it.