# OpenDeviceDB (npm · @opendevicedb/mcp)

Check 21,000+ devices with open firmware or protocols before reverse engineering one.

- Trust score: 77/100 (medium)
- Change this week: +3
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-11-05

## Components

- npm · `@opendevicedb/mcp`: 77/100 (this document), [markdown](https://verifymcp.io/servers/org-opendevicedb-opendevicedb/opendevicedb-mcp.md), [page](https://verifymcp.io/servers/org-opendevicedb-opendevicedb/opendevicedb-mcp)

## Channel facts

- Registry: `npm`
- Package: `@opendevicedb/mcp`
- Version: `0.3.0`
- Transport: `stdio`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-11-05.

- **Supply Chain Security**: 98/100
  - No malware found by supply-chain analysis.
  - No known CVEs affecting this package version or its production dependencies.
  - No install/post-install scripts declared.
  - 30 of 93 dependencies flagged as unhealthy.
- **Provenance & Transparency**: 45/100
  - Source repository is publicly reachable at the declared URL.
  - Provenance check failed: no build-provenance attestation is published.
  - Clear OSI-approved license (AGPL-3.0-or-later).
  - Actively maintained (last published 18 days ago).
  - Disclosure check failed: no security disclosure policy was found in the source repository.
- **Schema Quality & AI Usability**: 64/100
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 1437 tokens (~239/item across 6 items; 6 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 63/100
  - Stability observed for 19 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 100/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 100% of tool parameters carry a description.
- **Tool Safety**: 100/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - All 1 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation.
  - An AI judge read all 7 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## Install

### How do I install the OpenDeviceDB MCP server?

OpenDeviceDB runs locally as an npm package, launched with npx -y @opendevicedb/mcp. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

### Claude

```bash
claude mcp add org-opendevicedb-opendevicedb -- npx -y @opendevicedb/mcp
```

### Cursor

```json
{
  "mcpServers": {
    "org-opendevicedb-opendevicedb": {
      "command": "npx",
      "args": [
        "-y",
        "@opendevicedb/mcp"
      ]
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "org-opendevicedb-opendevicedb": {
      "command": "npx",
      "args": [
        "-y",
        "@opendevicedb/mcp"
      ]
    }
  }
}
```

### Codex

```bash
codex mcp add org-opendevicedb-opendevicedb -- npx -y @opendevicedb/mcp
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "org-opendevicedb-opendevicedb": {
      "type": "local",
      "command": [
        "npx",
        "-y",
        "@opendevicedb/mcp"
      ],
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add org-opendevicedb-opendevicedb --command npx --arg -y --arg @opendevicedb/mcp
```

### Hermes

```yaml
mcp_servers:
  org-opendevicedb-opendevicedb:
    command: "npx"
    args: ["-y", "@opendevicedb/mcp"]
```

### Netclaw

```json
{
  "McpServers": {
    "org-opendevicedb-opendevicedb": {
      "Transport": "stdio",
      "Command": "npx",
      "Arguments": [
        "-y",
        "@opendevicedb/mcp"
      ]
    }
  }
}
```

### Vellum

```bash
assistant mcp add org-opendevicedb-opendevicedb -t stdio -c npx -a -y @opendevicedb/mcp
```

### Other

```json
{
  "mcpServers": {
    "org-opendevicedb-opendevicedb": {
      "command": "npx",
      "args": [
        "-y",
        "@opendevicedb/mcp"
      ]
    }
  }
}
```

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-11-05 (score 77, +1)

No change was recorded against any check on this day. Stability & Change Management went from 60 to 63. That category is still filling its 30-day observation window: 18 days of observed history at the previous scan, 19 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-11-03 (score 76, +1)

No change was recorded against any check on this day. Stability & Change Management went from 53 to 57. That category is still filling its 30-day observation window: 16 days of observed history at the previous scan, 17 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-31 (score 75, +1)

No change was recorded against any check on this day. Stability & Change Management went from 43 to 47. That category is still filling its 30-day observation window: 13 days of observed history at the previous scan, 14 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-29 (score 74, +1)

No change was recorded against any check on this day. Stability & Change Management went from 37 to 40. That category is still filling its 30-day observation window: 11 days of observed history at the previous scan, 12 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-27 (score 73, +1)

No change was recorded against any check on this day. Stability & Change Management went from 30 to 33. That category is still filling its 30-day observation window: 9 days of observed history at the previous scan, 10 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-25 (score 72, +1)

No change was recorded against any check on this day. Stability & Change Management went from 23 to 27. That category is still filling its 30-day observation window: 7 days of observed history at the previous scan, 8 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-23 (score 71, +1)

No change was recorded against any check on this day. Stability & Change Management went from 17 to 20. That category is still filling its 30-day observation window: 5 days of observed history at the previous scan, 6 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-21 (score 70, +1)

No change was recorded against any check on this day. Stability & Change Management went from 10 to 13. That category is still filling its 30-day observation window: 3 days of observed history at the previous scan, 4 at this one. The score rises as the window fills, whether or not the server changes.

## MCP tools (6)

### `lookup_device` (~329 tokens)

Look up a device before reverse engineering it

CALL THIS FIRST, before you start reverse engineering any device (drone, camera, router, plug, robot, wearable...). It tells you whether the protocol or a free firmware already exists, whether someone is working on it right now (live claims), and gives a one-line recommendation (e.g. "open firmware exists: use X", "claimed by Y until Z: contact them"). Give identifiers when you have them (FCC id, USB vid:pid, BLE name, Zigbee model): they match better than names. The record's `install` routes (when present) say how to put the open firmware on the device: official guide, installer, difficulty, safety flags. If it answers found: false, nothing is known: call claim_device before starting.

Input parameters:

- `ble_name` (string): Bluetooth LE advertised name.
- `fcc_id` (string): FCC ID from the label, e.g. "SS3-NEO2". Identifiers are the most reliable match.
- `id` (string): OpenDeviceDB id (<vendor-slug>/<model-slug>) if you already have it, e.g. from search_devices.
- `model` (string): Model name as printed on the device or box, e.g. "Neo 2".
- `usb` (string): USB vendor:product id in lowercase hex, e.g. "2ca3:001f" (from lsusb).
- `vendor` (string): Manufacturer or brand, e.g. "DJI".
- `zigbee_model` (string): Zigbee modelId reported by the device.

### `search_devices` (~174 tokens)

Search the device directory

Ranked full-text search over vendor, model, aliases and identifiers across curated records and imported databases (OpenWrt, Zigbee2MQTT, Tasmota...). Use it to explore ("all DJI drones", "open-firmware cameras") or when lookup_device finds nothing and you suspect another name. Each result has an id to pass to lookup_device.

Input parameters:

- `category` (string): Restrict to one device category.
- `limit` (integer): Maximum results (default 20).
- `query` (string, required): Words to match: vendor, model, alias, or an identifier (FCC id, USB vid:pid, BLE name, chip, SKU). Empty string lists everything.
- `status` (string): Restrict to one effective status (unknown, in-progress, partial-protocol, controllable, open-firmware).

### `claim_device` (~337 tokens)

Claim a device you are about to reverse engineer

Record that you (your human) are working on a device, with a scope, contact and expiry (default 30 days, max 90), so other agents do not duplicate the work. Creates a stub record if the device is unknown (then give vendor, model, category). Writes data/devices/<id>.yaml in the local repository checkout (needs ODB_REPO); you then open a pull request — the result gives the exact commands.

Input parameters:

- `agent` (string): Agent/tooling used, e.g. "claude-code + rea 6.5.0".
- `category` (string): Required only when the device is not in OpenDeviceDB yet.
- `contact` (string, required): How others can reach the claimant: email, GitHub handle, URL of a tracking issue.
- `days` (integer): Claim duration in days (default 30, max 90). Expired claims are ignored.
- `force_new` (boolean): Create a new record even though a similar device exists (only if you are sure it is a different device).
- `id` (string): Device id if it already exists (from lookup_device/search_devices). Otherwise give vendor + model.
- `model` (string): Model name, used to build the id when the device is new.
- `scope` (string, required): What you will reverse engineer, e.g. "BLE pairing + telemetry", "full Wi-Fi control".
- `vendor` (string): Manufacturer, used to build the id when the device is new.
- `who` (string, required): Who is working on it: your human's name or handle (and project).

### `publish_findings` (~244 tokens)

Publish what you found

CALL THIS WHEN YOU FINISH (or stop) a reverse-engineering job, even with partial results. Merges your findings into the record: summary and status replace (status only moves forward), interfaces merge by transport+name (yours replace), projects by url, install routes by method+guide, identifiers and aliases are unioned, verification is appended. The result is validated against the schema; nothing is written on error. Link to your protocol docs/code hosted elsewhere; never include firmware images, vendor code, keys, or anything defeating Remote ID, geofencing or other safety functions (POLICY.md). Set provenance.ai_assisted honestly. Then open a pull request — the result gives the commands.

Input parameters:

- `allow_downgrade` (boolean): Allow lowering the status (only when the previous status was wrong; explain why in summary or verification notes).
- `id` (string, required): Device id (from lookup_device or claim_device).
- `patch` (object, required): Findings to merge into the record.
- `release_claim_of` (string): Remove the live claims of this claimant (the `who` you used in claim_device) now that the work is published.

### `request_device` (~198 tokens)

Request a device (say your user wants it)

Use when your user wants a device to become usable with open code but will not reverse engineer it themselves (lookup_device found nothing usable). Returns the existing request to add a 👍 to, or a pre-filled link to a new public GitHub issue that the user reviews and submits. Read-only: this tool never posts anything.

Input parameters:

- `ble_name` (string): Bluetooth LE advertised name.
- `fcc_id` (string): FCC ID from the label.
- `goal` (string): What your user wants to do with it, in their words (e.g. "fly it from Python now that the app is gone").
- `model` (string, required): Exact model name, e.g. "Bebop 2".
- `usb` (string): USB vendor:product id (lsusb).
- `vendor` (string, required): Manufacturer or brand, e.g. "Parrot".
- `zigbee_model` (string): Zigbee modelId.

### `list_sources` (~55 tokens)

List the databases OpenDeviceDB aggregates

Imported source databases with name, url, license, snapshot date and record count, plus the number of curated records. Use it to judge coverage and freshness: a device absent here may still be covered by a source that was not imported.

## Diagnostics

Captured diagnostic sections: Provenance, Dependencies. The full working is on the page: https://verifymcp.io/servers/org-opendevicedb-opendevicedb/opendevicedb-mcp#diagnostics

## Score history

- 2026-11-05: 77
- 2026-11-04: 76
- 2026-11-03: 76
- 2026-11-02: 75
- 2026-11-01: 75
- 2026-10-31: 75
- 2026-10-30: 74
- 2026-10-29: 74
- 2026-10-28: 73
- 2026-10-27: 73
- 2026-10-26: 72
- 2026-10-25: 72
- 2026-10-24: 71
- 2026-10-23: 71
- 2026-10-22: 70
- 2026-10-21: 70
- 2026-10-20: 69
- 2026-10-19: 69
- 2026-10-18: 68
- 2026-10-17: 53

## Common questions

### What is the OpenDeviceDB MCP server?

OpenDeviceDB is an MCP server listed in the public MCP registry as org.opendevicedb/opendevicedb. Check 21,000+ devices with open firmware or protocols before reverse engineering one. This page covers its npm package (@opendevicedb/mcp).

### Is the OpenDeviceDB MCP server safe to use?

OpenDeviceDB scores 77 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 5 November 2026. It declares no install or post-install scripts. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the OpenDeviceDB MCP server expose?

OpenDeviceDB exposes 6 tools: lookup_device, search_devices, claim_device, publish_findings, request_device, list_sources. Their descriptions and schemas cost roughly 1,337 tokens of context every time the server is loaded.

### Is the OpenDeviceDB MCP server still maintained?

OpenDeviceDB is still listed as active in the MCP registry. We last reached this channel on 5 November 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

### What licence is the OpenDeviceDB MCP server under?

OpenDeviceDB declares the AGPL-3.0-or-later licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.

## Links

- npm package: https://www.npmjs.com/package/@opendevicedb/mcp
- Socket report: https://socket.dev/npm/package/@opendevicedb/mcp
- Repository: https://github.com/opendevicedb/opendevicedb
- Website: https://opendevicedb.org/agents/
- Changelog RSS feed: https://verifymcp.io/servers/org-opendevicedb-opendevicedb/opendevicedb-mcp.xml
- Changelog JSON feed: https://verifymcp.io/servers/org-opendevicedb-opendevicedb/opendevicedb-mcp.json
- HTML version of this page: https://verifymcp.io/servers/org-opendevicedb-opendevicedb/opendevicedb-mcp