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

The description adds context beyond the annotations (readOnlyHint=true, etc.) by explaining that the tool retrieves active recommendations that help identify issues affecting system availability, stability, performance, or security, and that higher impact/likelihood values indicate more critical issues. It also demonstrates typical usage patterns via examples. No contradiction with annotations is present.

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 relatively concise, starting with a clear purpose sentence followed by a brief overview of filters and numerous call examples. The examples are well-organized but somewhat lengthy. The structure is effective, though the examples could be trimmed or moved into a separate documentation section.

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 that an output schema exists (not shown but stated 'Has output schema: true'), the description does not need to explain return values. It covers the tool's purpose, filter capabilities, and provides usage examples covering pagination, common filters, and sorting. The examples imply pagination and case usage. Minor gaps include no explicit mention of default sorting or the list nature of the response, but the examples compensate.

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 for all 12 parameters, each with explicit descriptions. The description adds some value by providing specific call examples that show parameter usage (e.g., 'impact': '3,4', 'tags': ['insights-client/group=database-servers']). However, it does not significantly deepen semantic understanding beyond what the schema already provides.

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 'Get' and the resource 'active Advisor Recommendations for your account', and explains what these recommendations help identify (system availability, stability, performance, or security). It distinguishes from sibling tools like advisor__get_hosts_details_for_rule or advisor__get_recommendations_stats by focusing on active recommendations with user-controllable filtering, not host details or statistics.

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 numerous call examples that implicitly illustrate when to use various filters (e.g., for high risk, pagination, automatic remediation, security categories). However, it lacks explicit guidance on when to use this tool versus sibling tools, such as advisor__get_rule_details or advisor__get_rule_by_text_search. The verb 'Get' and the mention of filters imply retrieval, but no direct comparison to alternatives is 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 indicate readOnlyHint, idempotentHint, and no destructive action. The description adds value by detailing pagination, returned fields (system identification, impact metrics, RHEL version, hit counts, incident status), and no contradictions.

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

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

The description is front-loaded with the main verb and resource, followed by details and examples. It is structured but slightly wordy; could be more concise.

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 presence of an output schema, the description adequately covers the return content and provides examples for common use cases, making it complete for the tool's purpose.

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?

With full schema coverage, baseline is 3. The description provides concrete call examples showing parameter combinations (pagination, filtering) and usage patterns, adding meaning beyond 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 it gets detailed information about RHEL systems affected by an Advisor Recommendation. It uses specific verbs and resource, but does not explicitly differentiate from the sibling tool advisor__get_hosts_hitting_a_rule.

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 usage examples and implies when to call this tool, but does not explicitly state when not to use it or name alternatives like the sibling 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, destructiveHint=false. Description adds call example but no additional behavioral context like permissions or rate limits. Adequate given 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?

Very concise: three sentences plus example. Front-loaded with main purpose. No unnecessary 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?

Output schema exists so return values not needed. For a simple read tool with one parameter, description is sufficient. Could mention if results are paginated or any limits, but not essential.

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 has 100% coverage for the one parameter with description. Description adds a call example showing the format for rule_id, adding value beyond 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?

Description states verb 'Get' and resource 'all RHEL systems affected by a specific Advisor Recommendation' clearly. Distinguishes from siblings like advisor__get_active_rules which lists rules.

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?

Says 'Use this to understand the scope of impact' but does not explicitly exclude alternatives or state when not to use. Implied but not explicit.

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, destructiveHint=false, idempotentHint=true, and openWorldHint=true, so the description's 'Show statistics' is consistent. The description adds no additional behavioral details beyond the annotation set, meeting the baseline for transparency.

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 extremely concise with a single sentence purpose followed by three illustrative call examples. Every sentence adds value, and the structure is front-loaded for quick comprehension.

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 has an output schema, return values are covered externally. The description explains the tool's purpose, parameters, and typical usage patterns (all vs. filtered). It is fully complete for its complexity level and sibling context.

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 schema descriptions already explain parameters. The call examples add practical usage context (e.g., 'Statistics for the workspace workspace1') which enhances understanding beyond the schema, justifying a score above baseline.

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 explicitly states the tool shows statistics of recommendations across categories and risks, with a clear verb-resource combination. It distinguishes from sibling tools like advisor__get_rule_details or advisor__get_active_rules which focus on rules rather than aggregated statistics.

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?

Call examples demonstrate standard usage and filtering by groups or tags, giving clear context for parameter use. However, it does not explicitly state when not to use this tool or provide alternative suggestions, leaving some ambiguity.

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 and idempotent behavior. The description confirms exact text substring matching, which adds minimal behavioral detail 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?

Very concise: one sentence plus a usage example. No superfluous information, front-loaded with purpose.

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, return values need not be described. The description adequately covers the simple search functionality, though it omits details like case sensitivity.

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 the single parameter with a description. The tool description adds a call example demonstrating the parameter usage, providing extra context 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 clearly states the tool finds Advisor Recommendations by exact text substring search. It distinguishes itself from siblings by specifying the search mechanism, but does not explicitly differentiate from similar advisor 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?

No guidance on when to use this tool versus alternatives like advisor__get_rule_details or advisor__get_recommendations_stats. The example shows usage but does not provide context for choosing this search 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 indicate readOnly, idempotent, non-destructive. Description adds useful behavioral context by listing the types of information returned (impact, likelihood, remediation, articles), which goes beyond annotation 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?

Description is concise with two sentences plus an example, front-loaded with purpose. Every sentence adds value 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 simple tool with one parameter and an output schema, the description adequately covers what the tool returns (impact, likelihood, etc.). It is contextually complete given the low 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?

Schema description coverage is 100% for the single parameter rule_id, which already describes the format. Description adds an example call, providing some extra context, but baseline is 3 due to full 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?

Description clearly states the tool retrieves detailed information about a specific Advisor Recommendation, including impact, likelihood, remediation, and articles. It distinguishes from sibling tools like advisor__get_active_rules (list) and advisor__get_rule_by_text_search (search).

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?

No guidance on when to use this tool versus alternatives. Sibling tools are listed but not contrasted, and no when-not-to-use scenarios are provided. Only a call example is 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=true, destructiveHint=false, and idempotentHint=true. The description adds that the tool provides 'system-specific remediation steps,' which enriches the behavioral understanding without contradicting 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 extremely concise with three short sentences: purpose, usage guideline, and an example call. Every sentence adds value, and it is front-loaded with the core action.

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 lookup tool with one parameter and an output schema, the description is complete. It explains the input (node_id) and the purpose (finding related Advisor Recommendations with remediation steps), which is sufficient for correct 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 coverage is 100%, and the schema already describes node_id as 'Node ID of the knowledge base article or solution. Example: 123456'. The description repeats this with a call example but adds no new semantic information beyond 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 that the tool finds Advisor Recommendations using a Knowledge Base article or solution ID. It specifies the resource and action, but does not explicitly differentiate from sibling tools like 'advisor__get_rule_by_text_search' or 'advisor__get_rule_details', leaving some ambiguity.

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 'Use this when you have a Knowledge Base article or solution ID,' providing clear context for when to use the tool. However, it does not mention when not to use it or suggest alternative tools among the 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?

The readOnlyHint and openWorldHint annotations already cover the safety profile. The description adds a behavioral cue that no information gathering is needed, but it does not describe pagination behavior, response size, or any side effects. With annotations present, this is acceptable but not deeply transparent.

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 very short and front-loads the call-to-action. However, the first sentence only repeats the tool title/name, slightly wasting the opening line. Overall, it is efficient and avoids bulk.

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 has a rich input schema with 100% parameter coverage and an output schema exists, the description does not need to explain return values. It adequately introduces the tool's purpose and immediate-call guidance, but does not provide deeper context like common usage patterns or relationship to other 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 description coverage is 100%, so each parameter is already documented with its meaning and default. The description adds only generic 'filtering and pagination' context beyond the schema, which is unnecessary but not harmful.

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 'List repositories with filtering and pagination options', identifying the specific verb, resource, and scope. It distinguishes itself from sibling tools, which target images, vulnerabilities, inventory, and RHSM, not content repositories.

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 'CALL IMMEDIATELY - No information gathering required,' giving clear guidance that no prerequisites are needed. It does not name alternatives or when-not-to-use, but among the siblings there is no competing repository-listing tool, so the context 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 indicate readOnlyHint=true. The description adds that it returns a version and includes a comparison URL, but does not detail other behaviors (e.g., rate limits, auth). For a simple read-only tool, this is sufficient.

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 front-load the purpose and immediately provide usage context and output handling. No extraneous 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?

Given zero parameters, an output schema, and readOnly annotation, the description covers when to use, what it returns, and what to do with the result. It is complete for a simple version retrieval 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?

No parameters exist, so schema coverage is 100%. The baseline is 4 per guidelines. The description correctly omits parameter details.

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 retrieves the version of the Red Hat Insights MCP server. It uses a specific verb ('Get') and resource ('version'), and no sibling tool serves a similar 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 description explicitly instructs when to call this tool: when the user asks for the version, or during API/authentication issues. It also tells the agent to present a comparison URL, leaving no ambiguity about 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, so the description's 'CALL IMMEDIATELY' adds minor context. It mentions raising an exception on connection failure, but lacks details on what happens if the blueprint does not exist or the identifier is invalid.

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 very short, but it includes some redundancy (repeats 'blueprint details' in the first line and under 'Returns'). The structure is functional, but could be more streamlined.

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 presence of an output schema, the description does not need to detail return values. However, it omits information about required input validity (e.g., what happens if the blueprint identifier does not exist) and does not fully leverage the annotations to provide comprehensive context.

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 parameter 'blueprint_identifier' described as 'The UUID, name or reply_id to query.' The description does not add any further semantic value beyond 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 'Get blueprint details,' indicating retrieval of a single blueprint's details. However, it does not distinguish itself from sibling tools like image-builder__get_blueprints, which lists blueprints, or image-builder__get_compose_details.

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 'CALL IMMEDIATELY - No information gathering required,' suggesting it is safe to call, but it provides no explicit guidance on when to use this tool over alternatives such as other get_* tools in the image-builder domain.

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 indicate readOnlyHint=true and openWorldHint=true. The description adds value by stating 'CALL IMMEDIATELY' and clarifying that no prior gathering is needed, which aligns with the read-only nature. No contradictions 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 extremely concise with two sentences: first for purpose, second for usage hint. No redundant words; every sentence provides essential 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?

Given the presence of an output schema and annotations that cover read-only and open-world hints, the description fully covers what the tool does and when to use it. No gaps remain for this straightforward list 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?

Input schema covers all 3 parameters with descriptions (100% coverage). The description does not add additional parameter semantics, so 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 clearly states 'Show user's image blueprints' with a specific verb and resource, and elaborates on content (saved templates/configurations for Linux distributions, packages, users). It distinguishes from sibling tools like image-builder__get_blueprint_details which focuses on a single blueprint.

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 '🟢 CALL IMMEDIATELY - No information gathering required', providing explicit guidance on when to use. However, it does not specify when not to use or compare to alternative tools for similar tasks.

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 as read only and open world. Description adds specific return details (status, progress, errors, download URLs, logs) and process context, but no contradictions.

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?

Well-structured with sections for requirements, warnings, process, and returns. Every sentence adds value. Front-loaded with purpose.

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 low complexity, 100% schema coverage, output schema present, and annotations, the description fully covers prerequisites, process, and return values.

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%. Description adds crucial meaning: parameter must be exact UUID from get_composes(), not generic terms. This goes beyond schema documentation.

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 title and description explicitly state it gets detailed info for a specific image build. It distinguishes from siblings like get_composes (list) and get_blueprint_details by requiring a UUID.

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 explicit instructions: requires compose UUID from get_composes(), warns against generic terms, and outlines a clear process from user request to function 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 include readOnlyHint=true, so the description does not need to reiterate that. The description adds context beyond annotations: it explains the return structure (UUID, name, status, created_at) and provides an example response. It also mentions a link to the UI. 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 well-structured, front-loaded with the key instruction, and uses bullet points and an example response. Every sentence adds value, and it is concise without being terse.

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 (list with pagination and search), the description covers purpose, usage, parameters, return structure, and an example. It does not mention error conditions or empty responses, but these are minor omissions. The output schema is implied by the example response.

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 descriptions for all three parameters. The description adds value by reiterating default values (limit 7, offset 0) and providing usage guidance for offset (asking user if they want more composes). It also explains the search_string as substring search.

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 explicitly states 'Get a list of all image builds (composes) with their UUIDs and basic status.' It uses a specific verb+resource and distinguishes from sibling tools like get_compose_details by stating that this returns the UUID needed for that tool.

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 strong usage guidance: 'ALWAYS USE THIS FIRST' when checking image build status or finding builds. It lists common use cases and instructs to ask the user about adapting offset for pagination. It does not explicitly state when not to use, but the context makes it 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 indicate readOnlyHint and openWorldHint. The description adds important behavioral context beyond annotations, such as the limited version support for RHEL and the unsupported status of CentOS Stream. This helps the agent understand the tool's behavior without contradicting annotations.

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

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

The description is very concise, using sections, emoji, and bold for clarity. Every sentence adds value: immediate usage instruction, key distribution details, and return type. No fluff.

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 zero parameters and an existing output schema, the description is complete. It explains what distributions are included/excluded and returns a list, providing sufficient context for the 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?

