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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false and openWorldHint=true, so the safety and network profile is covered. The description adds the return format (markdown) and the fetch-the-whole-page behavior, which is useful, but says nothing about auth needs, rate limits, or failure on non-existent pages.

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

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

Three short sentences, front-loaded with the core action, then the workflow placement, then the input format. Zero filler.

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

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

With no output schema, the description usefully discloses that the return is markdown page content, completing the picture for a single-parameter fetch tool. It omits edge-case behavior (invalid or missing URLs), which is a minor 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% and the schema already documents the single 'url' parameter with format=uri. The description adds the domain example ('https://docs.parallels.com/...'), a marginal reinforcement of what the schema already states. 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?

States a specific verb ('Fetch') and resource ('full markdown content of a specific Parallels documentation page'), and implicitly distinguishes itself from the search sibling by emphasizing 'full ... rather than excerpts.' An agent can tell it apart from ras_docs_search immediately.

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?

Explicitly says 'Use after ras_docs_search when you need the complete page (prerequisites, full procedure, all options) rather than excerpts' — naming both the alternative and the condition that selects this tool. Nothing is left to inference.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive behaviour, so the safety profile is covered. The description adds useful behavioural context by describing the return format ('one or more excerpts with titles and direct links') and the external documentation scope, though it does not mention rate limits or authentication requirements.

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

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

Three sentences, front-loaded with the core action, followed by concrete usage guidance and the return format. Every sentence earns its place with no redundancy or filler.

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

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

For a simple search tool with one fully documented parameter and rich annotations, the description covers purpose, usage, alternative tool, and return shape. No output schema exists, but the description adequately describes what is returned, so an agent has everything needed to invoke it correctly.

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

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

Schema description coverage is 100%, and the single query parameter is fully documented in the schema as accepting feature names, error text, settings, etc. The description adds no further parameter syntax or format details beyond what the schema already provides, so the baseline 3 is appropriate.

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

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

The description clearly states a specific verb and resource: searching the official Parallels documentation. It explicitly distinguishes itself from the sibling ras_docs_get_page by positioning itself as the step before fetching a full page, so an agent can tell them apart immediately.

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

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

It provides explicit use cases: validating configuration found via RAS API tools, looking up documented behaviour, and finding the right page before fetching it in full with ras_docs_get_page. The alternative tool and the condition for choosing it are named directly.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and open-world behavior, so the safety profile is fully covered. The description adds the shape of what is returned, but says nothing about pagination behavior or result size, which is the main remaining unknown for a list tool.

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

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

Two tight sentences with no filler, and the resource scope is front-loaded ahead of the use cases. Slightly repetitive in that the use-case clause restates the same audit theme three ways, but nothing is wasted.

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

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

With no output schema, the description usefully enumerates the fields returned, and annotations carry the safety profile while the schema documents all three optional parameters. The only omission is any note on result volume or truncation 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 description coverage is 100%, and the schema parameters (limit, fields, filter) are already well documented inline. The description adds no additional meaning about filtering, limiting, or field selection, so the baseline 3 applies.

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

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

The description opens with a specific verb and resource ("List RAS farm administrator accounts") and enumerates the returned content (usernames, roles, permissions, group membership). No sibling tool covers admin accounts, and the scope is unambiguous without opening the schema.

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

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

It gives three concrete use cases: auditing admin access, verifying role assignments, and reviewing who holds administrative control. That is clear context, though it names no exclusions or alternative tools (and no sibling competes for this data).

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, destructiveHint=false, and openWorldHint, so the safety profile is fully covered. The description adds the content scope (domain/backup/global options) but nothing about auth requirements, rate limits, or response shape beyond that list.

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

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

Two sentences, zero filler, with the resource named first and the use cases second. Efficient and front-loaded, though the content enumeration and the usage list overlap slightly in intent.

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

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

No output schema exists, so the description's enumeration of returned settings categories does useful work in telling the agent what to expect. With 0 params and full annotation coverage, nothing essential for a correct call is missing.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. No syntactic or format guidance is needed for a parameterless read.

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

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

States a specific resource (RAS farm configuration) and enumerates the contents — farm name, domain, backup settings, global options — so the agent knows exactly what comes back. It distinguishes itself from siblings like ras_farm_get_licensing or ras_farm_get_version by being the broad setup read, though it doesn't explicitly name those siblings.

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

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

Gives three concrete use cases: reviewing overall farm setup, verifying domain configuration, and checking backup scheduling. That is clear positive guidance, but it offers no exclusions or explicit routing away from the narrower farm_get_* siblings when those would suffice.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description's added value is the inventory of what actually comes back (license type subscription/perpetual, expiration date, seat count, usage, activation status), which is genuinely useful given there is no output schema. It does not mention permissions or freshness, so not a 5.

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

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

Two sentences, no filler. The resource is front-loaded and the enumerable return fields are listed compactly, followed by the usage triggers. Every clause earns its place.

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

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

With no output schema and no inputs, the description is the only place an agent can learn what this call yields, and it lists the major fields. It does not spell out the shape (e.g., single object vs. per-server rows) or whether unlicensed state returns an error, leaving minor gaps.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. A 4 is the baseline for a parameterless tool, and the description correctly avoids inventing filtering options that the schema does not support.

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 names a specific resource (RAS licensing status) and enumerates the exact facets it exposes: license type, expiration, seat count, usage, activation status. This cleanly separates it from sibling 'get_*' tools like ras_farm_get_config or ras_farm_get_version. It lacks an explicit contrast sentence against those siblings, which keeps it short of a 5.

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

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

It gives concrete scenarios for invocation: check compliance, verify capacity, diagnose licensing issues. That is clear context for when to reach for this tool, but no exclusions or named alternatives (e.g., 'use ras_farm_get_administrators for account-level issues'), so it stops at 4.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds context beyond that — that this is the SMTP config backing RAS email notifications and that it is useful for diagnosing delivery failures — and discloses the shape of the returned data, which matters since there is no output schema.

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

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

A single compact sentence pair that front-loads what the resource is before the usage guidance. Every clause carries information; no filler.

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

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

With no output schema, the description usefully names the key returned fields (server address, port, sender details) and gives a usage rationale, which is sufficient for a zero-parameter read tool. It could be slightly stronger by distinguishing itself from the notifications sibling, but nothing essential is missing.

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

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

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

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

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

States a specific verb+resource ('SMTP mailbox configuration') and enumerates the returned content (server address, port, sender details), which is more than a restatement of the name. It does not explicitly distinguish itself from the nearby ras_site_get_notifications sibling, leaving some ambiguity about which one surfaces notification-related settings.

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

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

Provides a clear when-to-use context: verifying email notification settings or troubleshooting delivery failures. It stops short of naming alternatives or exclusions (e.g., ras_site_get_notifications) that would help an agent pick the right tool between overlapping notification-related resources.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds no behavioral context beyond that — nothing about data freshness, whether 'counters' are live or historical, cost, or auth requirements — so it is minimum viable rather than additive.

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

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

Two sentences, front-loaded with the resource before the usage note. Minor redundancy: 'monitoring settings' in sentence one is echoed by 'check monitoring configuration' in sentence two.

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

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

With no output schema, the description carries the burden of indicating what comes back, and 'counters' plus 'thresholds and monitoring settings' only gestures at the payload without naming the metrics returned. For a simple zero-param read tool this is adequate but thin.

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

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

The tool takes zero parameters, so there is no parameter semantics to explain and the baseline of 4 applies. The description does not need to compensate for any schema gaps.

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

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

States a specific resource ('performance monitor configuration and counters for the RAS farm') and narrows scope to resource utilisation thresholds and monitoring settings. It is clearly distinct from the other ras_farm_* and ras_infra_* siblings, though it never names an alternative to route against.

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?

'Use this to review performance baselines or check monitoring configuration' gives an implied when-to-use, but it largely restates the purpose rather than distinguishing it from any sibling. No when-not conditions or prerequisites are 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 declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered externally and no contradiction exists. The description adds content scope (the three config sub-areas) but nothing beyond that, such as return shape or auth needs.

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

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

Two sentences, front-loaded with the resource and then the intended use. No filler, though the second sentence is somewhat redundant with the first's framing.

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 no-argument read-only config getter this is nearly sufficient: it names the resource and its main sub-components and the reason to call it. With no output schema, a hint at the returned structure would help, but the enumerated sub-areas largely cover 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; per the baseline this scores 4. No argument-level semantics are needed or missing.

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

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

States a clear verb/resource: it returns the RAS farm's reporting configuration, and enumerates the sub-areas (report scheduling, data retention, database connection). This distinguishes it well from infrastructure or site siblings, though it does not explicitly contrast with any named alternative.

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?

"Use this to verify reporting is enabled and properly configured" gives a concrete use case, which is stronger than most sibling getters. It stops short of naming when NOT to use it or which alternative covers adjacent reporting concerns.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true and destructiveHint=false, so safety is covered. The description adds the substantive behavioral fact that the call returns version plus build number, which is what the agent actually needs to reason about the result. It says nothing about caching, rate limits or auth, but none of those are material for a trivial read-only metadata call.

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

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

Three short sentences, front-loaded with what the tool is, then what it returns, then why to use it. Slight redundancy between the opening noun phrase and the 'Returns...' sentence, but no filler or padding.

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

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

With no parameters and no output schema, the description carries the burden of describing returns, and it does ('current API version and build number'). For a tool this simple that is sufficient; only the exact field names/shape of the response remain unspecified, which is a minor 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?

The input schema has zero properties, so there are no parameter semantics to clarify; the baseline for a no-parameter tool is 4. The description correctly avoids inventing or implying any inputs.

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

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

The description names a specific verb and resource ('Returns the current API version and build number') and repeats the tool's scope in plain language, so an agent knows exactly what it gets. It stops short of explicitly differentiating itself from any sibling, though no sibling tool covers API version/data-version metadata, so the risk of confusion is low.

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

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

It gives a clear use case: 'verify the API version is compatible or check which features are available.' That is real when-to-use guidance rather than implied usage. It does not state when not to use it or name any alternative, but for a zero-parameter version endpoint there is no plausible alternative to route to.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds that the result set can be large and that fields/filter/limit help narrow it, but this largely duplicates the schema and does not disclose auth requirements, pagination behavior, or other operational context.

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

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

Two sentences, front-loaded with the core purpose and returned fields, then the usage contexts. Every sentence earns its place with no redundancy.

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

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

For a read-only list tool with rich annotations, full schema descriptions, and no output schema, the description covers what is needed: what it lists, when to use it, and how to narrow results. Nothing critical is missing.

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

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

Schema description coverage is 100%, so the schema already explains limit, fields, and filter in detail. The description only names these parameters without adding syntax, defaults, or interpretation 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 states a specific verb ('List'), resource ('Parallels RAS agents'), and scope ('across the farm'), and enumerates returned fields (hostname, IP, OS, agent version, status). It is clear what the tool does, but it does not explicitly distinguish itself from infrastructure siblings like ras_infra_get_connection_brokers or ras_infra_get_providers.

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

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

It provides three concrete use cases: verifying agent deployment, diagnosing connectivity, and checking agent versions. However, it gives no guidance on when not to use this tool or which sibling tool to prefer for related infrastructure queries.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered without description help. The description adds the useful detail of what each row contains, but says nothing about result size, pagination, or default limits beyond what the schema states. Adequate but not rich.

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

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

Two sentences with zero padding: the first defines the resource and its columns, the second lists the tasks it supports. Front-loaded and every clause carries information.

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

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

With no output schema, the description appropriately compensates by naming the returned columns, and the read-only annotation covers the operation's semantics. It is essentially complete for a simple inventory getter, with only minor absence of result-size expectations.

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 limit, fields, and filter each documented in detail (defaults, maxima, case-insensitive matching, key-dropping). The description adds no parameter-level guidance beyond the schema, so the baseline 3 applies.

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

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

States a specific resource (SSL/TLS certificate inventory for the RAS farm) and even enumerates the returned fields (names, expiration dates, issuers, usage). This clearly separates it from siblings like ras_infra_get_agents or ras_infra_get_gateway_status, though it does not explicitly name a sibling it is distinct from.

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

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

Gives three concrete use cases — auditing certificates, checking upcoming expirations, and verifying assignments — which tell the agent exactly when to reach for this tool over other infra getters. It stops short of stating when not to use it or naming an alternative, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful domain context (brokers handle session brokering and load distribution) but says nothing about the result set scope, ordering, or response size behavior.

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

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

Three tight sentences with the resource and returned attributes front-loaded, followed by disambiguating context and then use cases. Nothing is redundant, though the middle domain-context sentence is the least load-bearing of the three.

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

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

For a read-only list tool with full schema coverage and no output schema, the description covers what is returned and when to call it. It does not clarify whether all brokers or only a site-scoped subset are returned, which is a minor residual 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 limit, fields, and filter are each documented in the schema itself, including the default/max on limit and the narrowing advice. The description adds no parameter-level meaning beyond that, making the baseline 3 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?

States the specific resource (connection brokers) and the exact attributes returned — status, priority, and configuration — which distinguishes it from siblings like ras_infra_get_sites or ras_site_get_tenant_broker. It reads as a noun phrase rather than an explicit verb+resource, but an agent can still tell what it fetches.

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?

Explicitly names three use cases: checking broker health, verifying primary/secondary priority, and diagnosing session routing. It gives clear positive guidance but does not state when NOT to use it or point to a more appropriate sibling for related broker questions.

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, destructiveHint=false, and openWorldHint. The description adds useful domain context about SCEP enrollment and troubleshooting but does not go beyond annotations to describe return format, pagination, or any nuanced behavioral traits.

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 short sentences with no filler. It front-loads the core purpose, then explains the domain and usage in a natural progression. Every sentence contributes to understanding the tool.

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

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

For a read-only status tool with rich parameter documentation and safety annotations, the description covers purpose and usage adequately. It does not explain return values or pagination, but no output schema exists; a brief note on the shape of the status response would make it fully complete.

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

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

Schema description coverage is 100%, so the schema already fully documents limit, fields, and filter. The description adds no parameter-specific meaning, which is acceptable given the schema's completeness, but it does not exceed the 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 clearly states the resource and implied action: enrollment server status. It adds domain context about SCEP certificate enrollment, which distinguishes it from generic infrastructure status tools. However, it does not explicitly name or differentiate itself from relevant siblings such as ras_infra_get_certificates.

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

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

It gives a clear when-to-use: checking enrollment server health or troubleshooting certificate enrollment failures. There are no explicit exclusions or named alternatives, so it falls short of a 5, but the usage context is well defined.

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, non-destructive and openWorld, so the safety profile is covered. The description adds field-level context (what a "status" actually contains) and the role gateways play, but says nothing about volume, pagination, or how the limit/filter interplay works beyond what the schema documents.

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

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

Three short sentences with the returned fields front-loaded and the usage hint last. The middle sentence about gateways providing external access is brief but earns its place by disambiguating the resource.

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

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

For a read-only informational tool with no output schema, the description names the returned data, so an agent knows roughly what comes back. Annotations carry safety and the schema carries paging/filtering, leaving no meaningful 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% and all three parameters (limit, fields, filter) are thoroughly documented in the schema with defaults, bounds, and guidance. The description adds no additional parameter meaning, so the baseline 3 applies.

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

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

States a specific verb+resource (gateway status) and enumerates exactly what the status contains: connection state, IP addresses, tunnel mode. It is clearly distinguishable from neighboring infrastructure status tools such as ras_infra_get_halb_status or ras_infra_get_enrollment_status.

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?

"Use this to monitor gateway health or troubleshoot external connectivity" gives explicit operational context for when to reach for it. It stops short of naming alternatives or when-not to use it, but the intent is unambiguous.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so safety behavior is covered. The description adds the conceptual content of a response (health, IPs, state), which is useful, but says nothing about pagination, default/max limits, or result volume beyond what the schema states.

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

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

Two tightly packed sentences with the resource and returned data front-loaded and the usage cue second; no filler.

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

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

No output schema exists, so the description carries return-value disclosure and does so reasonably by naming the field categories returned. It could say more about the row/list shape or filtering behavior, but it is adequate for a read-only monitoring 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% — limit, fields, and filter all carry detailed descriptions including defaults and caps. The description adds no additional parameter meaning, so the baseline 3 applies.

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

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

States a specific verb+resource (get status of HALB devices) and even expands the acronym and enumerates returned fields (device health, IP addresses, operational state). It is distinguishable from ras_infra_get_gateway_status and ras_site_get_load_balancing, though it never explicitly contrasts with those near-neighbors.

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?

"Use this to monitor load balancer availability or diagnose gateway connectivity" gives clear usage context and a diagnostic scenario. It stops short of naming when to prefer an alternative tool or any exclusions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered by structured data. The description adds the useful scoping fact that it returns only configured providers ('all ... configured'), but says nothing about pagination behavior or what per-provider attributes come back.

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

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

Two sentences, zero filler, with the enumeration of provider types front-loaded so the agent identifies the resource immediately and the use cases second.

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

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

No output schema exists, yet the description promises connectivity verification without indicating whether the response actually carries status/connectivity fields — a minor gap for an agent planning to parse results. Safety and parameter concerns are otherwise fully covered by annotations and 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% — limit, fields, and filter are each documented with defaults, bounds, and guidance in the schema itself. The description mentions no parameters, so it neither adds nor detracts; baseline 3 applies.

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

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

States a specific verb ('List') plus resource ('cloud and hypervisor providers configured in the RAS farm') and enumerates the concrete provider types (AVD, AWS EC2, Azure, Hyper-V, Nutanix, vCenter, ESXi). This makes it unmistakable versus siblings such as ras_infra_get_agents, ras_infra_get_vdi_hostpools, or ras_infra_get_sites.

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?

Explicitly names three use cases: verifying provider connectivity, checking provider types, and auditing multi-cloud config. It does not, however, state when NOT to use it or name an alternative sibling, so routing is clear but not fully bounded.

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/destructiveHint=false, so safety is covered. The description adds only domain background (pools group servers for load balancing) and no behavioral traits beyond the annotations — nothing about response size, pagination, or truncation behavior for a list endpoint.

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

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

Three short sentences, front-loaded with the action and resource. The middle sentence is useful background rather than waste, though it is not strictly necessary for invoking the tool.

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

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

For a read-only list tool with a fully documented schema and complete annotations, the description covers what the tool returns conceptually. The absence of an output schema means it could say more about response shape, but nothing essential to calling it correctly is missing.

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

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

Schema description coverage is 100% and all three parameters (limit, fields, filter) are thoroughly documented in the schema itself, so the baseline is 3. The description contributes no additional parameter meaning — it never mentions filtering or field projection.

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 gives a specific verb ('List') plus resource ('RDS host pool membership and configuration') and explains what host pools are. It is distinguishable from ras_infra_get_rds_hosts and ras_infra_get_vdi_hostpools by the RDS-hostpool framing, though it never explicitly contrasts them.

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

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

It offers three concrete use cases ('review pool composition, check host assignments, or verify pool settings'), which implies when to reach for it. However, it never names the adjacent tools (ras_infra_get_rds_hosts, ras_infra_get_vdi_hostpools) or states any exclusion, so the agent must infer the boundary itself.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds operational context not in the annotations: large-farm response sizing and the recommendation to narrow with filter/fields. 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?

Three tight sentences; the core purpose and returned fields come first, followed by usage and sizing tips. No redundancy or filler.

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

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

With no output schema, the description usefully enumerates the returned shape and covers when to use it plus how to keep responses manageable. Nothing an agent needs to invoke this read-only list tool correctly is missing.

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

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

Schema coverage is 100%, so baseline is 3. The description adds a concrete filter example ({status: 'online'}) and the strategic advice to narrow rather than raise limit, which goes slightly beyond the schema's field-level docs.

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

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

Names a specific verb (List) and resource (RDS session hosts) and enumerates the returned attributes (hostname, IP, agent status, active sessions, CPU/RAM, OS version). This makes it clearly distinct from the hostpool/agent siblings without needing to open either schema.

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

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

Gives explicit use cases — monitor host health, check capacity, troubleshoot RDS issues — and practical guidance for large farms. It stops short of naming alternatives (e.g. ras_infra_get_rds_hostpools or ras_sessions_list) or stating when not to use it.

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

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

Annotations already declare the safe read-only/idempotent/non-destructive profile, so the bar is lower. The description adds useful value by naming the returned content (provider names, metadata URLs, configuration details), which annotations cannot convey; pagination/edge behavior is left to the schema.

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

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

Two compact sentences, front-loaded with the resource and a dash-list of returned fields, followed immediately by the use case. No filler or redundancy.

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

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

Given no output schema, the description usefully sketches the return shape, and annotations plus a 100%-covered schema carry the rest. Adequately complete, with only minor omissions around result volume or filtering 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 description coverage is 100%, so limit, fields, and filter are fully documented in the schema itself. The description adds no syntax or semantics beyond that, making the baseline 3 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?

Specific verb (List) plus a precise resource (SAML identity providers) scoped to SSO, with the returned fields enumerated. An agent can tell what it retrieves, though it does not explicitly differentiate itself from near-neighbors like ras_infra_get_providers or ras_site_get_mfa.

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?

Explicitly frames the use case — auditing SSO configuration and troubleshooting SAML authentication — which gives clear context for when to call it. It stops short of naming a sibling alternative or stating when not to use it.

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

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds the domain context that multi-site deployments distribute infrastructure across locations, which frames why status/connectivity matters. It stops short of describing pagination or the shape of returned rows, so not a 5.

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

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

Three tight sentences: purpose first, then domain context, then use cases. No filler and the primary action is front-loaded.

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

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

For a read-only list tool with annotations, a fully documented schema, and no output schema, the description covers purpose, context, and use cases. Minor gap: beyond 'and their status' it doesn't characterize what the returned rows contain, but that is a small omission for a simple listing 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 description coverage is 100%, and the limit/fields/filter params are fully documented in the schema itself. The description adds no parameter-level detail, so the baseline 3 applies.

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

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

States a specific verb ('List'), resource ('all sites configured in the RAS farm'), and scope ('and their status'). It's distinguishable from per-site siblings like ras_site_get_ad_integration, which read one site's settings, versus this farm-wide topology 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?

Gives explicit when-to-use cases: 'check site connectivity, verify configuration, or audit farm topology.' However it names no alternatives or exclusions, so the agent must infer that per-site tools handle site-specific settings.

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, destructiveHint=false and openWorldHint, so safety is covered structurally. The description adds only the content inventory (branding, logos, settings) and says nothing about pagination, response size, or auth requirements.

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

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

Two short sentences, verb-first and front-loaded, with no obvious padding. The second sentence is mildly redundant with the first but still adds a usable framing.

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

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

For a read-only list tool with a fully documented schema, complete annotation coverage, and no output schema, the description tells the agent what the resource contains and when to reach for it. Return shape and pagination remain unspecified, but the schema's limit/filter/fields params largely cover that.

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

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

Schema description coverage is 100% and all three parameters (limit, fields, filter) are well documented in the schema itself. The description adds no parameter guidance, so the baseline 3 applies.

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

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

States a specific verb and resource ('List user portal themes configured in the RAS farm') and enumerates the content returned (branding, logos, customisation settings). It is clearly distinct from siblings like ras_infra_get_agents or ras_infra_get_sites, though it never names a sibling to contrast against.

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?

'Use this to review portal appearance configuration or verify theme assignments' gives a use case, but it largely restates the purpose rather than distinguishing it from alternatives or giving conditions/exclusions. With no closely related sibling, the implied-usage bar is met but nothing more.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered without the description. The description adds scope of returned content but no behavioral context such as pagination, result-size behavior, or auth requirements. Adequate against a low bar but nothing distinctive.

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

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

Two sentences: the first states the resource and its contents, the second front-loads the when-to-use cases. No filler, no repetition of the title or annotation metadata.

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

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

For a read-only list tool with fully documented parameters and no output schema, the description covers purpose, content, and use cases sufficiently. The only gap is distinguishing this from the parallel RDS host-pool tool, which would help in a sibling set this large.

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

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

Schema description coverage is 100% and the schema itself explains limit semantics (default 50, max 200, prefer filter), fields projection, and case-insensitive equality filtering. The description adds nothing about parameters, so baseline 3 is correct.

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

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

The description opens with a specific verb+resource ("List VDI host pool configuration") and enumerates the content returned (pool members, provisioning settings, capacity). That resource is clearly distinct from the neighboring VDI tools (ras_infra_get_vdi_templates, ras_pub_get_vdi_desktops, ras_pub_get_vdi_apps), so an agent can route without 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?

It gives three concrete use cases — reviewing pool composition, checking desktop provisioning status, verifying pool sizing — which is stronger than implied usage. It does not name an alternative tool or state when not to use it (e.g., for RDS host pools, use ras_infra_get_rds_hostpools), so it stops short of full routing guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered without the description. The description adds only domain framing (templates as base image definitions); it says nothing about result size, pagination behavior, or whether missing objects appear in the list.

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 tight sentences, front-loaded with the action and resource, followed by a definition of templates and then usage contexts. No filler, though the second sentence is explanatory background rather than call-critical instruction.

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

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

For a read-only, zero-required-parameter list tool with a fully described schema and no output schema, the description supplies purpose and use cases adequately. The remaining gap is guidance on narrowing results across a potentially large template list, which the schema hint alone covers.

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?

All three parameters are documented in the schema at 100% coverage, including limit bounds, the fields projection, and the filter equality semantics, so the schema carries the load. The description contributes no parameter guidance at all, which makes the baseline 3 appropriate given the nested filter object.

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

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

States a specific verb (List) and resource (VDI templates) plus the payload contents (status, configuration), and explains what a template is ('base image and settings for provisioned VDI desktops'), which separates it from the nearby ras_infra_get_vdi_hostpools sibling. It stops short of explicitly contrasting itself with any named sibling, so it lands just under the top tier.

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?

'Use this to check template versions, maintenance mode, or provisioning settings' gives concrete use contexts but no when-not conditions and never names an alternative tool. The agent can infer this is the read path for templates, but routing between it and the hostpool/desktop siblings is left to guesswork.

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

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

Annotations already declare readOnly, idempotent and non-destructive semantics, so the safety profile is covered. The description adds genuinely new behavioral context: policies are deeply nested, so `fields` should be used to project top-level metadata and avoid heavyweight responses. It does not discuss pagination or response size limits beyond that 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?

Three sentences, all load-bearing: purpose first, use case second, the nesting/projection caveat last. No repetition of the schema, no filler, and the most actionable fact (deep nesting) is positioned where an agent will see it before building a query.

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

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

With no output schema and nested objects, the description usefully names what each row contains and warns about nesting depth. Combined with a fully documented input schema, an agent has enough to call it correctly, though it never states return volume or whether assigned/unassigned policies are both included.

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

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

Schema description coverage is 100% and the schema already documents limit, fields and filter in detail, including the filter semantics and max row count. The description only reiterates the `fields` projection idea (top-level metadata) and adds no syntax or format beyond what the schema states, so the baseline 3 applies.

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

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

The description gives a specific verb and resource ('List all Parallels RAS client policies') plus the payload it returns (names, settings, assignment status). It is clear, but it does not distinguish this tool from potentially overlapping siblings such as ras_site_get_printing or ras_site_get_connection_settings, which also govern user-experience settings like display, audio and printing.

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

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

It states concrete contexts for use ('audit policy configuration or troubleshoot client behaviour'), which is more than implied usage. It stops short of naming when not to use the tool or pointing at an alternative sibling, so it is clear but not exhaustive.

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, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds genuinely new behavioral context beyond the annotations: large farms can return thousands of items and responses can be kept small via filter/fields, which is a scale/performance disclosure the annotations do not carry.

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

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

Three sentences, front-loaded with what the tool returns, then the usage condition, then the scale mitigation. No redundancy and every sentence carries information an agent needs.

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

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

With no output schema, the description still conveys the return shape (items across all published resource types in a single view), the volume risk, and the two levers for controlling it. Combined with the fully documented schema, nothing an agent needs to call this correctly is missing.

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

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

Schema description coverage is 100%, with limit, fields and filter each documented in the schema itself (including the default of 50, max 200, and the preference for narrowing over raising limit). The description's filter example {type: 'App'} hints at usable top-level keys, but this is marginal added value over the schema, so baseline 3 applies.

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

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

States a specific verb and resource (list all published items) and explicitly scopes it across all resource types (RDS, VDI, AVD apps and desktops), which distinguishes it from the per-type siblings like ras_pub_get_rds_apps and ras_pub_get_vdi_desktops. An agent can identify this as the aggregate cross-type listing without opening any schema.

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

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

"Use this for a complete overview of everything published in the farm" gives a clear selection context, implicitly positioning it against the per-type getters. It also advises narrowing with filter or project with fields for large farms. It stops short of naming the sibling alternatives explicitly or stating 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 declare the full safety profile (readOnly, idempotent, non-destructive, openWorld), so the description only needs to add surrounding context. It contributes the useful note that AVD apps come from Azure-hosted session hosts, but says nothing about response size, pagination, or ordering 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?

Three short sentences, front-loaded with the core action and free of filler. The middle sentence about Azure-hosted session hosts is mild background rather than essential instruction, so it is efficient but not perfectly lean.

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

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

No output schema exists, but the annotation set covers the safety profile and the schema fully documents the three optional parameters, so the description does not need to explain return values. It leaves only the sibling-selection question (AVD vs RDS/VDI) unaddressed, which is a minor 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% and all three parameters carry detailed self-documentation (default/max on limit, filter semantics, fields projection). The description adds no parameter-level meaning, so the baseline 3 applies.

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

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

States a specific verb (List) and resource (published Azure Virtual Desktop applications), and the AVD qualifier implicitly separates it from the RDS and VDI variants in the sibling set. It never names those alternatives explicitly, so an agent must infer the distinction rather than being told it.

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?

"Use this to review AVD app assignments or verify Azure-based application publishing" gives a clear use context, but offers no when-not guidance and never points to ras_pub_get_rds_apps, ras_pub_get_vdi_apps, or ras_pub_get_avd_desktops as the alternatives for other publishing types.

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, destructiveHint=false and openWorldHint, so the safety profile is fully covered and the description is not obligated to restate it. What it adds is narrow conceptual framing (AVD = Azure-hosted session hosts) rather than behavior such as pagination, response size, or filter semantics.

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

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

Three short sentences with the verb and resource front-loaded and no filler. The middle sentence is slightly didactic background, but nothing is redundant or padded.

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

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

No output schema exists, so the description carries the burden of explaining what a caller gets back, and it does not (row shape, default columns). For a zero-required-parameter list tool in a set of 38 near-identically named siblings, the definition is adequate but leaves the AVD-vs-RDS-vs-VDI selection to inference.

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%; limit, fields, and filter are each well documented in the schema, including the 'prefer narrowing with filter' advice. The description adds no parameter-level information, so the 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?

Clear verb (List) plus resource (published AVD desktops), and the second sentence pins down that this is the Azure-hosted variant. It does not name the sibling it displaces, so an agent must infer the RDS/VDI distinction from the word 'Azure' alone rather than being routed explicitly.

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

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

'Use this to review AVD desktop assignments or verify Azure-based desktop publishing' gives a plausible context of use but no when-not-to-use guidance. With ras_pub_get_rds_desktops, ras_pub_get_vdi_desktops, and ras_pub_get_all_items within one keystroke of this name, the absence of explicit routing is a real gap.

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, non-destructive, and openWorld semantics, so the safety profile is fully covered elsewhere. The description adds only domain context about what folders represent; it says nothing about pagination behavior, default result volume, or response shape.

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

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

Two sentences, zero filler, with the resource definition front-loaded before the usage guidance. Every clause earns its place.

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

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

For a zero-required-parameter read tool with a fully documented schema, the description covers purpose and usage adequately. With no output schema, a brief note on what each folder row contains would have closed the remaining 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 limit, filter, and fields are already documented thoroughly (including the advice to narrow with filter rather than raise limit). The description adds no parameter meaning beyond that, which is the expected 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?

States a specific verb (list) and a precise resource (published resource folders) and explains what those folders are for, which separates it from the app/desktop list siblings. It stops short of naming any sibling tool to contrast against.

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

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

Gives three concrete use cases (review hierarchy, check organisation, verify folder-level access), which tells an agent when this tool is appropriate. No when-not-to-use guidance or named alternatives are 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 declare readOnlyHint, idempotentHint and destructiveHint=false, so the agent knows this is a safe, repeatable read. The description adds the returned-field inventory, which is useful, but says nothing about pagination limits or the scale of results beyond what the schema documents.

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

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

Two tight sentences: the first front-loads what is returned, the second covers when to use it. No filler or repetition of the title.

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

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

For a read-only, zero-required-parameter list tool with full schema coverage and annotations, the definition is nearly complete — it names the concrete fields an agent will get back despite the absence of an output schema. Minor gaps around result scale/pagination 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?

Schema description coverage is 100% and all three parameters (limit, fields, filter) are thoroughly documented in the schema itself. The description adds nothing about parameter syntax or semantics, so the baseline of 3 applies.

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

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

States a specific verb ('List') and resource ('published RDS applications') and even enumerates the columns returned (app names, executable paths, server associations, user filter assignments). It implicitly distinguishes itself from the VDI/AVD variants in the sibling family by naming RDS, but never explicitly contrasts with ras_pub_get_vdi_apps or ras_pub_get_avd_apps.

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

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

Gives clear positive context — review published apps, check configurations, troubleshoot launch issues. It does not state when to prefer an alternate tool (e.g., a sibling app/desktop listing) or any exclusions, so it stops short of full routing guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so safety is covered. The description adds the scope qualifier 'published' and explains the resource type, but does not disclose auth, rate limits, pagination, or return behavior beyond what annotations already imply.

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

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

Three sentences, front-loaded with the action and resource, then domain context, then use cases. No sentence is wasteful, though the domain-context sentence is more explanatory than strictly necessary for call selection.

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

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

For a simple read-only list tool with rich annotations and full schema coverage, the description covers what it lists and when to use it. It omits output/pagination details and explicit sibling routing, but those gaps are modest given the tool's 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%, so the schema fully documents limit, fields, and filter. The description adds no parameter syntax or filtering semantics beyond the schema; 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 uses a specific verb and resource ('List published RDS desktop resources') and clarifies what an RDS desktop is. It does not explicitly contrast with sibling tools like ras_pub_get_vdi_desktops or ras_pub_get_avd_desktops, so it stops short of the explicit sibling differentiation a 5 requires.

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

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

It gives clear use cases: reviewing RDS desktop assignments and troubleshooting launch issues. It does not state when not to use it or name alternative sibling tools for VDI/AVD desktops, but the context is sufficient for a 4.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered. The description adds what the response conceptually contains (operational flag, pending changes) but says nothing about auth requirements, staleness of the status data, or refresh behavior.

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

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

Three short sentences, front-loaded with what the tool reports and followed by when to use it. No filler.

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

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

No output schema exists, so the description must cover return values, and it does so at a summary level ('operational' plus 'pending changes'). Sufficient to call correctly for a parameterless status endpoint, though finer detail on the return shape is absent.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies.

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

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

States a specific resource ('publishing service status and health') and what it returns ('whether the publishing agent is operational and any pending changes'). It is distinguishable from siblings like ras_pub_get_rds_apps or ras_pub_get_folders, which enumerate items rather than report service health, though it does not name them explicitly.

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

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

Gives two concrete use cases: verifying publishing is functioning, and diagnosing why resources are unavailable. Clear context, but no explicit exclusions or named alternative tools for those diagnostics.

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

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

The annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is fully covered structurally. The description only adds domain context (dedicated VM hosting), and says nothing about result size, filtering cost, or pagination behavior beyond what the schema states.

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

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

Two tight sentences, zero filler, with the core purpose front-loaded before the differentiating domain detail. Every clause earns its place.

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

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

For a read-only list tool with fully documented parameters and rich annotations, the description supplies adequate context to call it correctly. The one gap is explicit routing to the RDS/AVD siblings, which would be relevant given the densely populated ras_pub_* family.

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 limit, fields, and filter are already well documented in the schema. The description contributes no additional parameter meaning, which is the expected baseline when the schema does the heavy lifting.

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

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

The description states a specific verb and resource ('List published VDI applications') and adds a domain distinction ('run on dedicated virtual machines rather than shared RDS hosts') that separates it from the RDS/AVD siblings. It does not name the sibling tool directly, but the VDI-vs-RDS framing is enough for an agent to disambiguate.

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?

'Use this to review VDI-published applications or compare with RDS app assignments' gives an implied context and alludes to the alternative (RDS apps), but never explicitly names ras_pub_get_rds_apps or states when NOT to use this. Usage is inferable rather than 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, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is fully covered structurally. The description adds only conceptual domain context (VDI = dedicated VM per user) and says nothing operational such as result ordering, pagination, or default row counts. Useful framing, but limited behavioral value 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?

