Build your own functions

Publish device functions with bounded parameters, discover them through MCP, choose agent permissions and broadcast requests with separate results.

A function is something your device knows how to do: read a sensor, change a light, or update a display. openlaunch calls that function a capability in its API. You write the device code; openlaunch handles discovery, permission and delivery.

Add a function to your device adapter

Give the function a name, a short explanation, and a schema for its inputs. Include it in the manifest your adapter sends during pairing. For example, a lamp adapter can publish:

{
  "name": "desk lamp",
  "kind": "custom.sensor",
  "capabilities": ["device.health", "light.brightness"],
  "functions": [
    {
      "name": "light.brightness",
      "title": "Set brightness",
      "description": "Set this lamp's brightness from 0 to 100.",
      "access": "write",
      "inputSchema": {
        "type": "object",
        "properties": {
          "value": { "type": "integer", "minimum": 0, "maximum": 100 }
        },
        "required": ["value"],
        "additionalProperties": false
      }
    }
  ]
}

kind identifies the adapter’s device family. Use a built-in kind for a supported profile or a lower-case custom kind such as custom.sensor. Custom kinds are limited to 64 characters, start with a letter, and use lowercase letters or digits separated by single dots or hyphens. The bridge accepts custom kinds without requiring a service release. Your adapter must implement every advertised function and report its result. A manifest describes code; it does not install code or add a circuit. The built-in Pi integration reports health. The built-in Uno R4 integration implements health, LED and matrix text. Extend the Pi adapter source or Uno sketch for additional hardware behavior.

Capability names use lowercase dot-separated segments, for example sensor.temperature or light.brightness. Inputs support booleans, bounded numbers or integers, and strings with a maximum length and optional choices. Use at most 16 named parameters and 16 functions per device. External schema references and executable input schemas are rejected. Standard function names cannot be overridden. Capability names identify operations; they do not add implementations to your adapter.

Use it in the console

After pairing your adapter, its function appears on the device card with a form based on its schema. Choose the parameters and run it. The receipt starts queued; inspect its result after the device polls.

Create a named connection in Agents and issue a bridge SDK token for the agent. The secret is shown once and can be revoked or replaced there. Then grant that connection only the functions it needs on each device, with an expiry. Token validity alone does not grant access to a device. Approved custom functions appear in the agent’s MCP tools automatically. Their names identify the device as well as the function. Revoking a grant also blocks an already-discovered tool from running. See the Device and agent SDK guide for SDK usage and the agent guide for MCP clients.

Firmware or adapter changes require a matching manifest. SDK adapters can call publishManifest(manifest) after implementing their functions. Changed manifests clear existing grants and cancel queued actions, so owners approve the updated functions before agents can use them. Requests already delivered become uncertain; publishing a manifest cannot undo a physical action. Changing a device’s kind requires a new enrollment.

Broadcast to several devices

Use Broadcast a function in the console. Choose devices, then choose a function they all publish. Each device gets its own command, permission check, expiry and receipt. A rejection on one device does not make another device’s completed action disappear.

Developers can use the SDK’s broadcast() method or POST /v1/broadcasts with deviceIds, capability, arguments, idempotencyKey and ttlSeconds. Responses contain an action or an error for each device. Retrying the same request with the same key reuses each existing action. A broadcast is not an atomic hardware operation: inspect each result.

Read the API guide and pairing rules when building a new adapter. Keep the repaired Uno’s console UART profile separate from stock firmware; see the Uno guide.