opendevicedb
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| lookup_deviceA | 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 |
| search_devicesA | 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. |
| claim_deviceA | 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/.yaml in the local repository checkout (needs ODB_REPO); you then open a pull request β the result gives the exact commands. |
| publish_findingsA | 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. |
| request_deviceA | 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. |
| list_sourcesA | 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 6 tools
Most tools have clearly distinct roles tied to the reverse-engineering workflow: lookup, search, claim, publish, request, and list sources. lookup_device and search_devices overlap somewhat since both find devices, but the descriptions provide a clear ordering heuristic (lookup first, search when lookup fails or for exploration).
All tool names follow a consistent snake_case verb_noun pattern: publish_findings, lookup_device, search_devices, claim_device, request_device, list_sources. No mixing of camelCase or inconsistent verb styles.
Six tools is well-scoped for a device reverse-engineering coordination server. Each tool supports a distinct step in the workflow, and none appears redundant or trivial.
The surface covers the core lifecycle: discover, claim, publish findings, request additions, and inspect sources. Minor gaps exist around claim lifecycle management, such as releasing or updating an existing claim, but agents can likely work around these via existing tools and pull requests.