Skip to main content
Glama

create_device_input

Create or rotate an authenticated collector channel for this device. Ownership is checked before the app asks the input central. The server chooses the channel id and authenticates batches only against a hash of the collector credential. The whole setup this call returns — credential included — is also saved, encrypted with a key only the input central holds and bound to that credential, so the owner can read it again with GET /api/ambientes/:id/inputs/:collector/setup. The credential does not expire: a device that stays off for weeks reconnects with it. It stops working only when a new configuration rotates it or the channel is removed. A repeated call for the same collector rotates the credential, replaces the saved setup and replaces monitoring with the list sent — that is how the monitored scope is edited — so the configuration on the device stops authenticating until it is replaced; a paused channel stays paused. DNS selects the receiver; it never authenticates the device.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesDevice environment UUID v4; the report URL is a one-hour write capability.
collectorYesalloy, telegraf, opentelemetry, ncpa, collectd or snmp.
monitoringYesOne or more of system (the whole machine), host (CPU, memory, load and uptime), disk, network, mysql and asterisk. `system` already includes host, disk and network, and those three together are stored as `system`. Items the collector cannot collect (see `collects` on the channel) are not measured.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description carries the full behavioral burden and handles it thoroughly: ownership checks, server-chosen IDs, hash-only auth, encrypted saved setup, non-expiring credentials, rotation side effects, paused-channel behavior, and the fact that DNS never authenticates. This is exemplary disclosure for a mutation tool.

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

Conciseness4/5

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

The description is front-loaded with a clear purpose and every sentence carries relevant behavioral or security information. It is slightly verbose and dense, but for a security-sensitive create/rotate tool, the length is justified.

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

Completeness5/5

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

The description is complete enough despite no annotations and no output schema: it explains prerequisites, response contents, credential lifecycle, rotation consequences, and persistence behavior. An agent has sufficient context to invoke the tool correctly and anticipate side effects.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful parameter-level context: resubmitting for the same collector rotates the credential and replaces monitoring with the submitted list. This clarifies how the monitoring and collector parameters affect state beyond their schema descriptions.

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

Purpose5/5

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

The description states a specific verb and resource: 'Create or rotate an authenticated collector channel for this device.' It also clarifies the dual purpose—creation and rotation—which distinguishes it from sibling tools like delete_device_input or get_device_input_setup.

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?

The description gives clear context for when to use the tool, especially that a repeated call rotates the credential and edits the monitored scope. It does not explicitly name alternatives or say when not to use it, but the create/rotate/read/delete boundaries are inferable from sibling names and the described behavior.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources