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

Annotations already cover read-only, idempotent and closed-world, so the bar is lower. The description still adds real value beyond them: it discloses that pending changes for the next reboot are included in the response, and warns that describe=true is 'slow the first time' — a performance trait not present in any structured field.

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?

Two sentences, zero filler. The core read behavior leads, and the conditional describe behavior with its performance caveat follows in a parenthetical that stays out of the way.

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 no annotations about return size, the description carries the return-value burden and does say what the payload contains. It doesn't say whether omitting all filters returns every BIOS attribute, which matters for a potentially large read.

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 coverage is 100%, so baseline is 3; the description goes beyond by framing the filters as two modes (free text vs exact names) and by tying describe=true to its cost and to what it adds (allowed values and help text). It stops short of showing how the filters combine.

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?

States a specific verb ('Read') and resource ('current BIOS settings'), and enumerates what comes back: attribute names/values plus pending-for-next-reboot changes. The resource is naturally distinct from siblings like idrac_boot_settings, though no sibling is named explicitly.

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 implies when the two filter modes apply ('filtered by text or exact names') and when to set describe=true, but it never says when to use this tool over idrac_boot_settings or idrac_get, nor any exclusions. Usage is inferable rather than stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered. The description adds real value beyond that by enumerating what is returned (boot mode, boot order, override targets such as PXE, virtual CD, BIOS setup), which is not in any structured field.

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?

A single front-loaded sentence that puts the primary content (boot mode, boot order) ahead of the secondary detail (override targets). Slightly list-dense with the parenthetical examples, but nothing is wasted.

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 input parameters and no output schema, the description must carry the return-value burden, and it does so by naming the three pieces of information returned. Adequate for the tool's simplicity, with only the sibling differentiation left unaddressed.

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?

The tool takes zero parameters, so the baseline is 4. The description correctly implies a no-argument inspection call and does not invent parameter semantics that don't exist.

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?

States a specific verb 'Show' and enumerates the exact resources returned: boot mode (UEFI/BIOS), boot order, and one-time boot override with targets. Clear on its own, but does not distinguish itself from the nearby idrac_bios_attributes sibling, which an agent could plausibly confuse with boot configuration.

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?

Usage is only implied by the read-only 'Show' framing; there is no explicit when-to-use or when-to-prefer-idrac_bios_attributes guidance. An agent must infer that this is the boot-configuration inspection call rather than the general BIOS attribute call.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description reinforces this with 'no settings change' while adding genuinely new facts: it runs as a short export job and takes 30-120 seconds, which matters for timeout planning. It does not cover failure modes (e.g. what happens if save_path exists) though that constraint lives in the schema.

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?

Three compact sentences, front-loaded with what gets exported, then uses, then runtime/cost. No filler, though the thermal-profile clause is slightly parenthetical and could be trimmed.

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?

There is no output schema, but the description characterizes the return payload ('every setting as XML') and the duration, which is the operationally important unknown. Minor gap: it doesn't note that the response may be truncated by max_chars or saved to disk via save_path, leaving that to the schema.

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 100%, and each parameter's enum and truncation semantics are already documented there. The description contributes only the implicit XML emphasis, so the baseline of 3 applies.

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?

States a specific verb and resource ('Export the Server Configuration Profile') and enumerates exactly what is included: 'every iDRAC, BIOS, NIC and RAID setting as XML'. This clearly separates it from sibling readers like idrac_get, idrac_bios_attributes or idrac_thermal, which cover narrow slices.

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?

Gives concrete use cases: backup, settings comparison, and reading iDRAC settings such as thermal profiles that 'have no other Redfish view'. That implicitly routes the agent here over the narrow per-component siblings, but there is no explicit when-not guidance or named alternative.

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

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

Annotations already establish this as a safe, idempotent, closed-world read, so the description doesn't need to re-argue safety. It does add a genuinely non-obvious behavioral fact — that rollback/previous versions are suppressed by default — which an agent would otherwise have to infer from the schema default. It doesn't mention result shape or volume, but with annotations carrying the safety profile this is solid.

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?

Two sentences, zero filler, with the coverage scope front-loaded and the non-obvious filtering caveat immediately after. Nothing to trim.

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?

For a two-optional-parameter read tool with no output schema, the description covers what is queried and the key filtering default. It would be slightly stronger if it sketched the returned fields (component name / version) so the agent knows what it can do with the list, but nothing essential to correct invocation is missing.

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 coverage is 100% and both parameters are documented in the schema itself, so the baseline applies. The description restates the include_previous default behavior and leaves the `search` parameter ('name or version contains this text') entirely to the schema, adding little beyond structured data.

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?

States a specific verb (List) and a well-defined resource (firmware versions) and enumerates exactly which components are covered — iDRAC, BIOS, Lifecycle Controller, RAID, NICs, disks, PSUs. This clearly separates it from siblings like idrac_bios_attributes (settings) or idrac_storage (hardware detail), which report different data even when they touch the same component.

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?

Usage is implied by the enumeration and there is no competing firmware tool among the siblings, but the description never states when to reach for this versus, say, idrac_system_overview or idrac_health. No exclusions or prerequisites are given.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds the non-obvious behavioral fact that responses are JSON and are silently truncated at max_chars, which is important because truncation can produce incomplete data. It doesn't describe how errors or unsupported $expand/$select are reported.

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?

Three short sentences, front-loaded with purpose, followed by the routing rule and the output contract. No filler or restatement of the title.

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, the description carries the burden of describing returns and does so (JSON, truncated). For a generic read tool with rich annotations and fully documented params, what's left out (error semantics, whether truncation is signaled in the response) is minor but noticeable.

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 100%, so all four parameters (path, expand, select, max_chars) are already documented with formats and defaults. The description reinforces the path example and the truncation role of max_chars but adds no syntax or constraint information beyond the schema. Baseline 3 applies.

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?

States a specific verb and resource ('GET any Redfish resource on the iDRAC by path') and includes a concrete example path. The phrase 'use it for data the dedicated tools do not cover' explicitly positions it relative to the many sibling idrac_* helpers.

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?

Gives a clear selection rule: reach for this when the dedicated tools don't cover the data, which is exactly the fallback role a generic GET plays among 17 domain-specific siblings. It stops short of naming preconditions such as authentication needs or what to do when a path returns an error.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds meaningful behavior beyond that: results are filtered to non-healthy findings only, and the response includes recent warning/critical SEL events — telling the agent how to interpret an empty result. It doesn't mention latency of the full sweep (the schema notes storage is slower).

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?

A single well-formed sentence that front-loads the covered subsystems and ends with the returned output. No filler and nothing restated from the title.

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, the description carries the burden of describing return content and does so: unhealthy findings plus recent SEL events. Minor gap — it doesn't state what an all-clear response looks like (e.g., empty list) or how long a full sweep takes, though the schema hints at the storage cost.

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 100%, so both parameters (recent_events, include_storage) are fully documented in the schema itself. The description gestures at the events portion ('most recent warning or critical events') but adds no semantics beyond the schema, so baseline 3 applies.

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?

States a specific verb and scope: check every subsystem (CPUs, memory, fans, temperatures, power supplies, voltages, storage) and return only unhealthy items plus recent SEL events. This clearly distinguishes it from the per-subsystem siblings (idrac_thermal, idrac_power, idrac_storage) which cover one area each.

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 unhealthy-only filter plus recent warning/critical events establishes a clear triage use case, and 'list only what is not healthy' implicitly steers an agent here rather than to full-inventory siblings. It stops short of explicitly naming alternatives like idrac_status or idrac_logs or stating when not to use it.

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

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

Annotations already declare readOnlyHint, idempotentHint and closed-world, so the safety profile is covered. The description adds that results carry state and progress, but says nothing about ordering, pagination behavior, or what happens when job_id is invalid/absent.

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?

A single front-loaded sentence covering both modes with no filler. Slightly dense — the parenthetical list could read as scope detail rather than example — but nothing is wasted.

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?

For a simple read-only list tool with a fully described 3-parameter schema and annotations covering safety, this is nearly sufficient; the added 'state and progress' note tells the agent what fields matter. Only pagination/ordering and error behavior are left unstated.

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 coverage is 100%, so limit, state and job_id are already fully documented in the schema. The description only hints at the state and job_id modes without adding format or interaction details beyond the schema, so baseline 3 applies.

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?

States a specific verb and resource ('List the iDRAC job queue') and enumerates the job categories it covers (BIOS/RAID config, firmware updates, exports). No sibling tool touches jobs, so the agent can place it instantly.

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 'or get one job by id' clause implies the two modes, so the agent can infer list vs. single-fetch usage. It does not say when to prefer this over alternatives (e.g. logs) or note any prerequisites, leaving usage only implied.

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

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

Annotations already cover the safety profile (readOnly, idempotent, closed-world), and the description adds genuine behavioral context: results are ordered newest-first and scoped to recent entries. It doesn't add pagination behavior or note that filtering happens server-side, keeping it from a 5.

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?

A single front-loaded sentence with the tool's core action and read-order first, followed by the two log options and filters. The parentheticals carry real disambiguating value rather than 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, the description conveys enough (recent, newest-first entries from two log types, filterable) to call it correctly. It omits entry shape/fields, a minor gap for a read-only log tool.

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 coverage is 100%, so the schema already documents all four parameters including defaults, the 1-200 limit range, and the severity enum. The description only echoes the severity/text filtering, adding little semantic detail beyond the schema — baseline 3 applies.

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?

States a specific verb ('Read recent entries') plus the two concrete resources ('sel' and 'lclog') and even disambiguates what each log contains (hardware events vs configuration changes/firmware/jobs). No sibling tool offers log reading, so the distinction is immediate.

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 of what each log holds gives the agent a clear basis for choosing 'sel' vs 'lclog', and it names the filtering options. It stops short of explicitly comparing against siblings like idrac_health or idrac_status for troubleshooting, so it falls just short of a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered structurally. The description adds genuine value beyond that by disclosing the payload's contents (services with ports, NTP, session count), which is the main unknown for a no-output-schema getter. It does not mention auth or permission requirements, keeping it below a 5.

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?

A single sentence, front-loaded with the subject ('Details of the iDRAC itself') followed by a compact enumeration of return fields. No filler, no repetition of the title, and every clause carries payload information.

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, the description correctly shouldered the burden of explaining return values and did so field by field. For a trivial no-arg read-only getter, that is nearly all the agent needs; only the distinction from sibling info getters remains unaddressed.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a 0-param tool applies. No parameter-related claims are needed or missing.

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?

Names the specific resource (the iDRAC controller itself, not the host server) and enumerates the exact data returned: firmware, date/time, enabled network services with ports, NTP servers, and open Redfish session count. An agent can tell this is the management-controller metadata getter. It stops short of explicitly distinguishing itself from overlapping siblings like idrac_firmware_inventory or idrac_network_interfaces.

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?

Usage is only implied — 'Details of the iDRAC itself' hints that this is the place for controller-level metadata rather than host hardware data, but there is no explicit when-to-use statement, no exclusion of near-neighbors, and no prerequisites. The agent must infer selection from the sibling list alone.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description still adds real behavioral context beyond them: the default filtering rule that empty DIMM slots are suppressed unless include_empty is true, plus the exact result fields. It does not mention pagination or error/auth conditions, but neither is material for a single-flag read.

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?

Two sentences, zero filler: the first establishes scope and returned fields, the second covers the one behavioral modifier. Information is front-loaded so an agent can decide after the first clause.

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?

For a one-parameter, read-only list tool with no output schema, the description enumerates the returned fields and the default filtering behavior, which is everything needed to call it correctly and interpret the result. Nothing material is left unspecified.

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 coverage is 100% and the single parameter is documented, so the baseline is 3. The description adds value beyond the schema by explaining the observable consequence of the flag ('Empty slots are hidden unless include_empty is true'), making the default behavior explicit rather than just restating the flag name.

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?

States a specific verb+resource ('List memory modules (DIMMs)') and enumerates exactly which attributes come back (slot, size, type, speed, manufacturer, part number, health). The resource is unambiguous relative to siblings like idrac_processors or idrac_storage, though no sibling is named explicitly, so it falls just 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.

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

Usage is only implied: it's clearly a hardware-inventory read, and the include_empty sentence tells you how to see empty slots. There is no explicit when-to-use/when-not or pointer to alternatives such as idrac_system_overview for aggregate hardware summaries, leaving the agent to infer routing.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds value by enumerating the data categories returned (MAC, link state, speed, IP, gateway, DNS, host name), which matters because there is no output schema, but it says nothing about pagination, empty results, or failure modes on unreachable controllers.

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?

A single front-loaded sentence with two parenthetical field lists — no preamble, no repetition, nothing to trim. Slightly dense, but every clause carries information.

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 no parameters, the description is the only source of return-value information, and it names the concrete fields an agent will get. It falls short of 5 only because it doesn't note the two-part shape of the response (physical ports vs. iDRAC settings object) or behavior when a domain is unreachable.

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?

