hmc_systems

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

Annotations declare readOnlyHint=true, and the description adds meaningful behavior beyond that: it states that omitted system_name_or_uuid returns a list with UUID, SystemName, State, MTMS, IPAddress, etc.; provided returns full details dict or None; state filtering uses the HMC server-side search endpoint. This gives useful runtime context without contradicting annotations.

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

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

The description is front-loaded with the primary purpose, then structured as clear conditional paragraphs. Every sentence provides necessary operational detail—list fields, single-item return, None case, state filtering—without redundancy or filler.

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

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

With no output schema and 0% parameter schema coverage, the description fully compensates by describing return types (list, dict, None), entry fields, and the state filter behavior. It is complete for a read-only lookup tool across its three modes.

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

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

Schema description coverage is 0%, so the description carries full burden for both parameters. It explains system_name_or_uuid with its two modes (list vs. get by name/UUID) and state with its filter behavior when system_name_or_uuid is omitted. The only minor gap is that state values are not enumerated or formatted, but the semantics are clear.

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

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

The description opens with a specific verb+resource: 'List all managed systems or get one by name or UUID.' It clearly distinguishes between list-all and get-one behavior, and the parameter-dependent modes are explicit. This differentiates it from siblings like hmc_find_system and hmc_system_summary by scoping it to systems listing/detail.

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

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

The description provides clear when-to-use context by explaining behavior for each parameter combination: omit system_name_or_uuid to list, provide it to get one, and combine state with omission to filter. It does not explicitly mention alternatives or exclusions, but the conditional usage is well specified.

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