Skip to main content
Glama

Physical Capability Cloud

by network.capability
OverviewDiscussionsAdmin

setup_register_device

Register a device in the database with adapter config and capabilities. Part of Step 3 in the onboarding flow. Required: kernelId, deviceId, type and adapterType (400 missing_required_fields otherwise).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
typeYesDevice role: machine, sensor or camera (the values setup_generate_config and setup_validate accept)
modelNoDevice model identifier (optional; stored as "unknown" if absent)
deviceIdYesYour ID for this device, unique within the kernel
kernelIdYesKernel ID to register the device under
adapterTypeYesOne of octoprint, modbus, opcua, sila, ipp, generic-http or mock; the route refuses anything else (including opentrons)
capabilitiesNoCapability types this device serves
adapterConfigNoAdapter-specific configuration (host, port, auth, etc.)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • changedInput schema / properties / adapterType / description
      Previous value: -"Adapter type: octoprint, modbus, opcua, sila, opentrons, generic-http"New value: +"One of octoprint, modbus, opcua, sila, ipp, generic-http or mock; the route refuses anything else (including opentrons)"
    • addedInput schema / properties / capabilities
      Added value: +{
+  "description": "Capability types this device serves",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • addedInput schema / properties / deviceId
      Added value: +{
+  "description": "Your ID for this device, unique within the kernel",
+  "type": "string"
+}
    • changedInput schema / properties / model / description
      Previous value: -"Device model identifier"New value: +"Device model identifier (optional; stored as \"unknown\" if absent)"
    • changedInput schema / properties / type / description
      Previous value: -"Device type (e.g. fdm-printer, cnc-mill, hplc)"New value: +"Device role: machine, sensor or camera (the values setup_generate_config and setup_validate accept)"
    • changedInput schema / required
      Previous value: -[
-  "kernelId",
-  "type",
-  "model"
-]New value: +[
+  "kernelId",
+  "deviceId",
+  "type",
+  "adapterType"
+]
  2. First observed

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=false and destructiveHint=false, so the mutation/safety profile is known. The description adds error behavior for missing required fields ("400 missing_required_fields"), but does not cover auth requirements, duplicate deviceId handling, or idempotency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with purpose, then onboarding context, then required fields. No redundant or filler content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter nested registration tool with annotations and no output schema, the description supplies purpose, onboarding step, and required-field error behavior. It could mention downstream activation/approval or duplicate handling, but it is largely complete for invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with each property documented, including allowed adapterType values. The description only repeats required parameter names and the missing-fields error, adding no syntax or format detail beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb and resource ("Register a device in the database") plus scope (adapter config and capabilities). It does not explicitly distinguish itself from setup_validate, setup_generate_config, or other registration siblings, so it falls short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear onboarding context ("Part of Step 3 in the onboarding flow"), but no explicit when-not guidance or alternatives among the setup_* and registration tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Physical Capability Cloud toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources