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

Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds context about the return payload (attributes, bios_uri, full resource), which goes beyond the annotations and clarifies what the caller receives. No contradictions found.

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 concise sentences plus an example, with the core action front-loaded. Every sentence earns its place, and the description is easy to scan.

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 two-parameter read-only tool, the description fully explains the return shape and provides an example. The output schema exists, so the description is complete without needing to enumerate return fields further.

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 schema already covers both parameters with 100% coverage, so the baseline is 3. The description's example with system_uri='/redfish/v1/Systems/1' gives a concrete format, adding a small increment beyond the schema's textual description.

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 that the tool fetches BIOS attributes and the full BIOS resource for one system, with a specific verb and resource. It also provides a concrete example, which distinguishes it from broader system tools like get_system or redfish_get.

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 usage for retrieving BIOS-specific information for a single system, and the example demonstrates a typical invocation. While it does not explicitly mention alternatives or when-not-to-use, the context is clear enough from the tool name and description.

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 read-only, idempotent, and non-destructive behavior. The description adds contextual value by detailing the return envelope (system_uri and boot configuration block) and providing an example call, which is sufficient given the annotation coverage. No contradictions exist.

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 concise: two sentences plus a compact example. It front-loads the primary purpose and returns information without wasted words.

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?

This is a simple read-only tool with clear annotations, a complete input schema, and an output schema. The description adequately covers purpose, return shape, and example usage. No material gaps are present.

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 input schema has 100% description coverage, so the schema already documents both parameters (endpoint and system_uri). The description provides an example using system_uri, but it does not add semantic meaning beyond the schema's existing descriptions. 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?

The description clearly states the tool returns the Boot section for a system, with the specific purpose of inspecting override target, mode, and enablement. This specific verb+resource combination distinguishes it from siblings like get_system, which returns the entire system resource.

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 the use case ('so callers can inspect...') and gives an example invocation. It does not explicitly name alternatives or exclusions, but the purpose is clear enough for an agent to know when to choose this over broader get_system.

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 read-only and non-destructive behavior. The description adds valuable context beyond annotations: the auto-selection fallback when no URI/ID is given, and the return structure (resolved uri + resource payload).

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 plus a concrete example, all tightly packed with actionable information. No filler or repetition of the schema.

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?

Given the rich annotations, full schema coverage, and presence of an output schema, the description sufficiently covers the tool's purpose, default behavior, and return shape. It is complete for an AI agent to select and invoke the 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 covers 100% of parameters with clear descriptions, so baseline is 3. The description adds meaning by explaining the relationship between uri and chassis_id as alternative ways to identify the resource, and the auto-selection behavior when both are omitted.

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?

Description uses specific verb 'Fetch' with resource 'Chassis' and scope 'single', and clearly indicates the two modes of selection (URI or ID). It distinguishes from sibling list_chassis by explicitly focusing on a single member.

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?

Provides clear usage context: specify URI or ID to fetch a specific chassis, or omit to get the first member auto-selected. Does not explicitly mention when not to use it or point to an alternative like list_chassis, but the intended use case is evident.

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?

The description discloses meaningful behavioral details: each member is fetched when include_details is true, vendor-reported fields vary, and the response includes a details_truncated flag. This goes beyond the annotations (readOnlyHint, idempotentHint, etc.) and adds valuable context about what the tool actually does.

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 concise, front-loaded with the primary action, and includes a return structure explanation plus an example. Every sentence contributes information without redundancy.

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 tool of this complexity, the description covers the walk behavior, output structure, optional details, and a usage example. The presence of an output schema further enhances completeness, but the description alone is sufficient for understanding the 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% and each parameter is described, but the tool description adds extra meaning by explaining the effect of include_details on the output and providing a concrete usage example. This enhances the parameter semantics beyond the schema alone.

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 states the tool walks the Processors, Memory, Storage, EthernetInterfaces, and PCIeDevices collections of one system, making the purpose explicit and specific. It distinguishes itself from sibling tools like get_system or redfish_walk by describing a distinct aggregated inventory operation.

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 context on when to use the tool (to retrieve component inventory for a system) and explains the behavior of include_details. It does not explicitly name alternatives or exclusions, but the context is sufficient for an agent to select this tool appropriately.

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?

The description goes beyond the readOnlyHint annotation by specifying the return object shape, the wrapping of lists as {items, total, truncated}, and including an example invocation. This gives the agent practical knowledge of what to expect without contradicting the safety hints.

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 concise: a purpose sentence, a return-format note, a list-wrapper clarification, and an example—all in four short sentences. Every piece adds value, with the core purpose front-loaded.

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 tool with two optional parameters, an output schema, and complete parameter descriptions, the description covers the functional purpose, return structure, and invocation pattern. No significant gaps remain for an agent to invoke 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?

The schema already provides 100% description coverage for both 'limit' and 'endpoint.' The tool description adds only an example using limit=200, which is helpful but does not introduce new meaning beyond what the schema states.

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 'Retrieve UpdateService firmware inventory members and return each firmware resource payload,' which names a specific verb, resource collection, and service. It clearly distinguishes this from sibling tools like get_component_inventory by targeting firmware inventory from UpdateService.

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 implicitly establishes when to use this tool: whenever firmware inventory members are needed. It does not explicitly name alternatives or exclusions, but the precise resource reference provides clear context that separates it from other inventory/read tools.

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 destructiveHint=false, covering the safety profile. The description adds meaningful context about the return shape (groups keyed by Systems/Chassis/Managers) and the rollup nature, going beyond the annotations without contradicting them.

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 two concise sentences and an example, with the purpose front-loaded. Every sentence adds value, and the example call is a useful quick-reference without waste.

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?

The tool has an output schema, and the description explains the return structure clearly. With only one optional parameter and annotations covering safety, the description is fully sufficient to infer usage and expected results.

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 schema provides 100% coverage for the single optional 'endpoint' parameter, so the description adds no extra parameter semantics. The example call get_health_summary() is already implied by the schema's default null, so the description does not compensate beyond what the schema offers.

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 ('Collect health/state rollups') and names the exact resources (Systems, Chassis, Managers), clearly distinguishing it from sibling tools like list_systems or get_system. The return structure is explicitly described, reinforcing the purpose.

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 phrase 'quick fleet health summary' provides a clear context for when to use this tool, implying it is for high-level overviews rather than detailed inspection. It does not explicitly name alternatives or exclusions, but the context against the sibling list is sufficient.

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 read-only, idempotent, and non-destructive behavior. The description adds valuable behavioral context by explaining the return object structure (entries, endpoint, manager/log-service context) and the list wrapper format {items, total, truncated}, which is not present in 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?

Three concise sentences with no fluff: purpose, return format, and a concrete example. The structure is front-loaded and every sentence earns its place.

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?

Given the rich output schema and annotations, the description is complete. It explains what the tool does, what it returns, and provides an example. There is no missing critical information for an agent to select and invoke the tool 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?

Schema coverage is 100%, so baseline is 3. The description adds value with a concrete example showing log_service_uri, severity, and limit usage, and also mentions 'selected LogService' which maps to the core parameters. This goes beyond just repeating schema descriptions.

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 the tool collects entries from a LogService with optional filtering, which is a specific verb+resource. It distinguishes itself from generic tools like redfish_get by focusing on log entries and troubleshooting workflows.

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 context: 'for troubleshooting workflows' and demonstrates filtering by severity and timestamp. It does not explicitly mention alternatives or exclusions, but the context is sufficient to infer when 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 mark the tool as read-only, idempotent, and non-destructive. The description adds valuable behavioral details beyond annotations: the auto-selection of the first manager when omitted, and the exact response structure (resolved 'uri' and full 'resource' payload). This enriches transparency 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?

Three compact sentences: the first states the core action, the second explains return value, and the third gives an example. No filler, front-loaded with the essential verb+resource, and every sentence earns its place.

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 an output schema present, the description need not detail return fields, but it still does so concisely. It covers selection modes, fallback behavior, and an example, making it complete for a simple read-only fetch tool in the context of its sibling tools.

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, but the description adds meaning by clarifying the relationship between uri and manager_id, the fallback behavior when both are omitted, and providing a concrete example. This goes beyond the schema's field-level descriptions and helps the agent construct correct calls.

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 begins with a specific verb and resource: 'Fetch one Manager (BMC/iDRAC/iLO/XCC) by URI or ID', clearly distinguishing it from sibling tools like list_managers or redfish_get. It also states the auto-selection fallback and the return shape, leaving no ambiguity about the tool's purpose.

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?

It provides clear context for when to use the tool: fetching a single manager by URI or ID, with auto-selection if omitted. However, it does not explicitly mention alternatives or when NOT to use it, although the unique behavior of auto-selection and direct resource fetch implicitly guides usage.

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 destructiveHint=false, covering the safety profile. The description adds the return structure ('Object with power_uri plus full power resource payload') and the telemetry scope, but does not disclose additional behavioral traits like authentication needs or edge-case behavior.

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 two concise sentences plus an example, with no wasted words. The fetch action and resource are front-loaded, and 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 simple read-only telemetry tool with strong annotations, an output schema, and a well-documented request schema, the description sufficiently covers purpose, usage, and return format without unnecessary detail.

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%, with both parameters ('endpoint' and 'chassis_uri') fully described. The description adds a concrete example call but no new semantic information beyond what the schema already provides, so the baseline-3 score 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?

The description states a specific verb ('Fetch'), a specific resource ('PowerSubsystem/Power'), and enumerates the telemetry types covered (watts, PSU, power-control, power-cap). It also distinguishes the tool from siblings by explicitly recommending it for PSU or power-draw requests.

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 includes an explicit preference statement: 'Prefer this tool for PSU or power-draw requests.' It clearly indicates when to use the tool, though it does not name specific alternative tools or exclusion scenarios.

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 read-only, open-world, idempotent, and non-destructive behavior. The description adds valuable behavioral context beyond annotations: fallback to deprecated Thermal inline arrays, the exact return shape (sensors_uri vs fallback), and list wrapping format. This fully discloses behavior.

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 compact and front-loaded, with no wasted sentences. It covers purpose, alternatives, return format, fallback behavior, and an example in just four lines, all of which are necessary.

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?

Given the tool's low complexity (read-only, 3 optional params) and the presence of an output schema, the description is fully sufficient. It explains return formats, fallback conditions, and usage examples, leaving no important gaps.

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 descriptions cover 100% of parameters, providing a strong baseline. The description contributes an example call showing how chassis_uri and limit are used together, which adds practical parameter semantics beyond the schema definitions.

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 'Fetch broad cross-domain sensor data from Sensors collection', clearly stating the verb and resource. It also explicitly distinguishes this tool from get_thermal and get_power, preventing ambiguity among sibling tools.

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?

It gives explicit alternative usage instructions: 'Use get_thermal for cooling details and get_power for PSU/power metrics.' This provides clear when-to-use and when-not-to-use 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 read-only, idempotent, and non-destructive behavior. The description adds valuable context beyond annotations: the auto-selection of the first system member and the return format (resolved URI and full resource payload).

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 concise and front-loaded: a clear action sentence, a return-format sentence, and a concrete example. No filler or redundant 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?

For a simple read-only retrieval tool, the description covers purpose, selection behavior, return format, and includes an example. Combined with full schema descriptions, an output schema, and robust annotations, there are no significant gaps.

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 descriptions cover all parameters (100%), but the description adds meaning by clarifying that the tool works 'by URI or ID', implying uri/system_id are alternatives, and explaining that omitting parameters selects the first system member. This goes beyond the schema's basic parameter descriptions.

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 the tool fetches a single ComputerSystem resource, by URI or ID, with auto-selection if omitted. This specific verb+resource+method distinguishes it from siblings like list_systems and redfish_get.

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?

Provides clear context: use when you need one system resource, with explicit URI/ID or automatic selection of the first member. However, it does not explicitly name alternatives like list_systems, so it lacks direct vs-alternative 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 the tool read-only, idempotent, and non-destructive. The description adds useful behavioral context beyond annotations: the default behavior when no identifier is provided (first task member), the return shape (payload under 'task' and resolved URI), and an example. No contradiction with 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 concise—two sentences plus an example—and front-loaded with the main purpose. Every clause adds useful information: the fetch behavior, the default case, the return format, and an illustrative call.

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?

Given the simple nature of the tool (3 optional parameters, output schema provided, no nested objects), the description is complete: it covers what the tool does, the key default behavior, and the return structure. The output schema supplements any need for detailed return field documentation.

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 input schema fully documents all three parameters with descriptions, so the baseline is 3. The description adds semantic value by clarifying that 'uri' and 'task_id' are alternatives, explaining the default when both are omitted, and providing a concrete example (get_task(task_id='Task42')).

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 the action ('Fetch a task') and identifies the resource ('task') with explicit mention of the input methods ('by URI or task_id'). It also differentiates from sibling list_tasks by focusing on a single task resource.

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 the use case (fetching a single task when you have a URI or task_id) but does not explicitly mention when not to use it or point to alternatives like list_tasks. The context is clear enough for an agent to infer when to invoke this tool.

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, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value by disclosing the return format ('Object with thermal_uri plus full thermal resource payload') and providing a concrete example call, which helps predict behavior.

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 sentences plus an example, no fluff. The first sentence states the core function, the second gives usage preference, and the third describes return payload. Very efficient.

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?

The tool is simple: read-only, two optional params, has output schema. The description covers what it does, when to use it, and what it returns. Annotations cover safety. No missing essential information for an agent to select and invoke 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?

The input schema covers both parameters with descriptions (endpoint and chassis_uri, both with default behavior). The description's example clarifies usage of chassis_uri but does not add semantic meaning beyond the schema's descriptions. Since schema coverage is 100%, a 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?

The description uses a specific verb ('Fetch') and resource ('ThermalSubsystem/Thermal') and clearly lists what telemetry it covers (temperature, fan, cooling). It also distinguishes itself by stating a preference for this tool for inlet/exhaust temperature and fan speed requests, differentiating from sibling tools like get_power or get_sensors.

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 states 'Prefer this tool for inlet/exhaust temperature and fan speed requests,' giving explicit when-to-use guidance. However, it does not name alternative tools or explicitly state when not to use it, so it stops short of full exclusions.

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?

The annotations already declare read-only, non-destructive, idempotent behavior. The description adds valuable behavioral details by explaining the return wrapper structure ({items, total, truncated}) and how the include_details parameter changes the output between URIs and full resources. This goes beyond the annotations, though it does not cover potential pagination or auth concerns.

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 two sentences plus an example, with no wasted words. It is front-loaded with the primary action, then the return format, and the example is useful. Every element earns its place.

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 only optional parameters and a rich output schema, the description provides enough context: the object structure, the include_details effect, and an example. It does not explicitly discuss pagination or endpoint selection, but these are already implied by the schema and the tool's simplicity.

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 are already well-documented. The description mostly restates the include_details behavior (URIs vs. full resources) and provides an example, adding marginal value beyond the schema. It does not clarify the 'endpoint' parameter beyond what the schema already says.

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 states a specific verb ('List'), a clear resource ('AccountService account members'), and the optional behavior of including full payloads. This clearly distinguishes it from sibling tools that list other resource types (e.g., list_systems, list_managers).

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 context about what the tool does and the output format, which helps an agent decide to use it for listing accounts. However, it does not explicitly mention when not to use it or name alternative tools for other resources, so it falls 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 convey read-only, idempotent, and non-destructive behavior. The description adds valuable behavioral context by detailing the return object structure (collection_uri, chassis items), the wrapping format ({items, total, truncated}), and the effect of include_details. This goes beyond what annotations provide, especially the truncation hint which complements the openWorldHint.

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 compact and front-loaded with the main purpose, followed by return format and a concrete example. Every sentence contributes meaningful information without fluff or repetition of the schema.

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 list tool, the description covers the core behavior, return shape, pagination/truncation indicator, and includes a usage example. An output schema exists, so detailed field documentation is already available. The description is complete enough for an agent to select and invoke the tool 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?

The input schema already fully describes both parameters, including the meaning of include_details and endpoint. The description reiterates include_details in prose and gives an example call, adding slight value but not substantially extending the schema's coverage. Baseline of 3 is appropriate given schema coverage is 100%.

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 the verb ('List') and resource ('Chassis members'), and specifies the optional behavior ('include full details and status'). It distinguishes itself from sibling tools like get_chassis, which targets a single chassis, and list_systems, which targets a different resource.

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 context: this tool lists chassis members and can optionally fetch details. It does not explicitly name alternatives or exclusions, but the purpose is unambiguous in the context of sibling list/get tools, making the intended usage clear.

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 read-only and idempotent behavior. The description adds value by disclosing return structure (endpoints list with names, URLs, and flags) and mentioning auth/read-only settings, which is useful context beyond the 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 two concise sentences plus an example, covering purpose, return format, and usage. Every sentence earns its place with no filler or repetition.

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 zero-parameter list tool with an output schema, the description fully covers what it returns and why. It includes an example and sufficient context for an agent to select and invoke 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?

The tool has zero parameters and an empty schema, so the description bears no parameter burden. The baseline for zero params is 4, and the description appropriately focuses on output rather than parameters.

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 states the tool lists all configured endpoints and their auth/read-only settings, with the specific purpose of helping callers choose a valid endpoint value. This is a clear verb+resource combination that distinguishes it from sibling tools that query specific resources.

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 phrase 'so callers can choose a valid endpoint value' provides clear context for when to use this tool—before endpoint-dependent operations. It does not name alternatives or exclusions, but the implied usage is straightforward.

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 destructiveHint=false. The description adds valuable context on return envelope format ({items, total, truncated}) and the distinction between URI-only and full payload behavior, which goes beyond the 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 concise, front-loaded with the primary action, includes a practical example, and avoids redundant information. Each sentence contributes to understanding the tool's purpose and behavior.

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?

Given the tool's simplicity, full schema coverage, and helpful annotations, the description is nearly complete. It covers purpose, optional details, and return envelope including truncation. The only minor gap is the lack of explicit cross-reference to get_manager for single-item retrieval, but this is not critical.

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 baseline is 3. The description's example reinforces include_details but does not add meaning beyond the schema's existing parameter descriptions, which already explain the boolean's effect.

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 the tool 'List Manager members' with a specific verb+resource, identifying BMC controllers (iDRAC/iLO/XCC) and optional detail inclusion. This distinguishes it from the sibling get_manager tool, which retrieves a single manager.

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 usage for listing managers but does not explicitly contrast with alternatives like get_manager or state when to use this vs list_systems. No exclusion or alternative guidance is provided, so agents must infer the appropriate context from the tool name and sibling list.

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 indicate read-only/idempotent safe operations. The description adds useful behavioral details: return format, pagination wrapper, and the effect of include_details on payload depth, exceeding what annotations provide.

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 concise and well-structured: purpose, parameter guidance, return contract, and an example. Each sentence provides distinct value with no redundancy.

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 straightforward list operation, the description is complete: it covers scope, parameter behavior, response shape, and example usage. The output schema and annotations bear the rest, making this sufficient for confident 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 descriptions already cover both parameters. The description adds meaning by specifying that include_details yields 'full resource payloads and health snapshots', enriching the schema's explanation. The endpoint parameter is clarified via the example.

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 the tool lists ComputerSystem members from /Systems, with a specific verb and resource. It distinguishes from sibling tools like get_system (single resource) and other list_* tools by targeting a specific collection.

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 includes an example invocation and explains when to use include_details, but does not explicitly contrast with alternatives like get_system. The context is clear enough for selecting this tool for enumeration, though exclusions are not 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?

The description discloses the return structure ('Object with TaskService entries under tasks'), the list wrapping format ({items, total, truncated}), and the effect of include_details. This adds behavioral context beyond the annotations, which already declare read-only/idempotent/non-destructive.

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 sentences: purpose, return format, and a concrete example. No wasted words; information is front-loaded.

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?

Given the tool's simplicity, full output schema, and rich annotations, the description covers all critical aspects: what it lists, the return shape, truncation behavior, and an example invocation. It is complete for an agent to select and invoke 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?

Schema coverage is 100% with both parameters (endpoint and include_details) already well-described. The description reinforces include_details via the example and first sentence but adds no new parameter-level meaning beyond that.

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+resource ('List TaskService task members') and clarifies the optional behavior (including full payloads). It distinguishes itself from sibling tools like get_task by being plural and scoped to TaskService. The example further clarifies intent.

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 usage (list all tasks, optionally with details), but it does not explicitly state when to prefer this over sibling tools like get_task, nor does it mention exclusions or alternatives. The example demonstrates usage, providing some contextual 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 readOnly, idempotent, and non-destructive behavior. The description adds valuable behavioral details beyond annotations, including the exact return object shape (manager_uri, virtual_media) and how lists are wrapped ({items, total, truncated}), plus a concrete example. No contradiction with 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 three compact, purposeful sentences: one for purpose, one for return format, and one for a usage example. There is no filler or redundant restatement of the tool name.

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 zero required parameters and an output schema, the description fully covers purpose, output structure, and a usage example. It is complete enough for an agent to select and invoke it correctly without needing further documentation.

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 input schema already covers both parameters with clear descriptions (endpoint name, manager URI). The description adds a concrete example using manager_uri with a realistic path format, which helps agents understand the expected value. This lifts it beyond the baseline 3 for 100% schema 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?

The description uses a specific verb ('List') and identifies the resource ('VirtualMedia resources for a manager'), clearly distinguishing this from sibling tools like list_systems and list_chassis. It also states the operational purpose ('inspect mounted images and media state'), which makes the tool's function 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?

The description provides clear context for when to use the tool: to inspect mounted images and media state of a manager. It stops short of explicitly stating when not to use it or naming alternative tools, but the context is strong enough to guide selection among similar list_* tools.

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 read-only, idempotent, non-destructive behavior. The description adds valuable context about the bundled index artifact (suggesting offline/local data) and the return content, including URIs, properties, actions, versions, and enum metadata. It also notes the potential size of full summaries, which is a practical performance consideration.

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 concise and front-loaded with the main purpose. It efficiently packs the key behavioral notes and an example into four compact sentences, with no wasted words.

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?

Given the tool's simple scope, an output schema, and safe annotations, the description provides sufficient completeness. It clarifies the source (bundled index), narrowing options, return format, and an example, making it fully understandable for an agent.

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 input schema already covers all parameters with descriptions. The description supplements this by explaining how property_name and action_name narrow the result, and the example clarifies usage with resource_type and property_name. This adds meaning beyond the schema definitions.

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 the tool returns distilled schema metadata for one Redfish resource type from the bundled index artifact. It distinguishes itself from sibling tools that focus on endpoint operations or live data access.

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?

It provides helpful guidance on narrowing output with property_name or action_name when full summaries are large, but does not explicitly discuss when to use this tool vs alternatives like redfish_get or list_endpoints. The usage context is implied rather than directly contrasted with siblings.

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, openWorldHint, idempotentHint, and non-destructive behavior. The description adds context by explaining that query options are applied conditionally and detailing the return object (resource, resolved URI, applied query options), which goes beyond the 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 three sentences plus an example, with no wasted words. It front-loads the most important information ('Escape hatch') and efficiently covers purpose, behavior, return value, and usage.

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?

The description covers the tool's role, behavior, return value, and an example. It does not discuss error handling or pagination, but the output schema exists and the tool is positioned as a simple raw GET, so this is adequate for the complexity.

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 input schema provides 100% coverage with clear descriptions for each parameter, including the 'Ignored if service does not support' behavior. The description's example adds a concrete usage snippet but does not significantly expand on the schema's semantics, so a baseline score of 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 opens with 'Escape hatch: use when no typed tool fits,' which clearly identifies the tool as a fallback for unhandled cases. 'Fetch any Redfish URI directly' states the specific verb and resource, distinguishing it from the typed getters like get_system and get_chassis.

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 phrase 'use when no typed tool fits' explicitly states the condition for using this tool and implies that typed tools are preferred alternatives. The example demonstrates invocation, and the note about applying query options only when supported adds practical 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 and idempotentHint, so the safety profile is covered. The description adds value by explaining it combines schema actions with live ActionInfo and AllowableValues, and by summarizing the return structure. This gives useful behavioral context beyond 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 three sentences, front-loaded with the key guidance, and includes a concrete example. No wasted words.

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?

Given the output schema and annotations, the description sufficiently covers purpose, return format, and usage context. It might benefit from explicitly stating that it is read-only, but annotations already convey that. Overall, it's complete for an agent to select and invoke the 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 describes both parameters with 100% coverage, so the description doesn't need to re-explain them. The example call with a concrete URI adds practical semantic value, making the parameter usage 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 clearly states it lists available actions for a resource URI and distinguishes it from sibling get/list tools by focusing on action metadata. The verb 'list available actions' is specific, and the phrase 'prefer this before any unfamiliar write/action call' establishes its unique role.

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 instruction to 'prefer this before any unfamiliar write/action call' explicitly tells the agent when to use it. It does not enumerate when not to use it or name alternatives, but the context is sufficiently clear for a discovery tool.

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, openWorldHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds behavioral detail: BFS traversal, returns nodes with uri/depth/type and visited_count, and an example with limits. This goes beyond annotations, but doesn't mention potential large result sizes or network behavior, which would be useful.

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 sentences plus an example, front-loaded with the 'escape hatch' label. Each sentence serves a purpose: usage context, algorithm, return format, and example. No filler or redundancy.

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 output schema present and annotations covering safety, the description fills the remaining gaps: when to use (escape hatch), how it works (BFS), what it returns (nodes + visited_count), and a concrete example. For a graph traversal escape hatch, this is 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?

Schema coverage is 100%, so the schema already documents each parameter. The description's example (start_uri, max_depth, max_nodes) reinforces usage but doesn't add new semantic meaning. The return description helps infer parameter intent (e.g., depth/nodes limits), but it's not a significant enhancement over the schema.

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 the tool's function: 'Perform a breadth-first walk over linked @odata.id resources.' The verb 'walk' is specific to graph traversal, and the resource 'Redfish graph' is distinct. It also frames itself as an 'escape hatch' for topology exploration, distinguishing it from typed list/get sibling tools.

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 explicitly says when to use: 'use for topology exploration when typed list/get tools are insufficient.' This provides usage context and indicates that typed tools are preferred for standard queries. It doesn't name specific sibling tools, but the category 'typed list/get tools' is clear enough. No explicit when-not is given, but the guidance is strong.

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 non-destructive, so the safety profile is covered. The description adds behavioral context by listing the exact return fields (service_root, redfish_version, capabilities, links, resolved endpoint name) and providing an example call, which helps the agent anticipate the result. It does not contradict any annotation.

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 two sentences plus a short example, with the main action front-loaded. Every sentence contributes purpose, return structure, or usage demonstration, with no filler or repetition.

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?

Given the tool is a simple read-only capability query with one optional parameter and an output schema, the description provides sufficient context: what it does, what it returns, and an example. It could be argued that error behavior or edge cases are omitted, but these are less critical for a read-only, idempotent capability-discovery tool. The presence of an output schema reduces the need to explain return values in detail.

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% with a clear description of the endpoint parameter (configured endpoint name, omit to use default). The description's mention of 'resolved endpoint name' and example usage adds minimal new meaning beyond the schema, so it meets the baseline 3 for high schema 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?

The description states the specific verb 'Fetch' with the resource 'ServiceRoot and protocol feature flags', and clarifies the purpose as understanding supported query options and links. This clearly distinguishes the tool from the many sibling tools like get_system or redfish_get by focusing on capability discovery, not a specific resource fetch.

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 context for use ('to understand what query options and links the endpoint supports'), which implies when an agent should invoke this tool. However, it does not explicitly name alternatives or state when not to use it, so it falls short of a full 5.

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