Three short sentences, front-loaded with the core action, and no filler. The middle definitional sentence is arguably optional but does help an agent distinguish VDI from session-based desktops, so it earns its place.

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

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

For a simple read-only list tool with a fully documented input schema, the description covers purpose and scope adequately. With no output schema, return shape is only implied by 'List ... resources', which is a minor gap but unlikely to cause misuse.

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

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

Schema description coverage is 100% and each of the three parameters (limit, fields, filter) is thoroughly documented in the schema, including the advice to prefer filter over raising limit. The description adds no parameter-level information, so the baseline 3 applies.

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

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

States a specific verb and resource ('List published VDI desktop resources') and adds a definition of what a VDI desktop is (dedicated VM per user), which implicitly separates it from the RDS/AVD desktop siblings. It's clear, though it never explicitly names those siblings as alternatives.

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?

"Use this to review assignments or verify per-user desktop allocation" gives an implied usage context, so the agent knows the general scenario. However, there is no when-not guidance and no explicit routing between this and ras_pub_get_rds_desktops / ras_pub_get_avd_desktops, which is the main ambiguity for a family of near-identical listing tools.

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

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

Annotations already declare readOnly, idempotent, non-destructive and open-world behavior, so the safety profile is covered. The description adds non-annotation value: the exact shape of returned rows and a performance hint to narrow rather than fetch everything on large farms. It still omits pagination/auth behavior, keeping it short of a 5.

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

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

Three compact sentences: what it returns, when to use it, how to scope it. Front-loaded and free of filler, though the closing narrowing tip partially duplicates the schema's own parameter 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?

With no output schema, the description correctly compensates by listing the fields returned, and it covers when to use the tool and how to limit cost on large farms. It is essentially complete for a read-only list tool, needing only minor detail on pagination or empty-result 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 description coverage is 100%, so the three parameters are already fully documented with defaults, bounds and semantics. The description only repeats the parameter names and the narrowing advice, adding no syntax or format information beyond the schema; baseline 3 applies.

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

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

States a specific verb and resource ('List active remote desktop sessions across the RAS farm') and enumerates the returned columns (username, client IP, device name, state, resolution, connected server). This clearly distinguishes it from the configuration-oriented siblings such as ras_infra_get_rds_hosts or ras_site_get_load_balancing.

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

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

Gives explicit usage contexts: monitor active users, check session counts, troubleshoot connectivity, identify idle/disconnected sessions. It does not name an alternative tool or state when NOT to use it, but the sibling set makes the boundary fairly obvious.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered without the description. The description adds semantic value by framing this as a configuration/status read used for connectivity and domain-join verification, but it discloses no auth requirements, latency, or freshness characteristics.

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

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

Two tight sentences: the resource and its contents lead, followed by the use cases. Every clause earns its place with no filler or restatement of the tool name.

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

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

For a parameterless, read-only configuration getter with annotations already covering the safety profile and no output schema to explain, the description supplies enough purpose and usage context. Naming what the returned configuration contains (domain, trust, OU) compensates for the absent 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. No parameter-level information is needed or missing.

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

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

The description states a specific resource (Active Directory integration configuration) and enumerates its scope — domain settings, forest trust relationships, OU mappings — which clearly separates it from the other ras_site_get_* siblings covering MFA, printing, load balancing, etc. It stops short of naming an alternative sibling explicitly, but the resource 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?

It gives three concrete when-to-use scenarios: verify AD connectivity, check domain join status, troubleshoot authentication issues. This is real usage context, though it offers no when-not-to-use conditions or a comparative alternative among the adjacent site getters.

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

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

The annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds the content scope (session timeouts, client connection policies, authentication methods) but omits any behavioral details such as permission requirements, rate limits, or whether settings are global or site-scoped.

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

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

Two short sentences: the first front-loads the resource and its contents, the second supplies use cases. Nothing is redundant or buried.

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

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

For a zero-parameter, read-only getter with annotations covering safety, the description supplies enough to call it and interpret the result. It does not clarify whether the settings are site-scoped (implied by the name) or what prerequisites exist, but these gaps are minor.

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

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

The tool takes zero parameters, so there are no parameter semantics for the description to clarify. Baseline for a parameterless tool 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 names the resource (connection and authentication settings) and enumerates the specific sub-areas it covers, so an agent knows what will be retrieved. However, it does not explicitly distinguish this tool from nearby siblings such as ras_site_get_mfa or ras_site_get_ad_integration, leaving overlap ambiguous.

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

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

It gives two concrete scenarios — reviewing security posture and troubleshooting client connection issues — which tells the agent when the tool is appropriate. It does not name alternatives or state when not to use it, so the guidance is clear but not exhaustive.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds that the settings govern allocation across user sessions, but says nothing about whether settings are site-wide vs. farm-level or what is returned.

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

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

Three short sentences, front-loaded with the resource definition. The second sentence ('Controls how CPU resources are allocated across user sessions') mildly restates the first, costing a little efficiency.

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

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

With no parameters and no output schema, the description could clarify what settings are actually returned (e.g., optimization mode or policy fields), but it stops at a general characterization. Adequate for a safe read call, but leaves the return content opaque.

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

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

The tool takes zero parameters, so there is nothing to document; per the baseline for parameter-less tools, a 4 applies.

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

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

States the resource ('CPU optimization settings for the site') and clarifies scope ('how CPU resources are allocated across user sessions'), which distinguishes it from other ras_site_get_* siblings. It never uses an explicit retrieval verb, relying on the name for that, but the resource 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?

Offers two use cases ('review resource management policies' or 'troubleshoot performance issues'), which implies context, but names no alternatives and does not address overlap with ras_farm_get_performance or ras_site_get_load_balancing.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds content scope and a diagnostic use case but does not disclose return format, authentication needs, or rate limits, leaving it at a baseline level with annotations 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?

Two sentences with no wasted words, front-loading what the tool returns before the usage guidance. Every sentence earns its place.

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

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

Given the tool has no parameters, no output schema, and read-only annotations, the description is nearly complete: it lists the returned settings and the diagnostic use case. It could be more complete by clarifying how it relates to the similarly named load-balancing-status sibling, but it adequately covers what an agent needs to call it correctly.

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

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