There are no parameters (schema coverage 100%). The description explains the return value ('List of distributions'), adding meaning beyond the schema. Since no parameters, it effectively covers what the tool outputs.

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 retrieves a list of distributions for image building. It specifies support for RHEL (only latest minor version), Fedora (similar but no official versions), and explicitly mentions CentOS Stream is not supported, distinguishing it from other image-builder 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 includes '🟢 CALL IMMEDIATELY - No information gathering required,' which provides explicit usage guidance. It also explains distribution specifics, helping the agent decide when to use this tool, though it does not directly compare to 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 indicate readOnlyHint and openWorldHint, and the description adds context about returned JSON and potential exception. It does not contradict 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 somewhat verbose with emoji and optional parameter section, but purpose is front-loaded. Could be more concise.

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 exists and annotations are present, the description is complete enough, covering return value, parameter usage, and error handling.

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%, but description adds value by explaining the purpose of the endpoints parameter (reducing spec to selected paths, transitive references) and linking to specific tools.

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 'Get' and the resource 'OpenAPI spec', and distinguishes it from sibling tools that focus on other resources like blueprints or composes.

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 explains use cases (e.g., get details for a new blueprint) and when to use the optional endpoints parameter (for prepare payloads). It lacks explicit exclusions but provides clear context.

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 the tool is read-only and open-world. The description adds no additional behavioral details beyond stating what it returns. It does not contradict 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 extremely concise, with a clear structure: purpose, when to use, a critical note, and return value. No unnecessary 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 simplicity, the description covers all necessary aspects: purpose, usage context, and return value. It is complete for the task.

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 schema coverage is 100%, so the description does not need to add parameter details. The baseline for 0-param tools is 4.

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 purpose: to fetch the organization ID for RHEL image registration. It uses a specific verb and resource, and the context distinguishes it from sibling tools (e.g., image-builder 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?

Explicit guidance is provided: 'Always use this tool when enabling registration for Red Hat services in a blueprint.' It also warns against using placeholder IDs, reinforcing correct 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 indicate readOnlyHint=true, so safety is clear. Description adds no behavioral details (e.g., case sensitivity, exact match, single result). With annotations covering the risk profile, this is acceptable but not enhanced.

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 verb+resource+method. No wasted words; efficient and clear.

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 lookup tool with an output schema, the description covers the essential purpose. Minor improvement could specify return granularity (single vs. list) but not necessary given output 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%, so the schema already documents the 'hostname' parameter well. The tool description adds no extra semantics or format guidance, earning the 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?

Description clearly states verb 'Find', resource 'a host', and method 'by hostname/display name'. It effectively distinguishes from sibling tools like inventory__list_hosts which do broader listing.

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: use when you have a hostname. No explicit when-not-to-use or alternatives are given, leaving the agent to infer from context. This is minimally adequate but lacks guidance compared to 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 declare readOnlyHint=true, and the description is consistent (get operation). Description adds specific return fields, enhancing transparency. No mention of limits or errors, but the simple nature of the tool (1 param, output schema) makes this acceptable.

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?

Description is concise (2-3 sentences) with a clear purpose statement followed by a bullet-like list of return data categories. Every sentence adds value, 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?

Given the tool has one parameter, an output schema exists, and annotations declare readonly, the description covers all necessary context: what it does, what it returns, and how to call it. The agent has sufficient information 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 sole parameter (host_ids) is described in the schema as 'Comma-separated list of host IDs (UUIDs) to retrieve.' The description adds context by listing the expected fields in the response, which helps the agent understand the value of using this tool. With 100% schema coverage, baseline is 3; additional context raises to 4.

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 clearly states 'Get detailed information for specific hosts by their IDs' and lists the types of data returned (identifiers, network info, cloud provider, etc.). This distinguishes it from sibling tools like inventory__find_host_by_name (search by name) and inventory__list_hosts (list with filters).

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?

Description implicitly tells when to use (when you have host IDs and need comprehensive details). It does not explicitly mention when not to use or compare to alternatives, but the sibling names provide context. A clear usage scenario 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?

Annotations already declare readOnlyHint=true, and the description adds valuable behavioral context by warning about large response sizes and recommending input limits. No contradictions 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 reasonably concise, with a clear first sentence followed by a bullet-like list of data included. It is front-loaded with the core purpose, though the list could be slightly tightened.

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 presence of an output schema and annotations, the description is fairly complete: it explains what data is returned, warns about response size, and provides input recommendations. It covers the essential context for a read-only data retrieval 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% for the single parameter 'host_ids', and its description already includes the key usage guidance. The tool description adds no additional parameter semantics beyond what the schema provides.

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 gets 'detailed system profile information for specific hosts' and enumerates specific data categories (CPU, memory, network, etc.), which precisely defines its scope and distinguishes it from simpler sibling tools like inventory__get_host_details.

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 input schema description provides a crucial usage guideline: 'ALWAYS supply one or two UUIDs at a time! Expect really large responses which will overload your context.' However, the main description lacks explicit guidance on when to use this tool versus alternatives or 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=true. The description is consistent but adds no additional behavioral context (e.g., permissions, error handling, or side effects).

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 a concise single sentence that immediately conveys the tool's purpose. No wasted words, but could be slightly expanded for clarity.

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 with one parameter and an output schema. The description is minimally adequate but does not explain the structure of returned tags or any non-obvious behavior.

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 parameter description. The tool description does not add any parameter-level detail beyond what the schema provides.

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 'Get' and resource 'tags for specific hosts'. It is clear but does not differentiate from sibling tools like inventory__get_host_details or inventory__list_hosts.

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 no guidance on when to use this tool versus alternatives, nor any context about prerequisites or limitations.

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 adds a critical behavioral trait: using per_page=10 to avoid performance degradation and context overflow. This is beyond the readOnlyHint annotation, providing actionable context about side effects and best practices.

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?

Description is two sentences with a clear critical section. No extra words, front-loaded with purpose. 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 13 parameters, full schema coverage, and an output schema, the description adequately covers usage with a critical note. It lacks details on pagination beyond per_page, but that is likely covered by the output schema. Overall, sufficient 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?

Schema covers 100% of parameters. The description adds significant value for the per_page parameter by emphasizing the default and warning against increasing it unless explicitly requested. Other parameters are described only in schema, but the added guidance is substantial.

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 states 'List hosts with filtering and sorting options', which is a specific verb and resource. It clearly distinguishes from sibling tools like inventory__find_host_by_name and inventory__get_host_details by indicating a listing operation with filtering.

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 explicit critical guidance on using per_page=10 first and only increasing if user explicitly asks. This is a clear usage instruction. However, it does not explicitly mention when not to use this tool versus alternatives, though siblings suggest different use cases.

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 provide readOnlyHint=true, and the description adds that the dashboard 'fetches data directly from the server,' implying no side effects. The description does not contradict annotations and provides reasonable context, though it could detail resolution or pagination 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 concise: three sentences covering purpose, usage preference, and data source. Every sentence is meaningful and front-loaded with the core purpose.

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 with 11 parameters and no output schema, the description covers purpose and usage but fails to describe the return format or result structure. It mentions 'interactive dashboard' but does not clarify what the tool returns, which is a notable gap.

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 only reiterates that 'all filter parameters are optional,' which adds minimal meaning beyond the schema's own descriptions. No additional parameter guidance is provided.

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 explicitly states the tool 'Show, list, or display fleet inventory in an interactive dashboard,' providing a clear verb and resource. It also distinguishes itself from the sibling tool list_hosts by specifying when to prefer this tool (visual display) vs. raw data.

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 directly advises to 'PREFER this tool over list_hosts whenever the user wants to see, show, list, or display hosts or fleet inventory' and reserves list_hosts for raw data processing. This offers explicit context for when to use 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 indicate read-only and idempotent behavior. The description adds substantial context: explains the return format, modes, and parameter roles. It also includes a 'CALL IMMEDIATELY' note, reinforcing the safe, non-destructive nature. 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 well-structured with sections and bullet points, making it easy to scan. However, it is somewhat lengthy; some details could be condensed while retaining clarity.

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 complexity (6 parameters, multiple modes), the description is thorough. It covers usage context, parameter selection, and return structure comprehensively. The presence of an output schema does not undermine the description's completeness as it still adds interpretive value.

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%, but the description goes beyond by providing usage rules for each parameter (e.g., using 'application_stream_name' for human-friendly names, 'name' for technical names). This adds significant practical 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 title and description clearly state it retrieves Application Streams lifecycle information. It specifies the resource (Application Streams) and action (get lifecycle), but does not explicitly differentiate from sibling tools like planning__get_relevant_appstreams, leaving some ambiguity.

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 explicit when-to-use guidance ('Use this tool when the user asks about Application Streams lifecycle') and parameter selection advice. However, it lacks explicit when-not-to-use context or alternative tool references.

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 adds context beyond annotations: explains that relevance is computed backend based on actual host data, no client-side filtering. This aligns with readOnlyHint and idempotentHint. No contradiction.

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?

Well-structured and front-loaded: starts with 'CALL IMMEDIATELY,' then usage scenarios, parameter instructions, and output schema. Every section serves a purpose; no wasted text.

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 complexity (inventory-based relevance, lifecycle dates, sibling tool), the description fully covers purpose, usage, parameters, and output schema. No gaps remain.

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?

Despite 100% schema coverage, the description enriches parameter meaning: major/minor restrict relevance to specific RHEL versions, include_related distinguishes current usage vs. upgrade recommendations. Provides concrete guidance that the schema alone doesn't capture.

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 retrieves relevant Application Streams from the user's inventory, including lifecycle/support dates. It distinguishes itself from the sibling tool `get_appstreams_lifecycle` by specifying it focuses on inventory relevance vs. an exhaustive catalog view.

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 explicit guidance: 'CALL IMMEDIATELY - No information gathering required,' example queries, when to use vs. lifecycle tool, and how to set parameters for scoping (major/minor) and include_related. Also explains when not to use (exhaustive catalog).

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. The description adds value by explaining the return schema, parameter behaviors (e.g., related=true for include_related), and response guidance. No contradictions 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 well-structured: purpose, call indicator, examples, parameter guidance, response guidance, and return schema. Every section adds value. Slightly long but justified by the tool's complexity.

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 all essential aspects: purpose, when to use, parameter semantics, response structure, and response guidance. No significant gaps. Sibling differentiation is clear from the title and description.

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 at 100%, but the description enhances with practical usage guidance: how to scope with major/minor and the meaning of include_related with the related flag. This adds significant value beyond 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 returns RHEL lifecycle information for systems in the requester's inventory. It uses specific verbs and resources, and distinguishes from sibling planning__get_rhel_lifecycle by focusing on inventory relevance. Examples further clarify 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 description provides explicit use cases with example questions and parameter guidance (e.g., setting major/minor, include_related). It does not explicitly name the alternative tool for general lifecycle questions, but the presence of sibling planning__get_rhel_lifecycle implies the distinction.

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, and open-world hints. The description adds value by detailing the return structure (meta and data fields) and explaining what a count of 0 means. No contradictions are present.

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: a short summary, a call-to-action, usage guidance, and a detailed output description. Every sentence adds value, and it is front-loaded with the most important 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?

Given the rich annotations and detailed output schema in the description, the description is complete. It covers purpose, usage, behavior, and return format without missing critical information.

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% (both parameters have descriptions). The description does not add any additional meaning to the parameters beyond what the schema already provides. Baseline 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 clearly states the tool's function: 'List relevant upcoming package changes, deprecations, additions and enhancements to user's systems.' It specifies the verb 'List' and the resource, and distinguishes from the sibling tool 'get_upcoming_changes' by indicating when to use this one.

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?

Explicit instructions are provided: 'Use this tool to answer questions about upcoming package changes...' and 'Use this tool over get_upcoming_changes when the user asks about upcoming changes for their systems.' It also includes a 'CALL IMMEDIATELY' directive. However, it doesn't cover when not to use the tool explicitly.

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 readOnlyHint, idempotentHint, and openWorldHint, which cover safety and idempotency. The description reinforces this with 'CALL IMMEDIATELY - No information gathering required' and details the return structure, adding context beyond the annotations. No contradictions.

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 somewhat lengthy but well-structured with headings, bullet points, and emojis. It front-loads the core purpose and call-to-action. Some redundancy exists, but overall it is easy to scan and interpret.

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 no parameters and comprehensive annotations, the description covers all necessary context: what the tool returns, how to interpret results for different use cases, and that it is a safe read operation. The return structure is detailed in the description, making it fully self-contained.

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?

There are no parameters in the input schema, and schema coverage is 100%. The description does not need to add parameter semantics. 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 clearly states it returns life cycle dates for all RHEL majors and minors, using a specific verb and resource. It distinguishes from sibling tools like planning__get_appstreams_lifecycle by focusing on RHEL, and the extensive usage guidance reinforces 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 description explicitly tells the agent when to use this tool (e.g., user asks for RHEL versions and lifecycle timelines) and provides step-by-step instructions for different query types (major-only, specific minor, date windows). It also says to call immediately with no information gathering, which is excellent 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 set readOnlyHint, idempotentHint, and openWorldHint. The description adds behavioral guidance like 'CALL IMMEDIATELY' and post-filtering instructions. No contradictions.

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 well-structured with an emoji for emphasis, a clear instruction line, usage note, and return format. Slightly lengthy due to return details, but still concise and 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 no parameters, full annotations, and an output schema, the description is complete. It covers purpose, usage, and behavior. Minor missing detail on what 'upcoming' means, but 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?

There are zero parameters, and schema coverage is 100%. The description does not need to add parameter details. Baseline for no parameters is 4.

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 upcoming package changes, deprecations, additions, and enhancements. It uses specific verbs and resources, and distinguishes from siblings by emphasizing that it provides a full list, with filtering instructions for specific versions.

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 'CALL IMMEDIATELY - No information gathering required' and instructs when to use it for full lists or specific RHEL versions. It does not explicitly mention when not to use, but the context is 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?

Discloses gzipped response handling, which is beyond schema. No annotations exist, so description carries full burden. It does not mention authentication, rate limits, or the structure of the response (though output schema exists).

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?

Description is brief with three sentences. Some repetition between first and second sentences, but overall concise and front-loaded with the main purpose.

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, description doesn't need to detail return values. It covers the core purpose and gzip behavior. Lacks mention of pagination despite limit/offset parameters, but not critical given 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 coverage is 100% with each parameter described. The description does not add additional meaning beyond the schema, so baseline score 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?

Description clearly states the tool gets access information for all Red Hat insights applications. The verb 'Get' and resource 'access information for all Red Hat insights applications' are specific, and no sibling tool competes directly.

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 explicit usage context: 'Use this when you need to see access permissions across all applications.' However, it does not mention when not to use it or alternatives, but given no sibling rbac tools, it's adequate.

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 readOnlyHint=true, so the description's behavioral claim is consistent. It adds no new behavioral traits (e.g., rate limits, auth) beyond the expected read operation, but is adequate.

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 mostly concise but contains slight redundancy (the 'Returns' section summarizes information already in the preceding sentence). The emoji and call-to-action are helpful but add token count.

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 presence of an output schema (which documents return values), the description sufficiently covers what the tool does and what details are returned. It is complete for a simple retrieval 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?

The input schema already describes the 'name' parameter with a clear description ('The name of the activation key to retrieve'). With 100% schema coverage, the description adds no new meaning, placing it at 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?

The description clearly states it retrieves a specific activation key by name, using a strong verb ('Get') and specifying the resource. It differentiates from the sibling 'rhsm__get_activation_keys' which lists all keys.

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 'CALL IMMEDIATELY - No information gathering required,' indicating no prerequisites. It implies usage when you have a key name, but does not explicitly mention the alternative list endpoint when the name is unknown.

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, so the description adds value with the 'CALL IMMEDIATELY' behavioral cue. It explains the purpose of activation keys for RHEL registration, which supplements the annotation without contradiction.

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 relatively concise with a clear opening, a call-to-action flag, and a brief explanation. It could be slightly more concise, but overall well-structured and 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 low complexity, full schema coverage, presence of annotations, and existence of an output schema, the description provides all necessary context: what the tool does, when to call, and what it returns (list of activation keys with details).

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 for both parameters (limit, offset) with defaults and descriptions. The description does not add any additional parameter semantics beyond what is already in the schema, so baseline 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 'Get the list of activation keys available to the authenticated user,' which clearly specifies the action (get) and resource (activation keys). It distinguishes from sibling tools like 'rhsm__get_activation_key' (singular) by indicating it returns a list.

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?

Includes a 'CALL IMMEDIATELY - No information gathering required' flag, guiding the agent to invoke without prior steps. However, it does not explicitly mention alternative tools for getting a single key or when not to use 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 indicate readOnlyHint=true. The description adds context about using VMAAS and explains the meaning of 'affected_packages', enhancing transparency beyond the annotation's simple read hint.

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 somewhat repetitive ('Explain why CVEs...' appears twice) and could be more concise. However, it is front-loaded with the main purpose and structured coherently.

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 presence of an output schema, the description sufficiently covers what the tool does, required inputs, and even suggests a next step (Remediations). It provides complete context for a tool explaining CVEs per system.

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 examples for both parameters. The description adds context about needing system UUID from inventory and CVEs, but this doesn't significantly augment the semantic meaning already provided by 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 explains why CVEs affect the environment, detailing affected packages and fix info. It uses specific verbs like 'explain' and references VMAAS, distinguishing it from sibling tools that list CVEs or systems.

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 mentions prerequisites (system UUID and CVEs) and suggests using the Remediations tool for updates. However, it does not explicitly specify when to use this tool versus alternatives like vulnerability__get_cve_systems or vulnerability__get_cves.

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, indicating a safe read operation. The description adds useful context beyond annotations by listing the specific metadata returned (CVSS scores, severity, advisories, known exploits, etc.), which helps the agent understand the tool's behavior without contradiction.

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 (4 sentences) and front-loaded with the main purpose. It clearly lists the metadata items but has some redundancy (e.g., 'description' mentioned twice). Overall efficient with minimal 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?

Given the presence of an output schema (as per context signals) and comprehensive annotations, the description covers the tool's purpose, key parameters, and returned data fields adequately. It references the OpenAPI spec for more details. No major gaps for a read-only 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?

Input schema coverage is 100% and both parameters are well-described in the schema (cve with example, advisory_available with boolean string interpretation). The description does not add any new semantic meaning beyond what the schema already provides, 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 clearly states the tool's purpose: 'Get details about specific CVE.' It lists the specific metadata returned, distinguishing it from sibling tools like vulnerability__get_cves which likely lists CVEs. The verb 'Get' combined with 'details' precisely defines the action and 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 use when needing detailed CVE information, but does not explicitly state when to use this tool versus alternatives like vulnerability__get_cves or vulnerability__get_cve_systems. No when-not or alternative guidance is provided.

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 provide readOnlyHint=true, so the description's disclosure of returning 'CVE metadata, how many systems are affected by each CVE, and more' adds some output context but no significant new behavioral traits (e.g., pagination limits, authorization). The description does not contradict annotations, and the disclosure is adequate but minimal.

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, which is moderately concise. The second sentence ('This provides an overview...') largely restates the first sentence, adding redundancy. The third sentence refers to an OpenAPI spec, which is a weak crutch. It could be condensed to one or two sentences without losing meaning.

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 has 11 optional parameters with many filters, the description is quite generic. It states it's an overview but doesn't hint at the extensive filtering, sorting, or pagination capabilities (though schema descriptions exist). An agent might underestimate the tool's flexibility. The description is minimally complete for a basic understanding but not comprehensive.

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 high (91%), so the baseline is 3. The description adds no parameter-level details beyond what the schema provides. It mentions 'CVE metadata' and 'systems affected' but does not explain how to use filters like cvss_from, impact, or known_exploit. The description does not compensate for the one undocumented parameter (filter_).

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 'Get list of CVEs affecting the account' with a specific verb and resource. It indicates an overview of vulnerabilities across the entire system inventory, which distinguishes it from sibling tools like vulnerability__get_cve (single CVE details) and vulnerability__get_cve_systems (systems per CVE). However, it does not explicitly differentiate from siblings, so it's not 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?

The description says 'Use this endpoint to get an overview' but provides no guidance on when not to use it or alternatives. Given siblings like vulnerability__get_cve and vulnerability__get_cve_systems, the lack of explicit exclusions or comparisons leaves an agent without clear decision criteria.

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, indicating a safe read operation. The description adds minimal behavioral context (it's a 'report'), but does not disclose pagination behavior or output format beyond what annotations and schema 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 short (three lines) but has slight redundancy between the first two sentences. It conveys the core purpose efficiently without unnecessary details.

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, an output schema exists, and parameters are fully described in the schema, the description is sufficient. It does not explain return values, but the output schema fills that gap.

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 the schema already documents all parameters. The description does not add additional meaning beyond stating the overall purpose, so 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 clearly states the verb ('Get'), the resource ('list of systems'), and the constraint ('affected by a given CVE'). This distinguishes it from sibling tools like vulnerability__get_systems which lists all systems without a CVE filter.

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 'Use this tool to obtain list of all affected systems for a given CVE.' This provides clear context for when to use the tool, though it does not explicitly mention alternatives or 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?

The readOnlyHint annotation already indicates a safe read operation. The description adds no extra behavioral details such as rate limits, authentication, or response size. It confirms JSON format but goes no further.

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 a single sentence of 10 words with no fluff. It is front-loaded and 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?

Given no parameters, an output schema exists (though not provided), and the tool is a simple OpenAPI spec retrieval, the description is complete enough. It tells the user exactly what to expect.

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?

There are no parameters, so the description need not add parameter meaning. The schema coverage is 100% trivially. The baseline for 0 parameters is 4, and the description meets it.

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 'Get', the resource 'Red Hat Insights Vulnerability OpenAPI specification', and the format 'JSON'. It distinguishes the tool from sibling tools like image-builder__get_openapi by specifying the service.

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 no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or when not to use it. For a simple tool, some context could be added.

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`, so the tool is known to be read-only. The description adds no new behavioral traits (e.g., no mention of pagination details, performance, or side effects) but does not contradict 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 with 6 sentences, but includes some redundancy (e.g., 'This is a report...' restates the first sentence) and a mention to refer to the OpenAPI spec, which is of limited value. Still, it is front-loaded with the key guidance.

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 existence of an output schema, the description covers the tool's purpose, usage, and distinguishing guidance. No critical gaps are present for a read-only list endpoint with well-documented parameters.

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 all parameters described in the input schema. The description does not add meaning beyond what the schema provides, 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 states 'Get list of CVEs affecting a given system', which clearly identifies the verb and resource. It differentiates from siblings by noting that `get_cves` is preferred for filtered results, but the core purpose 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?

The description explicitly states 'IMPORTANT: Prefer `get_cves` as `get_cves` can filter for CVEs with available advisories.' This provides clear when-to-use and when-not-to-use guidance, naming an alternative 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?

The annotations already indicate readOnlyHint=true, so the description doesn't need to restate. It adds that both affected and not affected systems are returned, and lists returned fields. However, it does not disclose pagination behavior, rate limits, or sorting default beyond what the schema provides.

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 note about the OpenAPI spec. It is front-loaded with the core purpose and conveys key 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?

Given the 6 parameters (all optional with descriptions), an existing output schema, and no nested objects, the description sufficiently covers the tool's behavior. It mentions the returned fields and the scope (both affected and not affected), providing a complete picture for a list endpoint.

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 baseline is 3. The description does not add meaning beyond the schema; it mentions response fields (last check-in, etc.) but not input parameters. No additional value for parameter semantics.

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 clearly states it retrieves a list of systems from the Vulnerability inventory, including specific fields like last check-in, system name, workspace name, RHEL version, and CVE count. It distinguishes from siblings like vulnerability__get_cve_systems by noting it returns both affected and not affected systems, but could be more explicit.

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?

No guidance provided on when to use this tool versus alternatives (e.g., vulnerability__get_cve_systems, vulnerability__get_system_cves). The description only states what it does, not the context or prerequisites.

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 adds context beyond the readOnlyHint annotation by specifying it is an interactive dashboard that fetches data directly from the server, with no write behavior implied. No contradictions.

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 structured with a clear purpose statement, usage guidelines, and technical details. It is slightly redundant with schema but overall concise and well-organized.

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 adequately explains input and behavior but does not mention return format or output details, which would be helpful given no output schema. The dashboard concept implies a list of CVEs but is not explicit.

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 parameters are already well-documented. The description adds no new semantic information beyond restating system_uuid behavior, which is already in 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 shows, lists, or displays CVEs in an interactive dashboard, at account or system level. It explicitly distinguishes from sibling tools get_cves and get_system_cves by indicating this tool is for display and those are for raw data.

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 to prefer this tool over get_cves and get_system_cves for displaying CVEs, and to use those only when raw data is needed. It also explains behavior based on system_uuid parameter.

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