Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

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

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
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 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.

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

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.4/5.0

Scored across 6 tools

Disambiguation4/5

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).

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness4/5

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.

Maintenance

ActivityMaintained
ResponsivenessUnresponsive