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

With no annotations, the description must fully disclose behavior, but it only states the action and parameter meanings. It does not mention effects on the queue, idempotency, permissions, or response format, leaving a significant transparency gap.

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

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

The description is a concise list of arguments with one-line explanations and no filler. The first sentence front-loads the core action, and every line adds necessary parameter 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?

The description lacks any mention of output or return value, which is important because no output schema exists. It also omits error handling, preconditions, and differentiation from sibling tools, making it incomplete for a 5-parameter tool with nested content.

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?

Even though the schema has 0% description coverage, the description provides meaningful parameter semantics: priority values ('Low', 'Normal', 'High') with default, specific_content described as key-value pairs, and reference marked optional. This adds real value beyond the schema's raw type definitions.

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

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

The description clearly states the action ('Add a new item to a queue') with a specific verb and resource. It is self-explanatory, though it does not explicitly distinguish itself from sibling tool bulk_add_queue_items.

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

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

No guidance is provided about when to use this tool versus alternatives such as bulk_add_queue_items or get_queue_items. There is no mention of prerequisites, contexts, or 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?

With no annotations provided, the description carries the full behavioral burden. It discloses important mutation traits via commit_type: 'AllOrNothing' rolls back on failure, while 'ProcessAllIndependently' commits each item. This provides transparency around failure handling beyond 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?

The description is well-organized with an Args section that lists each parameter and its semantics. Every sentence contributes information—there is no fluff. The main purpose is front-loaded, and the format is easy to scan.

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

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

Given the tool has 4 parameters, nested item structures, and no output schema, the description covers all inputs and key failure modes (commit_type). It could be more complete by mentioning return values or error conditions, but it is sufficient for correct invocation in most cases.

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

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

Schema description coverage is 0%, meaning the schema offers no property descriptions. The description compensates fully by explaining folder_name, queue_name, items (including nested object structure with specific_content, priority values, reference), and commit_type options. This exceeds the schema's bare types and titles.

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 'Add multiple items to a queue in a single API call' which clearly states the verb, resource, and scope. This distinguishes it from the sibling tool 'add_queue_item' that handles single items.

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

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

The phrase 'in a single API call' implies bulk usage, and the sibling context makes the alternative obvious. However, there is no explicit when-to-use vs. when-not-to-use guidance, just a clear context that it is for multiple items.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states the operation (count only, no item fetching), and explains scoping behavior via parameters (e.g., queue_name scoping and optional filter). This is sufficient for a read-only count 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?

The description is compact: a one-sentence summary, a two-sentence usage note, and a bulleted parameter list. No fluff 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?

For a count tool with an existing output schema, the description covers purpose, usage context, and parameter semantics. It tells the agent when to use it, what it does, and how parameters affect results. The existence of an output schema reduces the need to describe return values.

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

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

The input schema has 0% description coverage, but the description's 'Args' section compensates with clear explanations: folder_name as display name, queue_name scope behavior, and filter_query OData syntax with example. This adds meaning beyond the schema titles.

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 ('Return the total number') and identifies the resource ('queue items') and scope ('matching the given criteria'). It also distinguishes it from sibling get_queue_items by explicitly stating 'without fetching the items,' making clear this is a counting operation rather than a retrieval one.

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

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

The description explicitly instructs to call this before get_queue_items to check volume and decide on batching/pagination, providing a clear when-to-use context. It also mentions health checks as another use case, and differentiates from the sibling by noting it does not fetch items.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It only restates the action (delete) and parameter meanings, but does not mention that deletion is permanent, irreversible, or could fail if the item is currently being processed. No side effects, permission requirements, or error behavior are disclosed.

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

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

The description is compact and front-loaded with the primary purpose in the first sentence. The argument descriptions are direct and add value without unnecessary verbosity. Every sentence earns its place; no filler or redundant 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 simple delete operation with two parameters, the description covers the essential purpose and parameter meanings. However, it lacks any behavioral context (permanence, constraints, or failure modes) and does not mention return values. Given its simplicity, the description is mostly complete but has clear room for improvement in behavioral transparency.

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

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

Schema description coverage is 0%, so the description fully compensates by explaining each parameter: queue_item_id as 'the ID of the queue item to delete' and folder_name as 'the display name of the folder containing the item.' This adds meaningful semantics beyond the bare property names, making the tool easier to invoke correctly.

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

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

The description clearly states the verb and resource: 'Delete a queue item by its ID.' It also specifies the key parameter (queue_item_id) and includes the folder context. This distinguishes it from sibling tools like add_queue_item, retry_queue_item, and get_queue_items.

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 usage context is implied by the delete action, but the description does not explicitly state when to use this tool versus alternatives (e.g., retry_queue_item for re-processing). It provides no exclusion criteria or prerequisites, leaving the agent to infer when deletion is appropriate.

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?

With no annotations, the description carries the full burden. It discloses that the tool combines metadata and error logs, deduplicates and time-sorts, and includes a configurable tail. It does not explicitly state that it is read-only or discuss permissions, but for a diagnostic tool this is minor and the core behavior is well covered.

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

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

The description is well-organized and front-loaded with the core purpose. The 'Returns:' and 'Args:' sections are concise and every sentence adds value. There is 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?

Despite having no output schema, the description enumerates the three return fields and their contents. It also covers parameters, usage, and differentiation from sibling tools. The agent has all necessary context to decide when to use the tool and what to expect.

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

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

Schema description coverage is 0%, so the description fully compensates. Each parameter is explained with meaningful context: job_id is 'the ID', folder_name clarifies it is the 'display name' (not an ID), and tail specifies 'most-recent log entries' with a default. This goes beyond the schema's basic types.

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 ('Return a focused diagnostic report') and clearly identifies the resource ('a job'). It further distinguishes the tool from siblings by explicitly stating it is the 'first tool to call' for failure diagnosis and contrasting it with get_job + get_job_logs.

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

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

The description gives explicit when-to-use guidance ('when asked "what went wrong?" or "why did this job fail?"'), states the alternative (get_job + get_job_logs), and provides a clear exclusion condition ('Only use get_job_logs afterward if you need more log history than tail provides or need to paginate').

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?

With no annotations provided, the description must disclose behavioral traits. It merely restates the action without mentioning reversibility, required permissions, side effects on running processes, or return behavior.

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

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

The description is extremely concise: one sentence plus two clearly formatted parameter explanations. Every word earns its place, with 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?

For a simple two-parameter tool with no output schema, the description covers the core function and inputs. However, it omits behavioral context (e.g., whether disabling is reversible, what happens if already disabled) and doesn't reference any alternative workflows or prerequisites.

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 'Args' section provides meaningful definitions for both parameters beyond the schema's bare titles: schedule_id is identified as the ID to disable, and folder_name as the display name of the containing folder. Since schema description coverage is 0%, this added context is valuable and helps the agent map inputs correctly.

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 ('Disable') and resource ('process schedule'), clearly stating the tool's function. It is implicitly distinct from the sibling 'enable_schedule' through the opposite verb, though it doesn't explicitly differentiate 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?

No guidance is provided on when to use this tool versus alternatives like 'enable_schedule' or 'list_schedules'. The description only states the action, not the context, preconditions, or 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?

With no annotations, the description carries the full burden of disclosing behavioral traits. It fails to mention what 'enable' does to the schedule, whether it is idempotent, what happens if the schedule is already enabled, or whether any permissions or side effects are involved. This is a significant gap for a mutating 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?

The description is extremely concise and well-structured. It leads with a clear one-sentence purpose, followed by a structured argument list. No unnecessary words or filler; every part 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 two-parameter tool with no output schema, this description covers the basic mechanics but lacks broader context. It does not explain the effect of enabling a schedule, error conditions, or how it relates to sibling tools. It is minimally viable but not fully complete.

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

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

The input schema has 0% description coverage, so the description must compensate. It provides brief explanations for each parameter (schedule_id is 'the ID of the schedule to enable' and folder_name is 'the display name of the folder containing the schedule'). This is useful but minimal, adding only surface-level meaning without deeper semantic context like format constraints or relationships.

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

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

The description states the core action clearly: 'Enable a process schedule.' This is a specific verb+resource combination and naturally distinguishes from sibling tools like disable_schedule. However, it is almost a verbatim restatement of the tool name and adds little beyond that.

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

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

No guidance is provided on when to use this tool versus alternatives. There is no mention of preconditions (e.g., schedule must be disabled), scenarios where enabling is appropriate, or related tools like list_schedules or disable_schedule. The description simply states what it does without usage context.

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

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

With no annotations provided, the description carries the burden of disclosing behavior. It states only the basic action and does not mention whether the operation is read-only, side effects, permissions needed, or behavior when the asset is not found. Lack of such disclosure leaves the agent without critical 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?