The tool takes zero parameters, so the baseline is 4. The description correctly frames this as a whole-server snapshot rather than implying any filtering argument that an agent might otherwise try to supply.

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 uses a specific verb ('List') on two clearly named resources: the server's physical network ports and the iDRAC's own network configuration. It does not differentiate itself from a likely-overlapping sibling such as idrac_manager_info, which could also expose iDRAC network settings.

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?

Usage is only implied — an agent can infer 'call this when you need MAC/link/speed or IP/gateway/DNS data', but there is no explicit when-to-use, when-not-to-use, or pointer to an alternative sibling for related manager configuration.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so the safe-read profile is covered structurally. The description contributes the data inventory (consumption stats, cap, per-supply model/capacity/voltage/firmware/health, redundancy), which is useful payload context but not behavioral. It doesn't note iDRAC-version variability, latency, or whether data is live vs. cached, which for a controller-status call would matter.

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?

One dense, front-loaded sentence with no filler; the parenthetical attribute list is efficient. Slightly list-heavy, but every clause maps to returned data.

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, the description does the important work of enumerating the returned fields, so an agent knows what it will get back. Combined with annotations and a fully documented optional parameter, only the version-dependence of the voltage sensors is left implicit.

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 coverage is 100% and the single parameter's own description already explains the iDRAC 8 power-good nuance. The description adds only 'Optionally the voltage sensors,' essentially restating the flag. Baseline 3 is correct when the schema fully carries parameter meaning.

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 enumerates exactly what the tool returns: current/average/minimum/peak power consumption, power cap, power supplies with their attributes, and optional voltage sensors. That is specific enough to separate it from siblings like idrac_thermal or idrac_health. It lacks an explicit verb ('get/read'), but the resource scope is unambiguous.

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?

Usage is only implied by the content: an agent can infer it should call this when it needs power draw or PSU data. There is no explicit statement of when to prefer it over idrac_thermal (temperature) or idrac_health, and no exclusion or prerequisite guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so the safety profile is covered. The description adds only the shape of the returned data (model, cores, threads, speed, health); it says nothing about auth requirements, empty/absent CPU handling, or pagination, which is acceptable given the annotation coverage but not rich.

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?

One sentence, front-loaded with the action and resource, with the field list as trailing detail. Nothing redundant and nothing padded.

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?

There is no output schema, so the description carries the burden of describing return values — and it does so by naming the five fields an agent will receive. What remains missing is minor: no note on what an empty list means or how health values are expressed.

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?

The tool takes zero parameters, so the baseline is 4. The description correctly implies no inputs are needed by framing it as a simple list operation, and the empty schema confirms this with no ambiguity.

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?

States a specific verb and resource (list installed CPUs) and enumerates the exact fields returned, so the agent knows this is a CPU inventory read and can tell it apart from siblings like idrac_memory or idrac_storage purely from the resource noun.

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?

Usage is only implied: the verb 'list' plus the read-only annotations signal a safe inventory call, but the description never says when to pick this over a broader sibling such as idrac_system_overview or idrac_health, nor any preconditions.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered; the description adds the diagnostic framing and the fact that it reports the MCP server's permission mode. Minor gap: it does not say what happens on connection failure (error vs. degraded status), which is the key behavioral outcome for a connectivity check.

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?

Two sentences, no filler; the payload of reported fields comes first and the usage trigger follows. Nothing is redundant with the schema or annotations.

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?

No output schema exists, so the description carries the burden of describing return values — and it does, listing the five reported facts. For a zero-parameter diagnostic tool this is sufficient to call it correctly.

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?

Zero parameters, so the baseline is 4 and no parameter explanation is required. The description correctly focuses on return content instead.

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?

States a specific verb ('check the connection') plus resource (iDRAC) and enumerates exactly what is reported: firmware, Redfish version, server model, service tag, and MCP permission mode. That reported-field list distinguishes it from generic siblings like idrac_system_overview and idrac_manager_info, which collect system or manager data rather than validating connectivity.

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?

Gives explicit usage context: 'Use this first when another tool fails or to confirm the setup works' — a clear diagnostic/first-step trigger. It does not name specific sibling tools or state when-not to use it, but the intended role is unambiguous.

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

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

Annotations already declare readOnly/idempotent/closed-world, so the safety profile is covered. The description adds genuinely non-obvious operational context — that the call is slow on iDRAC 8 — which an agent can use for timeout planning, plus it enumerates the returned data (health, predicted failure, SSD wear).

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?