The tool takes zero parameters, so there is no parameter semantics to explain. Baseline for a zero-parameter tool 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 names the specific resource (load balancing settings) and enumerates its contents (balancing method, resource weights, session limits), so an agent can distinguish it from most siblings. It lacks an explicit verb and does not differentiate from ras_infra_get_halb_status, which may overlap in scope.

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?

Explicitly states when to use it: to review session distribution across RDS hosts or diagnose uneven load distribution. It provides clear context but does not name alternative tools or exclusions, so it falls short of a full when/when-not specification.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so safety is covered structurally. The description adds real value beyond them by disclosing the breadth of returned content (providers, criteria, bypass rules), though it says nothing about permissions required or pagination/format.

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

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

Two sentences: the first front-loads the resource and its contents, the second the use cases. Nothing is repeated from the title or schema; every clause adds information.

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

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

With no output schema, the description carries the burden of conveying return content and it does so by enumerating the MFA elements returned. It leaves implicit whether the scope is the current site or all sites, which is a minor but real gap for a zero-parameter GET.

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

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

The tool takes no parameters and the schema is empty, so there is nothing to disambiguate — baseline 4 applies. The description does not introduce any parameter-level meaning, but none is needed.

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 names a specific resource (multi-factor authentication provider configuration) and enumerates exactly which sub-resources it covers: enabled providers with named types (TOTP, RADIUS, Deepnet, SafeNet, Email OTP), criteria rules, and bypass conditions. This is unambiguous against siblings such as ras_site_get_ad_integration or ras_site_get_load_balancing.

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

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

It states two concrete scenarios: auditing MFA security posture and troubleshooting MFA login failures. That is clear context for selecting the tool, but it names no alternatives or exclusions (e.g., where to go for policy-level vs site-level MFA data).

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, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds domain context about notification configuration but does not disclose additional behavioral traits such as permissions required, rate limits, or data sensitivity.

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

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

Two tightly written sentences front-load the resource identity and then state the usage scenario. There is no redundant or filler 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?

For a read-only configuration review tool with fully documented input parameters and comprehensive annotations, the description provides enough context to understand what is returned and why one would call it. No output schema exists, but the description's stated purpose adequately covers the agent's needs.

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 limit, fields, and filter thoroughly. The description adds no parameter-level meaning, which is acceptable given the complete schema coverage and earns the baseline score.

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 names the specific resource ('Notification event configuration') and clarifies that it involves alert triggers, email notifications, and event thresholds. It also states the intended action ('review which events trigger admin notifications or verify alerting is configured'), making the tool's purpose distinct from sibling configuration 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 second sentence gives clear usage context: reviewing which events trigger admin notifications or verifying alerting configuration. It does not state when not to use the tool or name explicit alternatives, but the context is sufficient for selection.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the content taxonomy of what the configuration contains, but says nothing about return shape, environment prerequisites, or whether settings are site-scoped versus farm-scoped beyond the tool name prefix.

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

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

Two sentences with zero padding. The content scope is front-loaded before the usage sentence, and each clause ('printer redirection, universal printing options, driver policies') adds distinct information.

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

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

For a zero-argument, idempotent read with no output schema, the description gives enough to select and call it correctly. It could be stronger by sketching the returned configuration structure, since no output schema exists to carry that burden, but the gap is minor for a simple settings read.

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

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

The tool takes zero parameters, so there is no argument semantics to explain; the baseline for a parameterless tool applies. Nothing in the description misrepresents or over-promises an input.

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

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

Names the specific resource ('Printing configuration') and enumerates the subdomains it covers: printer redirection, universal printing options, driver policies. The 'get' verb is only implied by the tool name, but the scope is unambiguous against the sibling ras_site_get_* tools, each of which targets a distinct site setting.

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 use cases — 'troubleshoot print redirection issues' and 'review printing policy configuration'. No exclusion or alternative sibling is named, but the tool is a single-purpose read of one settings domain, so there is little ambiguity to resolve.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful domain context (the tenant broker enables multi-tenant deployments, the tool reports join status), but reveals nothing about response format, pagination, or failure modes. With annotations carrying the safety burden, this is adequate but not rich.

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

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

Two tight sentences, front-loaded with the resource and purpose, with the usage instruction following immediately. No filler or repetition.

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

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

For a zero-parameter read-only status tool with no output schema and full annotation coverage, the description supplies the essential context: what the broker is and what status/join data is retrieved. It could go slightly further on what the returned status conveys, but nothing critical for invocation is missing.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. No parameter-level confusion is possible.

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

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

States a specific resource (tenant broker) and the operations it supports (status and join information), which is clearly distinct from the other ras_site_get_* siblings that cover AD integration, load balancing, MFA, etc. It stops short of explicitly naming a sibling alternative, but the resource 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?

Explicitly says 'Use this to verify tenant broker connectivity or check join status for managed sites,' giving a clear operational context for invocation. It does not state when NOT to use it or name an alternative tool, but the usage context is well defined.

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, non-destructive and openWorld, so safety is covered. The description adds useful domain context about how redirection works, but says nothing about pagination, default/max row behavior, or response shape for what is a list-style read.

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

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

Three short sentences, front-loaded with the resource identity followed by a one-line domain explanation and a usage hint. Each sentence earns its place, though the second is borderline explanatory fluff for an agent that mainly needs to select and call the tool.

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

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

With no output schema, the description should stand in for return-shape expectations, but annotations plus a fully documented input schema carry most of the load. For a simple parameterized list/get of site-level rules, the definition is largely sufficient, with only pagination and response format unaddressed.

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

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

Schema description coverage is 100% and the schema already documents limit, fields, and filter thoroughly (including defaults, max, and filtering semantics). The description adds no parameter meaning, so the baseline of 3 applies.

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

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

The description names a specific resource (URL redirection rules configured for the site) and clarifies the domain concept, so an agent knows this retrieves redirection rules rather than any other site setting. It doesn't explicitly differentiate itself from the other ras_site_get_* siblings, but the resource name is distinct enough to route correctly.

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?

"Use this to review redirection rules or troubleshoot URL handling" gives an implied but generic context for when to call. There is no when-not guidance and no mention of alternative tools for related site settings, so usage is inferred rather than stated.

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