The description is concise, with a one-sentence purpose followed by an organized Args list. Every sentence earns its place and there is no irrelevant 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?

The presence of an output schema covers return values, and the description clearly explains inputs and purpose. However, it does not address error conditions or operational context (such as whether the asset is searchable by exact name), but for a simple get operation with two parameters, the description is sufficiently complete.

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

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

The schema has no descriptions for the parameters, but the description's Args section adds meaning by stating folder_name is the display name and asset_name is the name of the asset to retrieve. This compensates for the 0% schema coverage, though it does not include additional constraints or examples.

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

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

The description clearly states the tool's function: retrieving a specific asset by name from a folder. It uses the verb 'Get' and names the resource, and it distinguishes from sibling tool list_assets by focusing on a single asset rather than 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?

The description implies it should be used when fetching a specific asset by name, but it does not explicitly contrast with alternatives such as list_assets or mention when not to use it. The guidance is implied rather than stated.

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

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

With no annotations, the description states the tool returns a raw API response containing all job fields, which is useful. However, it does not explicitly confirm the operation is read-only or mention any permission/rate-limit requirements, leaving some behavioral gaps for a get operation.

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 tight: two sentences plus a brief arg list, with no redundant wording. The primary purpose is stated first, and the alternative is noted succinctly.

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

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

The tool is simple (2 required params, no output schema), and the description covers purpose, alternative, and parameters. It stops short of detailing potential error responses or the exact structure of the 'raw API response', but it is adequate for selecting and invoking the tool.

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

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

Schema has no descriptions (0% coverage), but the description provides clear one-line explanations for both job_id and folder_name, resolving the ambiguity of the parameter titles. This sufficiently compensates for the missing schema descriptions.

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

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

The description uses specific verb 'Get' plus resource 'full details for a specific job by ID' and explicitly distinguishes from diagnose_job, making its purpose unambiguous. The 'raw API response' qualifier further clarifies the exact nature of the output.

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 explicitly states when to use diagnose_job instead: when needing to understand why a job failed. This provides a clear alternative and implies get_job is for raw full job details, effectively differentiating among siblings.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It goes beyond a basic statement by explaining pagination, log level precedence ('Ignored if log_levels is provided', 'Takes priority over min_level'), and the order of log levels. However, it does not mention edge-case behaviors such as error handling, timezone assumptions for timestamps, or log ordering, so it is not fully exhaustive.

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

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

The description is well-structured: a one-sentence purpose, two sentences for tool selection, a brief note on log level ordering, and a clean Args list. No sentence is redundant; the structure makes scanning easy.

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 an 8-parameter tool with no annotations and zero schema coverage, the description covers all parameters, usage guidance, and behavioral nuances. The presence of an output schema means return values need not be explained. Minor gaps include no mention of timestamp timezone handling, log ordering, or behavior when the job is not found, keeping it from being 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 0%, so the description must compensate, and it does so thoroughly. Every parameter gets a plain-language explanation: job_id, folder_name, batch_size, skip, min_level, log_levels, start_time, and end_time. It even clarifies the relationship between min_level and log_levels, which is not evident from the schema alone.

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

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

The description opens with a clear and specific verb-resource pairing: 'Retrieve paginated robot execution logs for a specific job.' It also explicitly distinguishes itself from the sibling tool diagnose_job by contrasting use cases, making it unmistakably distinct.

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

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

The description provides explicit when-to-use guidance: 'Use diagnose_job instead when the goal is to understand a failure' and 'Use get_job_logs when you need full log pagination, specific time ranges, or log levels that diagnose_job doesn't surface.' This directly names an alternative and gives clear usage boundaries.

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?

No annotations are provided, so the description carries the burden. It discloses that results are a trimmed set of fields, merged across folders, optionally sorted by StartTime, and that hours_back takes priority over days_back. It also explains the effect of most_recent_first with batch_size. It doesn't explicitly state read-only safety, but 'Query jobs' implies non-mutating behavior.

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

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

The description is front-loaded with purpose and usage, then follows with a structured Args list. There is no filler or redundant repetition of schema defaults (e.g., batch_size default is not restated in prose). Every sentence adds value.

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

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

With an output schema present, return details are not needed in the description. The description covers usage context, all parameters, merge behavior, and sorting. It is complete for a query tool, including enough detail for an agent to know exactly when and how to invoke it.

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

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