Two sentences, no filler. The scope and returned field list are front-loaded, and the performance caveat is correctly placed last as a secondary note.

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, the description carries the burden of describing return values and does so field-by-field, and annotations cover safety. Minor gap: it doesn't note that drives/volumes can be skipped via the flags (e.g., a controllers-only fast path), which would matter given the stated slowness.

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 100% and both parameters (include_drives, include_volumes) are documented in-schema with defaults, so the description need not repeat them. It says nothing about them, which is acceptable at this coverage level but adds no extra meaning — baseline 3.

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?

Specific verb ("List") plus precise resources (storage controllers, physical disks, virtual disks) and the exact fields returned for each. It is trivially separable from siblings like idrac_processors, idrac_memory, or idrac_network_interfaces without opening any schema.

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?

Usage is only implied by the resource type — an agent infers "call this when you need storage inventory." There is no explicit when-to-use statement, no exclusions, and no pointer to a sibling or alternative (e.g., when to prefer idrac_health for a quick health check).

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds real value by disclosing the returned content (a point-in-time snapshot of identity, firmware, power and thermal readings), which is essential since there is no output schema. It does not mention whether values are live vs cached or any cost/latency considerations.

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?

A single front-loaded sentence that leads with the tool's nature and then lists contents; every clause is a concrete returned field and nothing is wasted. The closing 'good starting point' line is the only slightly soft element.

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, the description carries the burden of describing return values, and it does so by enumerating the fields returned. Adequate for a zero-parameter read tool; a note on value freshness or units would make it fully complete.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. The schema is trivially complete at 100% coverage.

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?

States a specific verb+resource ('One-call summary of the server') and enumerates exactly which fields are bundled: model, service tag, firmware versions, power state, health, CPU/memory totals, power draw, inlet temperature. This makes it distinguishable from per-subsystem siblings like idrac_processors or idrac_power by being the aggregate view, though no sibling is named explicitly.

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?

'A good starting point for most questions' implies when to reach for it, but is vague and names no alternatives. It never says when to prefer the narrower siblings (idrac_health, idrac_thermal, idrac_power) instead, leaving that inference to the agent.

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

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

Annotations already declare readOnlyHint and idempotent, but the description adds useful behavioral context: it explains that iDRAC 8 lacks Redfish fan-speed control, so the agent knows writing fan speeds is impossible. It also enumerates what is included (thresholds, redundancy) 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?

Two tight sentences, front-loaded with the primary resource and data content, followed by a concise limitation. No wasted verbiage; every sentence adds value.

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?

For a read-only tool with no output schema, the description adequately specifies what is returned (fan RPM, temperature locations, thresholds, redundancy) and notes the read-only limitation. It could have mentioned return format or granularity, but missing output schema means the description carries enough for invocation.

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 100% and there is only one parameter (include_thresholds) fully documented in the schema. The description mentions thresholds conceptually but does not clarify the parameter's effect (e.g., default behavior or what happens when false), so baseline 3 is appropriate.

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 clearly states it returns current fan speeds and temperature readings, including specific data points (inlet, exhaust, CPUs) and metadata (thresholds, redundancy). It does not explicitly differentiate from idrac_health, which likely also reports thermal status, but the scope is unambiguous.

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?

Usage is implied by the content description (this tool provides fan and temperature data), but there is no explicit statement of when to use it versus idrac_health or idrac_power, nor any exclusions. The read-only note adds context but not a usage directive.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered. The description adds genuine value beyond them by disclosing that the response also reports whether the firmware supports attaching images through Redfish — a capability flag an agent would not otherwise anticipate.

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?

A single sentence with zero waste, front-loaded with the resource and then enumerating the three facts returned. Nothing is padded or restated from the title.

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?

No output schema exists, yet the description enumerates the salient returned facts (attachment presence, which image, Redfish attach support), which is exactly what an agent needs before calling. For a zero-parameter read tool, nothing material is missing.

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?

The tool takes no parameters, so the baseline is 4. The description correctly implies a parameterless read with no filtering or selection arguments, and nothing in the text misleads about inputs.

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?

Specific verb ('Show') plus a specific resource ('iDRAC virtual media devices') with a clarifying parenthetical naming the two device kinds (virtual CD/DVD and removable disk). The resource is clearly distinct from siblings like idrac_storage or idrac_boot_settings, though it does not explicitly say how it differs from them.

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?

There is no explicit when-to-use or when-not-to-use guidance and no named alternative. Usage is only implied: an agent reads this when it needs current virtual media attachment state. Given the narrow, unambiguous resource, that implied usage is adequate but not instructive.

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