Skip to main content
Glama
industrial-aiops

OT-AIops

by industrial-aiops
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

onboarding_config_draft

Read-only

Generate an onboarding config draft from a stored scan, marking confirmed endpoints and flagging unconfirmed fields for human review before merging.

Instructions

[READ][risk=low] The config.yaml endpoints a stored scan can justify.

Closes the gap where a site scanned forty devices and then retyped all forty
by hand. Reads a stored scan; writes nothing. `config.yaml` is edited by a
person, exactly as with `iaiops tags apply`.

**Every drafted field says whether the scan established it.** A field with
`value: null` was NOT established, and its `caution` says what it is waiting
for — do not fill one in and do not drop it. Dropping it lets the protocol
default apply in silence, which is how a Modbus gateway gets read at unit 1
and shows a confident number for the wrong machine. Carry the cautions to
whoever merges this; they are the content, not decoration.

**Only CONFIRMED protocols become endpoints.** An open port means something
is listening, not that it speaks the protocol; those hosts appear under
`skipped` with the reason. `limits` states what this draft structurally
cannot contain — a protocol's absence here is not evidence of its absence at
the site.

`tags` is always empty and this tool will not fill it. A scan finds devices;
which point means run state or good count is process knowledge, and a wrong
production counter yields a plausible OEE, which is worse than an error
(D16). That confirmation is a person's, via `iaiops tags export` / `apply`.

`scan_id` empty means the newest stored scan.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dbNo
scan_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.28.0

TDQS

A4.1/5.0
Behavior5/5

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

Even with readOnlyHint, openWorldHint, and destructiveHint annotations, the description adds substantial behavioral detail: null fields are NOT established and must not be dropped, only confirmed protocols become endpoints, open ports are listed under skipped, limits documents structural incompleteness, and tags will always be empty. It also directly states 'writes nothing', which matches the annotations and leaves no safety ambiguity.

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 long but organized with bold lead-ins and logical paragraphs, and nearly every section carries a necessary safety caveat. The opening sentence is a fragment, and the 'D16' internal reference plus the Modbus anecdote could be trimmed, so it is not maximally concise.

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?

With no output schema, the description does the needed work of explaining return semantics: drafted fields with value/caution, skipped hosts with reasons, limits, and empty tags. It also covers the human merge responsibility and scan_id defaulting. The main gap is the undefined db parameter, which leaves a small but real hole in an otherwise complete picture.

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?

The schema has zero parameter descriptions, so the narrative must carry meaning. The description does define scan_id's behavior ('scan_id empty means the newest stored scan'), which is genuinely useful, but it says nothing about the db parameter at all. This is meaningful but incomplete parameter coverage.

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?

The description identifies the resource as config.yaml endpoints justified by a stored scan and repeatedly clarifies the read-only drafting behavior ('Reads a stored scan; writes nothing', 'Every drafted field says whether the scan established it'). It lacks a crisp opening verb and does not contrast itself with sibling onboarding tools, 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?

The intended use case is clear: it closes the gap after a scan so devices do not need to be retyped by hand, and 'scan_id empty means the newest stored scan' gives a concrete default. It explains what not to expect (tags are always empty, unconfirmed protocols go to skipped), but it never explicitly names a sibling alternative or states when a different tool should be chosen instead.

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

Deploy Server

Other Tools