Schema description coverage is 0%, so the description is the only documentation. It explains all 8 parameters meaningfully: state and source enumerate valid values, folder_names defaults to all non-workspace folders, and hours_back/days_back precedence is specified. most_recent_first semantics are clearly described. This fully compensates for the schema gap.

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 'Query jobs across multiple folders in a single call' — a specific verb, resource, and scope (multi-folder). It also distinguishes itself from the sibling tool list_jobs, making its unique purpose clear.

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 explicitly states this is the preferred tool for tenant-wide or multi-folder queries and gives a concrete when-not condition: 'Use list_jobs instead only when you already know the single folder and need advanced OData filtering or job_priority filtering.' This provides clear decision 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?

With no annotations, the description carries the full burden. It discloses key behaviors: excludes personal workspace folders automatically, returns a list of objects with a defined structure, and implies a read-only operation through 'Return.' While it doesn't explicitly state 'no side effects' or mention pagination/errors, it is sufficiently transparent for a zero-parameter discovery 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?

Four sentences, each earning its place: purpose, usage guidance, return format, and an important exclusion. Front-loaded with the core function, no redundant or vague wording.

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 tool with no output schema, the description is highly complete. It explains what is returned, when to call it, how the returned names relate to other tools, and that personal workspace folders are excluded. This covers all essential context an agent needs to use the tool correctly.

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

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

The tool has zero parameters, so the baseline is 4. The description doesn't need to explain parameter semantics, and the schema trivially covers all (non-existent) parameters. No additional information is required.

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

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

The description explicitly states it 'Return all non-workspace folders with their deployed processes and queue names,' which is a specific verb+resource+scope. It also self-identifies as 'the primary discovery tool,' distinguishing it from siblings like list_folders and list_queue_definitions that likely return narrower datasets.

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 when-to-use guidance: 'Call it once at the start of any session or whenever the folder name, process name, or queue name is unknown.' It also explains that the names returned are the exact values expected by parameters in all other tools, clarifying its role relative to alternatives.

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?

With no annotations, the description must carry the full weight. It implies read-only via 'Retrieve' and discloses statuses, OData filtering, pagination, and ordering options. However, it does not explicitly state that no mutations occur, nor does it mention permissions, rate limits, or error behavior, leaving some gaps.

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

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

The description is well-structured: a clear one-sentence purpose, status list, usage tips, filter examples, then parameter definitions. It is a bit long but every sentence adds value, and the key purpose is front-loaded.

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

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

Given the complexity (6 parameters, filtering, pagination, sorting) and the presence of an output schema, the description covers purpose, usage, parameters, and examples. It omits error handling and permission details, but the output schema handles return values, making it reasonably complete.

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

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

The schema has 0% description coverage, but the description's 'Args' section explains every parameter in plain language, including defaults and filter_query semantics with concrete OData examples. This fully compensates for the schema gap.

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 'Retrieve a batch of queue items from a specific queue,' which is a specific verb+resource+scope statement. It distinguishes from sibling tools like count_queue_items (counting) and add/delete/retry (mutations).

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 explicitly tells the agent to use count_queue_items before calling this on a large queue, providing both an alternative and a when-not-to-use scenario. It also recommends most_recent_first=True with a small batch_size for efficiency, giving actionable usage advice.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states 'list' (implying read-only) but does not mention recursion depth, ordering, pagination, error behavior if the folder is missing, or whether asset details are complete. This leaves significant ambiguity for an agent.

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

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

The description is two short, direct sentences with the parameter inline in an 'Args' block. Every word earns its place, and no redundant information is included.

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

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

The output schema presumably explains return values, so the description does not need to cover them. Yet for a tool with no annotations and several siblings, the description lacks context about when to use this tool versus listing folders or getting a single asset. It is minimally viable but leaves the agent to infer usage from the name and single sentence.

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

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

With 0% schema coverage, the description must compensate. It clarifies that 'folder_name' is the 'display name' rather than an ID, which adds meaningful semantic value beyond the bare schema. However, it does not explain how to obtain the display name or confirm the folder exists, leaving room for more detail.

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

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

The description clearly states 'List all assets in a folder' with a specific verb, resource (assets), and scope (a folder). This distinguishes it from siblings like 'get_asset' (single asset) and 'list_folders' (folders instead of assets).

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

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

The description implies usage for when you need all assets within a specified folder, but it does not provide explicit guidance on when to choose this tool over alternatives such as 'get_asset' or 'list_folders'. There are no stated exclusions or prerequisites.

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

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

With no annotations, the description carries the full burden. It discloses that the tool returns a raw API response, that it does not filter personal workspaces (implied by the sibling's filtering), and that it returns only folder metadata. It could add more about pagination or permissions, but the key behavioral traits are present.

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

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

Two sentences: the first states purpose, the second gives usage guidance. Every word earns its place, with no repetition 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 tool with no parameters and an output schema available, the description covers purpose, usage, and behavioral scope. It also distinguishes from a sibling tool. The presence of an output schema means return values are already documented, so nothing 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 has zero parameters, so the baseline is 4. The description correctly does not invent parameter details; it focuses on behavior and usage, which is appropriate for a no-argument tool.

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 action ('List all folders') on a specific resource ('UiPath Orchestrator') and adds 'raw API response' to clarify scope. It also names a sibling tool (get_orchestrator_summary) and explains what that tool does differently, making the purpose unmistakable.

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

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

The description explicitly tells the user to prefer get_orchestrator_summary over this tool for most cases, then states exactly when to use list_folders ('only when you need the raw folder metadata'). This is a clear when/when-not with a direct alternative.

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

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

With no annotations, the description carries the full burden. It transparently discloses that it returns a trimmed set of fields, enumerates those fields, and explains pagination and filtering options. It does not mention error behavior for non-existent folders or auth requirements, but for a read-only list tool, the disclosure is strong.

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

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

The description is well-structured: purpose, usage guidance, return fields, and parameter documentation. Every sentence adds value, and the Args block is efficiently organized. No fluff 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 10 parameters and no schema descriptions, this description covers all necessary guidance: scope, when to use, output fields, and parameter semantics. The output schema exists, so return value details are not the description's job. This is a complete, self-contained description for selecting and invoking the tool.

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

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

The input schema has 0% description coverage, so the description's Args section is essential. It explains all 10 parameters, including defaults (batch_size=50, skip=0), accepted enum values for state and job_priority, ISO 8601 format for time filters, and the meaning of most_recent_first. This fully compensates for the schema's lack of descriptions.

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

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

The description opens with 'List and filter jobs within a single folder,' using a specific verb and resource while clearly delimiting scope. It also distinguishes itself from the sibling get_jobs_across_folders by explicitly stating the single-folder limitation.

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

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

The description provides explicit when-to-use guidance: 'Use this when the user asks about jobs in a specific, known folder' and directly names the alternative: 'Use get_jobs_across_folders instead when querying multiple folders or the entire tenant.' This is textbook usage differentiation.

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?

With no annotations, the description carries the full burden. It correctly identifies this as a read-only listing operation and specifies the default behavior when folder_name is omitted. However, it does not disclose potential edge behaviors like whether folder scoping includes subfolders, exact match requirements, or pagination, leaving some gaps.

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

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

The description is extremely concise, front-loading the key action and optional parameter. Every sentence adds value, and the format is clean and readable, with no wasted words.

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

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

The tool is simple with one optional parameter, and the description covers the action, scoping semantics, and default behavior. Since an output schema exists, return values are not the description's responsibility. A minor gap is the absence of details about folder-matching behavior, but overall the context is sufficient.

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

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

The schema provides only the property name, type, and default with 0% coverage. The description compensates by explaining that folder_name is the display name, is optional, and defines the behavior when omitted, adding significant meaning beyond the raw schema.

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

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

The description uses a specific verb ('list') and resource ('machines'), and clearly states the optional folder scoping. This distinguishes it from sibling list tools (e.g., list_folders, list_jobs) by naming a unique resource, making the purpose immediately clear.

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

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

The description explicitly states that folder_name is optional and that omitting it returns all machines, giving clear context for parameter usage. It does not name alternatives, but no sibling tool overlaps with listing machines, so the lack of exclusions is acceptable.

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?

With no annotations, the description must carry the full burden of behavioral disclosure. It does reveal that the tool returns metadata rather than items, which is a useful scoping constraint. However, it does not explicitly state whether the operation is read-only, mention permissions, or note any side effects. Since 'list' implies a read operation, the absence of explicit safety language prevents a higher score.

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

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

The description is concise and well-structured. It front-loads the core purpose, then lists return details, alternatives, and finally documents the argument. Every sentence adds value without redundancy, making it easy for an agent to quickly parse the essential information.

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

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

Given the tool's simplicity (one parameter, output schema provided), the description covers the essential context: what it lists, what it returns, what it doesn't, and alternatives. It omits potential error conditions or prerequisite checks, but these are less critical for a straightforward listing operation. The presence of an output schema also reduces the need to describe return values in text.

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 for the sole parameter is 0%, but the description adds meaningful semantics: 'folder_name: The display name of the folder.' This clarifies that the parameter expects a human-readable folder name rather than an ID, which directly compensates for the schema's lack of detail. More elaboration on how to obtain the display name would have been ideal, but this is adequate for a single parameter.

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

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

The description clearly states 'List all queue definitions (metadata) in a folder' and specifies exactly what is returned: names, IDs, and configuration, while explicitly noting what is not returned (items). This distinguishes it from sibling tools like get_queue_items and count_queue_items, making the purpose and scope unmistakable.

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

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

The description provides explicit guidance on when to use this tool vs alternatives: 'To retrieve actual work items, use get_queue_items. To count items matching a filter before fetching, use count_queue_items.' This directly addresses tool selection and is more detailed than typical alternatives 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?

No annotations are provided, so the description carries the burden of behavioral disclosure. It explains what a release is and that full metadata is returned, which gives some context. However, it does not explicitly state read-only behavior, permissions, or pagination/limits. The 'List' verb implies read-only but more detail would improve transparency.

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

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

The description is concise and front-loaded with the main purpose. It provides necessary context about UiPath releases and the sibling tool in four sentences, plus an Args line. No wasted words and easy to scan.

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

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

For a simple list operation with one parameter and an output schema, the description covers purpose, key terminology, and usage differentiation. The output schema likely documents return values, so that detail is not needed here. Minor gaps like error handling are not expected for a tool of this simplicity.

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

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

The schema has no descriptions (0% coverage), but the description includes an Args section explaining folder_name as 'the display name of the folder.' This adds meaning beyond the schema's property definition. For a single parameter, this is adequate compensation.

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 action ('List') on a specific resource ('releases') with scope ('in a folder'). It also distinguishes from sibling get_orchestrator_summary by noting that the summary only returns process names, making the purpose 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 references sibling get_orchestrator_summary and states when to use list_releases instead: when needing release keys (GUIDs), package versions, entry points, or deployment metadata. This provides clear when-to vs. when-not-to 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?

No annotations are provided, so the description carries the full burden. 'List' implies a read-only operation and 'returns all robots' clarifies the scope, but it does not disclose error behavior, pagination, ordering, or what happens if the specified folder does not exist.

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

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

The description is concise, front-loaded with the main purpose, and the Args block is directly relevant. Every sentence adds value without redundancy.

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

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

For a simple one-parameter list tool with an output schema, the description fully covers what the tool does, the parameter semantics, and the default behavior. The output schema handles return-value details, so no further elaboration is needed.

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

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

The schema only provides type and default for folder_name, while the description adds meaning by calling it the 'display name' and explaining that omitting it returns all robots. This compensates for the 0% schema description coverage.

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

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

The description clearly states 'List robots' and adds an optional folder scope, making the resource and action specific. This differentiates it from sibling tools like list_machines and list_assets by naming the exact resource.

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

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

The description explains how to use the folder_name parameter and the default behavior when omitted, which is useful usage context. However, it does not explicitly state when to use this tool over alternatives or provide any exclusion criteria.

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

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

With no annotations provided, the description carries the full burden and discloses useful return metadata (cron expression, enabled/disabled state, associated release name). It does not discuss auth or error behavior, but for a read-only list operation this is adequate.

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

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

The description is compact and well-structured: one sentence for purpose, one for return values, one for related actions, and a simple Args line. Every sentence adds distinct value with 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?

Given the simple single-parameter schema and presence of an output schema, the description is complete. It explains what the tool does, what metadata is returned, and how to toggle schedules, giving an agent enough to select and invoke it correctly.

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

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

The schema has no parameter descriptions (0% coverage), but the description adds an Args section explaining folder_name as 'the display name of the folder.' This fully compensates for the missing schema description for the single parameter.

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

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

The description clearly states it lists process schedules (time-based triggers) in a folder, using a specific verb and resource. This distinguishes it from sibling tools like enable_schedule/disable_schedule and list_folders.

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

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

The description explicitly mentions using enable_schedule/disable_schedule to toggle schedules, providing clear guidance on a related action. It does not explicitly contrast with other list tools, but the folder-scoped listing context is clear.

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

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

With no annotations provided, the description carries the full burden. It discloses the state reset to New, the error condition for non-eligible states, and the optimistic concurrency control mechanism via row_version. This goes beyond basic mutation descriptions, though it does not mention return values or side effects beyond the state change.

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

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

The description is concise and well-structured: a clear one-sentence purpose, a brief usage constraint paragraph, and a simple Args list. No superfluous content; 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's simplicity (3 required params, no output schema), the description covers all essential aspects: purpose, applicable states, error condition, concurrency, and parameter semantics. It does not explicitly describe the return value, but with no output schema, that is not strictly necessary. Minor gap could be mentioning any required permissions, but overall it is complete enough.

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 0% description coverage, but the description's Args section adds meaning to all three parameters. It explains queue_item_id as the ID, row_version as the value from get_queue_items preventing stale retries, and folder_name as the display name. This compensates well for the schema's lack of descriptions.

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

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

The description clearly states the tool's function: 'Retry a Failed or Abandoned queue item, resetting it to New so robots will pick it up again.' This is a specific verb (retry), resource (queue item), and state change (resetting to New), distinguishing it from sibling tools like add_queue_item or delete_queue_item.

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

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

The description provides clear context on when to use the tool: only for items with status Failed or Abandoned, explicitly stating other states will return an API error. It also implies the need to first fetch items via get_queue_items to obtain row_version. However, it does not explicitly name alternative tools for other scenarios, so it falls just short of a 5.

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

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

With no annotations, the description carries the full burden. It does disclose the auto-lookup behavior, strategy semantics, and conditional parameter requirements, which is valuable. However, it does not mention potential failure modes (e.g., what happens if process_name is not found), permissions required, or whether the call returns a job ID or waits. This is adequate but not comprehensive.

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

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

The description is somewhat long but earns its length by covering 7 parameters and strategy logic in a structured way. It front-loads the core purpose and then organizes details into strategy options and an args list. Not as tight as the exemplar, but appropriate for the complexity.

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

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

Given 7 parameters, zero schema coverage, and an output schema present, the description is largely complete for invoking the tool correctly. It explains parameter semantics, default behavior, and conditional requirements. It does not cover return values, but the output schema handles that. Minor gaps like error handling and prerequisites are not addressed, so it's not a perfect 5.

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

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

Schema description coverage is 0%, so the description must compensate. It does so thoroughly: each parameter is explained, including the relationship between release_key and process_name, the exact meaning of each strategy option, and when robot_ids or jobs_count are required. This goes well beyond the bare schema.

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

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

The description opens with a specific verb and resource: 'Start a new execution of a process (release) in a folder.' This clearly distinguishes it from sibling tools like list_jobs, get_job, or stop_job, which are read or control operations. It also mentions the key inputs (process_name, folder_name) that tie it to get_orchestrator_summary.

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

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

The description provides clear context for when to use the tool, instructing to provide process_name and folder_name, with release_key auto-resolved. It also explains the strategy options and their required parameters. It lacks explicit 'when not to use' or comparisons to alternatives beyond the reference to get_orchestrator_summary, so it doesn't reach 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?

No annotations are present, so the description must disclose behavioral implications. It mentions strategy semantics ('SoftStop' waits, 'Kill' immediate), but does not state reversibility, required permissions, or the effect on the job's final state. For a mutating tool, this is minimal disclosure.

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

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

The description is compact, with a clear action line followed by a concise Args block. Every sentence contributes value, and there is no redundant information.

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

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

The core operation and parameters are covered, but the tool has no annotations and no output schema. It would benefit from stating what happens after stopping (e.g., job state, return value, whether the operation is idempotent), leaving some gaps for a mutating action.

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

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

Schema description coverage is 0%, yet the description fully compensates by listing all three parameters and adding meaning: job_id is an ID, folder_name is a display name, and strategy explicitly defines allowed values. This goes well beyond the raw schema.

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

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

The description uses the specific verb 'Stop' with the resource 'a running job', clearly defining the tool's function. It naturally distinguishes this from sibling tools like start_job and get_job by indicating the action on a job.

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

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

The description provides clear context: it stops a running job and explains the two strategies ('SoftStop' and 'Kill'), which helps the agent decide based on desired behavior. It lacks explicit alternatives or when-not-to-use guidance, so it stops 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.