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

The description goes far beyond the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true, idempotentHint=false) by disclosing that the operation is state-changing and billable, requires confirm_cost, has no cost preview, and may return 402. It explains that only explicitly set parameters are sent, server defaults apply otherwise, class_mapping passes through with no length check, labels are additive, a dataset version is snapshotted, billing settles at run time, and auto_annotate_stop does not refund. This is exceptionally transparent and adds substantial value beyond the structured metadata. No contradiction with annotations.

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

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

Though long, every sentence carries essential information: cost implications, parameter behavior, defaults, class_mapping purpose, additivity, versioning, billing timing, and status/cancel pointers. The structure is logical—core action, cost, parameter semantics, behavioral nuances, and lifecycle management. There is no fluff; each clause earns its place. The density is justified given the tool's complexity.

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

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

The description covers the majority of what an agent needs: reference formats, cost and confirmation, parameter defaults and omissions, class_mapping usage, additive labeling, version snapshotting, billing timing, and related tools. However, it does not specify the return value or output format—there is no output schema, and the description never states what the tool returns (e.g., a run ID) that auto_annotate_status would poll. This is a minor gap given the tool's complexity, but it prevents a perfect score.

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 each parameter's type and basic purpose. The description adds meaningful context: it explains the confirm_cost requirement, that only modelId and optionally confidence, iou, class_mapping, and include_annotated are sent (others omitted for server defaults), and that class_mapping bridges taxonomy mismatches with no length check. This goes beyond the schema's descriptive text, giving the agent operational semantics. It does not restate every parameter but adds value where nuance matters.

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, specific verb-resource pairing: 'Start an auto-annotation run on a dataset... labelling it with a model...'. It explicitly lists the three accepted reference formats for both dataset and model, and differentiates from siblings by naming auto_annotate_status and auto_annotate_stop as the polling/cancelling counterparts. This is unambiguous and distinguishes the tool from its related operations.

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: it mandates confirm_cost=true, explains how to gauge cost magnitude via datasets_get, and warns about insufficient-credit 402 errors. It also states when to use alternatives: 'Use auto_annotate_status to poll and auto_annotate_stop to cancel.' It clarifies that no overwrite confirmation is needed because labels are additive, and explicitly notes the absence of an imgsz parameter, preventing misuse. This is comprehensive and actionable.

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

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

The description goes well beyond the readOnly and non-destructive annotations by fully explaining the semantics of activeJob and lastRun, including null behavior, in-flight progress, failure/stopped flags, results, and error representation. This gives the agent a clear model of what the response means without needing an 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?

The description is two sentences with no filler. The first sentence front-loads the tool's purpose and accepted input forms, and the second sentence delivers essential return-value semantics. Every sentence contributes useful 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?

Despite having no output schema, the description fully explains the observable return behavior: both fields null means no run yet, activeJob shows in-flight progress, and lastRun captures results or errors. Together with the read-only annotations and single fully documented parameter, this is complete enough for correct invocation and interpretation.

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 main description repeats the exact acceptable dataset reference forms already present in the schema: slug, owner/slug, or ul://owner/datasets/slug URI. Therefore, the description adds no new parameter meaning beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb and resource: 'Get an auto-annotation run's status for a dataset.' It clearly identifies the target as a status-checking operation rather than a starting or stopping operation, distinguishing it from the sibling tools auto_annotate_start and auto_annotate_stop. The supported dataset reference forms are also stated.

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

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

The description implies the tool is for checking auto-annotation run status, but it does not explicitly state when to use it versus alternatives, nor does it mention exclusions such as 'use auto_annotate_start to begin a run.' The purpose is clear enough that an agent can infer the usage context, but explicit routing guidance is absent.

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?

Beyond the annotations (destructiveHint, readOnlyHint false), the description discloses substantial behavior: it reads status first and only calls the endpoint if a run is active; it surfaces the server's own action verbatim with possible values 'cancelled', 'dismissed', or 'none'; and it states the tool 'Ships ungated' and that dismissal 'moves no money.' This goes far beyond the structured annotation hints and gives the agent a precise mental model of side effects and response 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?

The description is five sentences long, but each sentence carries distinct behavioral or contextual information: purpose, pre-check behavior, response semantics, gating policy, and financial/non-blocking guarantees. It is front-loaded with the core purpose. A slight deduction because the final sentence about 'never strands anything' and 'moves no money' could be considered slightly redundant with the earlier 'refuses when no run is active,' though it does add reassurance.

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 single-parameter cancellation tool with no output schema, the description covers all essential runtime behavior: when it acts, when it refuses, what actions it may report, gating status, and side-effect consequences (no money moves, no blocking of next start). There is no output schema, and the description effectively substitutes by explaining the server's verbatim action response. Nothing an agent needs to invoke or interpret the result 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 the single 'dataset' parameter is already described as 'Dataset ref by slug, owner/slug, or a ul://owner/datasets/slug URI.' The description repeats this same format list at the start without adding new semantic detail. With full schema coverage, the baseline of 3 is appropriate; the description adds no parameter-specific value beyond the schema.

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

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

The description opens with a specific verb and resource: 'Stop or dismiss a dataset's auto-annotation run.' It also enumerates the accepted reference formats and distinguishes the action from sibling tools like auto_annotate_status and auto_annotate_start. The phrase 'consistent with training_cancel and export_cancel' further classifies it as a cancel/off-switch tool.

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

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

The description clearly implies when to use this tool—when you want to stop or dismiss an auto-annotation run. It states 'Reads status first and refuses without calling the endpoint when no run is active,' which tells the agent this tool handles the status check internally. However, it does not explicitly name alternatives like auto_annotate_status for read-only checks, nor does it provide an explicit 'when not to use' condition, so it stops short of a full 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, while the description adds valuable behavioral detail: the default response omits bulky histogram/heatmap groups, names them in the summary, and explains that include_histograms=true returns the full payload unmodified. This goes beyond the structured annotations and helps the agent anticipate payload size and result 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 focused sentences: the first states the core purpose and input formats; the second explains the default omission and the escape hatch. No filler or repetition of schema content appears.

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, two-parameter tool with no output schema, the description covers the essential invocation details: what the tool returns, how to identify the dataset, and the optional flag's effect. An agent has enough information to call it correctly without additional guidance.

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

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

Schema description coverage is 100% and both parameter descriptions are already clear about dataset ref formats and the include_histograms behavior. The description reinforces these details but does not substantially add new meaning beyond the schema, which is expected when coverage is complete.

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: it gets per-class annotation counts for a dataset and lists the accepted reference formats (slug, owner/slug, ul:// URI). It clearly differs from sibling tools like datasets_get or explore_datasets, so an agent can tell what this tool is for without inspecting other definitions.

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

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

It provides clear context for when to use the tool: when per-class annotation counts are needed, and it explains the dataset reference formats. It does not explicitly name alternatives or state when not to use this tool, but its purpose is specific enough that implied usage is strong.

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

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

Annotations already mark the operation read-only and non-destructive. The description adds useful behavioral context beyond that: the result is a time-limited download link rather than the export itself, and it can target either the latest version or a specific frozen version. This is meaningful additional disclosure despite not detailing link expiry 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?

A single, front-loaded sentence states the action, the output, the input formats, and the version behavior with no filler. 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 retrieval tool with simple parameters and no output schema, the description covers the key return concept (time-limited download link) and the version selection behavior. It stops short of describing error cases or link expiry duration, but those are minor for the tool's complexity.

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

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

The input schema already describes both parameters, so the baseline is 3. The description goes further by explaining the accepted formats for 'dataset' (slug, owner/slug, ul:// URI) and clarifying that omitting 'version' yields the latest export while supplying it selects a frozen version. That adds real semantic value beyond the schema.

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

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

The description opens with a specific verb and resource: 'Get a time-limited export download link for a dataset.' It names the accepted reference forms (slug, owner/slug, ul://owner/datasets/slug URI) and the two retrieval modes (latest export or frozen version), which clearly sets it apart from sibling export operations like export_create, export_status, and exports_list.

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

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

The description conveys how to specify a dataset and choose between latest and frozen exports, but it does not explicitly state when to prefer this tool over export_create, export_status, or exports_list. Usage context is clear, but exclusions/alternatives are left to the agent to infer from sibling names.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds little behavioral detail beyond 'optional filtering' and accepted dataset references; it does not mention pagination defaults, result shape, or signed URL 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?

A single, front-loaded sentence contains the core verb, resource, accepted reference forms, and the existence of filters. Every word contributes value with no redundancy.

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

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

For a straightforward read-only list operation with 100% schema coverage and safety annotations, the description is largely sufficient. Minor gaps exist around return format and default pagination, but these are not critical for correct invocation.

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

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

Schema description coverage is 100%, so the baseline applies. The description mostly repeats the dataset reference formats already present in the schema and provides no additional meaning for the filter parameters beyond the generic phrase 'optional filtering.'

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'), names the resource ('images in a dataset'), and enumerates the accepted identifier formats (slug, owner/slug, URI). It is clearly distinct from sibling tools like datasets_list, which lists datasets rather than images.

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

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

The description implies when to use the tool by naming its action and resource, but it does not explicitly state when to choose it over alternatives or mention any exclusions. The usage context is inferable but not directly articulated.

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

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

The description adds meaningful behavioral details beyond the annotations: this starts an asynchronous job, returns a queued job id plus current ingest status, and defaults conflictPolicy to skip. It also notes that the platform default is undocumented. This compensates well for the lack of an output schema while remaining consistent with the non-idempotent, non-read-only annotations.

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

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

The description is two tight sentences with no filler. The action and accepted reference forms are front-loaded, followed by the default behavior and follow-up guidance. Every clause carries useful 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 there is no output schema, the description adequately explains what the caller should expect: a queued job id plus current ingest status, and how to follow up. It covers the async nature and a key default. It could mention validation limitations or error behavior, but for a four-parameter ingest starter this is 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?

Schema description coverage is 100%, so the schema already documents all four parameters. The description adds value for conflictPolicy by stating the default is skip and noting the platform default is undocumented, but it does not add meaning for dataset, sourceUrl, or targetSplit beyond what the schema provides. 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 opens with a specific verb and resource: 'Start a remote URL ingest job for a dataset,' then lists the accepted reference forms (slug, owner/slug, ul:// URI). This clearly distinguishes dataset_ingest from sibling upload and export tools.

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

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

The description clearly frames the tool as the remote-URL ingest path, which differentiates it from local upload siblings like dataset_upload_file, dataset_upload_folder, and dataset_upload_video. It also gives an explicit follow-up instruction: 'use datasets_get to follow up.' It stops short of naming when-not-to-use alternatives, but the context is clear.

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

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

Annotations already indicate a non-read-only, non-idempotent, non-destructive operation. The description adds a visibility-default nuance, but it does not disclose duplicate behavior, failure modes, permissions, or response behavior. The parenthetical about platform defaults is also slightly ambiguous relative to the schema's stated visibility default.

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 filler and a front-loaded purpose. The second sentence is useful but slightly awkwardly worded, preventing a top score.

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

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

For a tool with 7 parameters, 3 required, and no output schema, the description is minimally adequate but incomplete. It does not explain expected results, behavior on duplicates, or how it fits among sibling create/ingest/upload tools. The schema handles parameter meanings, but the surrounding operational context is 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?

Schema description coverage is 100%, so the input schema fully documents all parameters. The description adds only a visibility-default note that is already captured by the schema's 'private (default)' description, so it does not materially extend parameter understanding.

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 and resource: 'Create a dataset in your Ultralytics workspace.' It is clear and unambiguous versus siblings like projects_create or datasets_delete, but it does not explicitly name alternatives or contrast itself with them.

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

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

There is no guidance on when to use this tool versus alternatives such as dataset_ingest, dataset_upload_file, or dataset_version_create. No prerequisites, exclusions, or conditions are mentioned, so the usage context must be inferred from the tool name alone.

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

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

Beyond the destructiveHint=true annotation, the description discloses critical side effects: images and annotations go to trash, models trained on the dataset are not deleted, and trashed items are restorable for a bounded window. This adds valuable behavioral context that an agent needs to know before invoking a destructive 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 two sentences with zero filler. The first sentence front-loads the action and identifier formats; the second sentence concisely explains the consequences. Every sentence earns its place, and the structure is optimal for quick agent parsing.

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 destructive tool with one well-documented parameter and no output schema, the description covers everything an agent needs: how to specify the dataset, what happens to associated data (trash, models), and the restoration window. Nothing critical is missing for correct invocation.

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

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

The schema already provides full coverage (100%) of the single 'dataset' parameter with a description listing the same formats (slug, owner/slug, ul:// URI). The tool description repeats this information without adding new semantic meaning, so it does not compensate beyond the schema 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 states a specific verb ('Delete') and the resource ('a dataset') along with the exact identifier formats (slug, owner/slug, ul:// URI). This clearly distinguishes it from sibling tools like datasets_list, datasets_get, and datasets_create, which serve different purposes.

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: when you want to delete a dataset. However, it does not explicitly state when to prefer this over alternatives (e.g., dataset_version_delete) or mention any conditions or exclusions. There is no explicit when/not guidance, but the context is clear enough for a straightforward delete operation.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the accepted identifier forms, but that is more parameter-related than behavioral; it does not disclose things like not-found behavior, authentication needs, 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?

The description is a single compact sentence with no filler. The verb, resource, and the three accepted formats are all front-loaded and immediately actionable.

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 single-parameter read operation with annotations covering safety, the description is nearly complete. The only minor gap is that with no output schema, it does not describe the response structure, but 'details' conveys enough for an agent to know 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 100% and the only parameter, 'dataset,' already documents the same slug, owner/slug, and URI formats. The description restates this information rather than adding meaning beyond the schema, so the baseline score of 3 applies.

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

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

The description uses a specific verb ('Get') and resource ('details for one dataset'), and clearly enumerates the acceptable reference formats. It is immediately distinguishable from sibling tools like datasets_list or explore_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?

The description implies single-dataset lookup by using 'one dataset,' but it does not explicitly state when to prefer this over sibling tools such as datasets_list or explore_datasets. No exclusions or alternative conditions are given, so guidance is only implicit.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds no additional behavioral details beyond the obvious 'list' operation – it doesn't mention pagination, filtering, or the scope of datasets returned (e.g., owned vs. accessible).

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

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

The description is a single, concise sentence with zero filler. The core purpose ('List datasets') is front-loaded, making it easy to scan. It could arguably be too sparse, but for a simple list operation it is appropriately sized.

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 (no required params, no output schema), the description is adequate but has gaps. It doesn't explain the return format, whether pagination exists, or if it lists only owned datasets or all accessible ones. These missing details could leave an agent uncertain about the response structure.

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

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

The input schema provides 100% coverage for both parameters (owner and username), with clear descriptions. The tool description adds no extra meaning or nuance beyond what the schema already states, so the baseline score of 3 applies.

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

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

The description clearly states the verb 'List' and the resource 'datasets', scoped to 'your Ultralytics workspace'. This is specific and unambiguous, distinguishing it from sibling tools like datasets_get (which retrieves a single dataset) and exports_list.

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

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

The description implies its use case (listing datasets) but provides no explicit guidance on when to choose it over alternatives or when not to use it. There's no mention of alternatives or exclusions, leaving the agent to infer the appropriate 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?

The description discloses meaningful behavior beyond the annotations: it uses the signed-upload flow, defaults conflictPolicy to skip, and reports a queued job id with ingest status rather than a synchronous completion. It also tells the agent how to follow up via datasets_get, which is valuable for an async upload 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?

Two sentences carry the full functional description, default behavior, response expectation, and next step with no filler. The most important action and target are front-loaded, and every clause contributes 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 an async upload tool with no output schema, the description covers the essential operational details: what is uploaded, how the dataset is referenced, the conflict-policy default, what the response reports, and how to follow up. It does not explain the mechanics of the signed-upload flow, but that is likely a platform-level concern rather than a per-call requirement.

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 each parameter. The description adds context about the default conflictPolicy and the upload flow, but these mostly echo or slightly extend what is already in the schema, so a baseline score of 3 is appropriate.

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

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

The description states a precise action and resource: uploading a local dataset archive through a signed-upload flow, with dataset addressing formats explicitly listed. This clearly separates it from sibling upload tools like dataset_upload_folder and dataset_upload_video, even without naming 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?

The description implies the intended use case by focusing on local dataset archives and the signed-upload flow, but it never explicitly states when to choose this tool over dataset_upload_folder, dataset_upload_video, or dataset_ingest. The follow-up instruction to use datasets_get is useful but is not an alternative-selection guideline.

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 only declare readOnly=false, idempotent=false, destructive=false. The description adds meaningful behavior: the upload is asynchronous (queued job id), returns the dataset's current ingest status, and defaults conflictPolicy to skip. This goes beyond the structured annotations and helps the agent predict side effects.

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

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

The description is two sentences, front-loaded with the core action and reference formats. It is mostly economical, though the parenthetical "(the platform default is undocumented)" adds some noise and slight confusion given the schema already documents the default.

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 4-parameter tool with full schema coverage and no output schema, the description covers the essential behavioral flow: upload, queued job id, ingest status, and follow-up via datasets_get. It does not explain authentication details or exactly how the zip is formed, but the signed-upload mention and follow-up guidance are sufficient for correct invocation.

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

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

Schema description coverage is 100%, so the schema already documents dataset, folder_path, targetSplit, and conflictPolicy. The description mostly restates the dataset reference forms and conflictPolicy default that are already in the schema, adding little new parameter-level meaning.

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

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

The first phrase names a specific action and resource: "Upload a local image folder as a zip through the signed-upload flow for a dataset." It also states the supported reference forms. It does not explicitly contrast with sibling tools like dataset_upload_file or dataset_upload_video, but the folder-vs-file/video distinction is strongly implied.

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 useful context such as folder uploads, the signed-upload flow, conflictPolicy defaulting to skip, and following up via datasets_get. However, it does not state when to prefer this tool over dataset_upload_file/dataset_upload_video or when not to use it, so usage guidance remains implicit 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?

The description discloses meaningful behavior beyond the false annotation hints: it mentions the signed-upload flow, that the operation reports a queued job id, and that it returns the dataset's current ingest status. It also calls out that conflictPolicy defaults to skip even though the platform default is undocumented. These are useful behavioral details not present in the annotations.

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

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

The description is three sentences with no filler: one for the core action, one for the conflictPolicy default, and one for the response shape and follow-up. It is front-loaded with the most important action and keeps each sentence focused.

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 upload tool with no output schema, the description covers the return shape ('queued job id with current ingest status') and points to datasets_get for follow-up. It is complete for core invocation, though it lacks authentication requirements and comparison guidance against sibling upload tools.

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

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

Schema description coverage is 100%, so the baseline is 3 and the description need not compensate heavily. It does add one useful parameter-level detail: 'Defaults conflictPolicy to skip (the platform default is undocumented).' However, it does not enrich the semantics of fps, max_frames, targetSplit, dataset, or video_path beyond their 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 states a specific verb and resource: 'Upload a local video as extracted frames through the signed-upload flow for a dataset.' It also specifies the accepted dataset reference formats and describes the video-to-frames nature, which distinguishes it from upload_file/upload_folder without naming them.

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

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

There is no guidance about when to choose this tool over siblings such as dataset_upload_file, dataset_upload_folder, or dataset_ingest. The only hint is post-usage: 'use datasets_get to follow up,' which is not an alternative-selection guideline. The intended use must be inferred from the action description.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so the agent knows it's a mutating, non-idempotent operation. The description adds valuable nuance by explaining that if the dataset is unchanged, the existing version is returned instead of a new one—this clarifies the non-idempotent behavior and the 'frozen' immutability. It does not cover permissions or rate limits, but the key behavioral trait is 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?

Two sentences, both essential and front-loaded with the core action and the important exception. There is no filler or redundant phrasing. The structure is optimal for quick comprehension.

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

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

For a simple creation tool with two parameters, no nested objects, and no output schema, the description covers the essential usage, accepted reference formats, and the key behavioral nuance. It does not specify the return value, but given the lack of an output schema, that omission is acceptable for a create operation. The description is sufficient for an agent 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 schema already provides 100% coverage for both parameters, including descriptions for 'dataset' (slug, owner/slug, or URI) and 'description' (optional note). The tool description repeats the dataset reference formats but adds no new meaning beyond the schema. Since schema coverage is complete, the baseline of 3 applies; the description does not need to compensate.

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 ('Create a frozen dataset version snapshot') and the resource (dataset) with multiple ways to specify it. It distinguishes itself from sibling tools like dataset_version_restore or datasets_get by focusing on creation. The special behavior (returning existing version if unchanged) further clarifies the tool's unique purpose.

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

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

The description provides clear context for when to use it (creating a snapshot) and the specific behavior when the dataset is unchanged. It does not explicitly name alternatives or exclusions, but the context is unambiguous enough for an agent to select it over other version-related tools. The lack of explicit 'use instead of' guidance keeps it from 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?

The description goes well beyond the destructiveHint annotation by detailing exactly what is replaced (images, labels, splits), what is discarded (un-versioned manual annotation work), and the side effect on image IDs (held IDs resolve to empty label arrays rather than 404s). This is exemplary transparency for a destructive 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 dense but purposeful, with each sentence carrying important operational or recovery information. It could be slightly better structured with clearer separation between the core restore behavior and the post-restore re-listing guidance, but it remains efficient and front-loads the primary purpose.

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

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

For a destructive, non-idempotent tool with no output schema, the description covers the full operational picture: how to invoke it, what happens destructively, how to undo a mistake, and what callers must do afterward (re-list images). No critical behavioral gap remains for an agent to call it safely.

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 explains both parameters: dataset reference formats and version number sourced from datasets_get. The description reinforces these details and adds that versions are 'already returned unprojected,' but it does not fundamentally change or extend parameter understanding beyond the schema.

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

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

The description opens with a specific verb ('Restore a dataset to a previously saved version') and clearly identifies the resource and the accepted reference formats (slug, owner/slug, or ul:// URI). It also ties the operation to version listing via datasets_get, making it easy to distinguish from related version and dataset tools.

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

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

The description gives concrete usage context: it is positioned as the undo tool for auto-annotate runs, explains that restoring an auto-annotate snapshot reverts the run exactly, and notes that a mistaken restore can be recovered by restoring a later version. It does not enumerate explicit exclusions or when-not-to-use conditions, but the use case is clear enough.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe-read nature is known. The description adds valuable context by disclosing that serviceUrl and deployedAt are null until the deployment reaches 'ready' status, which is not inferable from annotations or schema. This goes beyond the baseline.

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

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

The description is two sentences with no fluff. The core purpose is stated first, followed by a crucial behavioral note about null fields. Every word earns its place, and the structure is optimal for quick parsing.

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 single-parameter retrieval tool with annotations covering safety, the description is complete. It covers the reference format, the default owner, and the null-field behavior. No output schema exists, but the description doesn't need to detail return values for this straightforward operation. 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 schema describes the parameter as 'Deployment ref by owner/deployment or a bare slug,' but the description adds the critical default behavior ('owner defaults to the account owner'), which is not in the schema. This provides additional meaning beyond the schema, justifying a score above the baseline of 3.

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

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

The description clearly states the action ('Get details') and the resource ('one deployment'), and specifies how to reference it (owner/deployment or bare slug with default owner). This distinguishes it from deployments_list, which lists multiple deployments, and from deployment_health/logs/metrics, which target specific aspects.

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 how to specify the deployment, including the default owner behavior. While it doesn't explicitly mention alternatives like deployments_list or deployment_health, the singular focus on 'one deployment' implies its use for single-deployment detail retrieval. The lack of explicit 'when not to use' is a minor gap but the intent is inferable.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only safety is covered. The description adds valuable context beyond that: it clarifies that the 'status' field refers to the upstream HTTP status at the deployment's service URL, not the tool call's status, and that the owner defaults to the account owner. This prevents a critical misunderstanding.

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, with the primary purpose stated first and the critical caveat about 'status' placed second. Every phrase earns its place, making it easy for an agent to parse quickly.

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 is present, so the description must convey the response shape. It explains the 'status' field but does not mention any other possible fields (e.g., timestamp, latency, error info) or behavior on missing deployments. For a simple health probe this is acceptable, but a bit more detail would improve completeness.

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

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

The input schema provides a 100%-covered description of the single 'deployment' parameter. The tool description goes further by explaining the default behavior when a bare slug is used (owner defaults to the account owner), which is not stated in the schema and helps the agent construct correct invocations.

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 ('Probe') and a clear resource ('one deployment's health'), with the scope defined by owner/deployment or bare slug. It distinguishes itself from sibling deployment tools by focusing on health probing, which is semantically distinct from deployment_get, deployment_logs, or deployment_metrics.

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 explicit guidance on when to use this tool versus alternatives like deployment_get or deployment_metrics. The description provides a behavioral detail about the owner default but does not mention when a health probe is appropriate or when another sibling would be better, leaving the agent to infer.

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

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

The description goes well beyond the readOnly/destructive annotations by explaining that severity is passed through unvalidated, that an invalid value surfaces the server rejection message, that limit has explicit defaults and caps, and that nextPageToken pages toward older entries. These are meaningful runtime behaviors not visible in annotations.

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

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

The description is compact, front-loads the main purpose, and then efficiently covers the key parameter behaviors. Every sentence adds useful information 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 read-only log retrieval tool with no output schema, the description is complete: it defines the target, owner resolution, severity semantics, limit bounds, and pagination. An agent has enough information to call the tool correctly and handle normal server behavior.

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

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

Schema coverage is 100%, so a baseline of 3 is appropriate. The description adds some value beyond the schema by noting that invalid severity values return the server's own rejection and that nextPageToken moves through older entries, which clarifies pagination direction. However, much of the parameter detail is already present in the 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 opens with a specific verb and resource: 'Read log entries for one deployment.' It clarifies how the deployment is addressed (owner/deployment or bare slug) and naturally distinguishes this from sibling tools like deployment_metrics or deployment_health by focusing on log retrieval.

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 clear: this tool is for reading logs of a single deployment, with optional severity filtering, limit tuning, and pagination. It does not explicitly name alternatives or state when not to use it, but the purpose is specific enough that an agent can infer when it is the right sibling.

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?

Beyond the readOnlyHint and destructiveHint annotations, the description discloses the two mutually exclusive response shapes, the exact fields returned for each, and that 'range' is passed through unvalidated. This is significant behavioral context that helps the agent interpret results and anticipate server behavior without contradiction.

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

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

The description is dense and informative, front-loaded with the core purpose, then detailing response shapes and parameter behavior. While it is a longer paragraph, every sentence adds value and there is no redundancy, so it remains concise relative to the complexity it conveys.

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 two response shapes and the absence of an output schema, the description fully covers what an agent needs to know: the fields in each shape, the parameter that selects them, and the behavior of range. No critical information is missing for a read-only metrics 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?

With 100% schema coverage, the baseline is 3, but the description adds substantial meaning: it explains the deployment parameter's format (owner/deployment or bare slug), clarifies that sparkline toggles the response shape, and specifies the default and unvalidated nature of range. This goes well beyond the schema descriptions.

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

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

The description clearly states the action ('Read metrics') and the resource ('one deployment'), with specific identifiers ('by owner/deployment or a bare slug'). It distinguishes itself from siblings like deployment_health and deployment_logs by focusing on metrics, and the sibling list confirms it's a distinct read operation.

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

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

The description clarifies what the tool does and the default owner behavior, but does not explicitly say when to prefer this over alternatives like deployment_health or deployment_logs. The context is clear enough for an agent to infer its use, but it lacks explicit exclusions or alternative routing.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the description adds significant extra context: it discloses that returns include undocumented metadata fields, that costs follow the deployment's resource configuration (no per-request cost), and that cold starts may cause slow responses or 503 errors with advice to check health. These details go beyond the annotations and are highly relevant for an agent invoking the 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 three sentences with no filler. It front-loads the core purpose, then covers return behavior, cost, and cold-start handling in a logical order. Every sentence contributes necessary information, making it highly efficient.

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

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

Given the tool's complexity (no output schema, annotations cover safety), the description is complete: it explains what the tool returns (images/metadata verbatim, including undocumented fields), cost implications, and a specific failure scenario (cold start) with recommended action. It also covers all required parameters' semantics through the schema and the added default-owner note. Nothing critical for an agent to call 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 coverage is 100%, so the baseline is 3. The description adds semantic value beyond the schema for the 'deployment' parameter by noting that 'owner defaults to the account owner' when a bare slug is used—information not present in the schema. It also reiterates that imagePath is local, matching the schema. For iou, conf, and imgsz, it adds nothing beyond the schema, but the additional default-owner behavior justifies a slightly higher 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 clearly states the action: 'Run inference through a deployment's own serving endpoint on a local image file'. It specifies the resource (deployment's endpoint) and the input (local image file), and clarifies how to reference the deployment (owner/deployment or bare slug with default owner). This distinguishes it from siblings like model_predict (model-based) and deployment_health (health check).

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 clear usage context: it explains how to specify the deployment and that the owner defaults to the account owner. It also provides a specific alternative: 'check deployment_health rather than retrying blindly' in the case of a cold start. While it doesn't explicitly contrast with model_predict, the deployment-specific nature is implied. The guidance is useful but could be more explicit about when to choose this over other inference tools.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the main safety profile. The description adds only the workspace scope and does not disclose additional behavior such as pagination, 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?

The description is a single, front-loaded sentence with no filler. It states the action and scope efficiently, making it easy for an agent to parse quickly.

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 operation with one optional documented parameter and annotations carrying the safety profile, the description is mostly complete. It lacks explicit output details or pagination behavior, but nothing critical is missing for invoking the tool correctly.

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

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

Schema coverage is 100%, and the single optional owner parameter is well documented in the schema with its default behavior. The description adds no extra meaning to the parameter, 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 uses a specific verb ('List') and resource ('model deployments'), and scopes it to 'your Ultralytics workspace.' This clearly distinguishes it from related sibling tools like deployment_get, deployment_health, and models_list.

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

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

No guidance is given about when to use this tool instead of alternatives such as deployment_get or deployment_logs. There is no mention of exclusions, prerequisites, or when a different tool would be more 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?

The description provides substantial behavioral detail beyond the annotations: it sends only {action: stop}, the server rejects already-stopped deployments with a 400 rather than succeeding, stopping preserves URL/configuration, and it still counts toward deployment quota. It also notes that it ships ungated, which the destructiveHint=true annotation doesn't convey. No contradiction with annotations.

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

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

While the description is longer than average, every sentence earns its place: scope, unreachable actions, side effects, server behavior, quota impact, and reversal unavailability. It front-loads the core action (stop) and the default-owner behavior before diving into caveats, making it dense with useful information rather than 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?

For a single-parameter tool with no output schema, the description is fully complete. It covers invocation (owner/deployment or slug, default owner), behavioral effects (quota, config/URL preservation), edge cases (already-stopped 400), endpoint constraints (only stop action), and the tool set's lack of a start counterpart. An agent has everything needed 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?

Schema description coverage is 100% and the single parameter 'deployment' is already fully described in the schema ('Deployment ref by owner/deployment or a bare slug'). The description repeats this without adding extra semantics like format examples or validation rules, 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 states a specific verb ('Stop') and resource ('a deployment'), and identifies the exact input forms (owner/deployment or bare slug). It also distinguishes itself by noting the endpoint's start/resize/replace actions are unreachable, which sets it apart from sibling tools like deployment_start or deployment_get.

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

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

Explicitly explains when to use this tool (to stop a deployment, acting as a money-off switch) and what happens with it, including that starting is unavailable in this tool set. It also references sibling tools like training_cancel and export_cancel as consistent with the ungated behavior, giving clear context for an agent choosing among tools.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the main behavioral safety profile is covered. The description adds very little beyond that, only scoping to public datasets, and does not mention result format, pagination, or any other runtime 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 a single concise sentence with no filler and the key information is front-loaded. It is somewhat under-specified, but it is not verbose or poorly structured.

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 4-parameter search tool with no output schema, the description is too thin. It does not explain what kind of results are returned, how to choose filters, or how this search relates to sibling tools. The annotations and schema cover safety and parameter names, but not enough operational context.

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

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

Schema description coverage is 100%, so the parameters q, sort, task, and offset are already documented. The description adds no extra parameter semantics, but the schema carries the burden sufficiently, so a 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 the operation ('Search'), the resource ('public datasets'), and the platform ('Ultralytics Explore'). It is distinguishable from siblings like datasets_list, though it does not explicitly contrast itself with explore_projects.

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 given about when to use this tool instead of related tools like datasets_list or explore_projects. The only usage signal is implied by the word 'search'; no conditions, exclusions, or alternatives are mentioned.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe query nature is covered. The description adds the 'public projects' scope, which is useful, but does not disclose result format, pagination behavior, or any rate limits. This is acceptable given 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?

A single sentence delivers the core purpose with no filler. The verb and resource are front-loaded, making it immediately scannable for an agent.

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, the description plus the fully documented schema and safety annotations cover the essentials needed to invoke it correctly. The lack of an output schema and explicit result-format details is a minor gap, but not critical for selecting and calling this 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%, with all three parameters (q, sort, offset) documented in the schema. The description does not add any parameter-level detail beyond the schema, so the baseline score of 3 applies.

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

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

The description clearly states a specific verb ('Search') and resource ('public projects on Ultralytics Explore'), making the tool's function immediately understandable. It is distinct enough from sibling tools like explore_datasets, though it does not explicitly name that 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?

No guidance is given on when to use this tool versus alternatives such as explore_datasets or projects_list. The description implies search functionality but provides no exclusions, prerequisites, or context for choosing this tool over others.

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?

Beyond the destructiveHint annotation, the description discloses that the same API verb deletes a finished export's artifact irreversibly, that the status check is non-atomic, and that a race can cause deletion instead of cancellation. This is exactly the kind of behavioral nuance an agent needs and would not know from annotations alone.

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, each earning its place: purpose, operational behavior, and the race-condition warning. The most important scoping information is front-loaded, and the destructive caveat is placed prominently. 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 destructive action with a race condition, the description fully covers how to identify the target, when cancellation is attempted, what terminal states mean, and the irreversible risk. The absence of an output schema is acceptable because return-value expectations are not necessary for safe invocation here.

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 baseline is 3. The description restates the model reference forms and the need for project with slug, but adds no materially new parameter meaning beyond what the schema already documents.

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: 'Cancel an active export job for a model,' immediately distinguishing it from export_create and export_status. It also clarifies the addressing modes and the export id, and further disambiguates the dual cancel-vs-delete behavior. This is a precise, non-tautological purpose statement.

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 clear context: it is for cancelling an export that is still active, and it explicitly says the operation refuses on any terminal status. It does not explicitly name alternatives such as export_status as the way to check status beforehand, so it stops short of full when-to-use-versus-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?

Beyond the annotations, it discloses that the operation is state-changing and may cost credits, that format is validated immediately but compatibility is deferred until run time, and that a queued export can still fail. This gives the agent a realistic model of asynchronous behavior without contradiction.

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

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

Three dense sentences front-load the core action and cost implications, then cover failure modes and follow-up tools. 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 an async, state-changing operation with no output schema, the description covers cost, validation timing, deferred failures, and follow-up status checks. It does not mention the shape of the immediate response or how to obtain a job identifier, which is a minor gap given the tool's 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 baseline is 3. The description mostly restates schema content such as model ref formats, server-side format validation, and confirm_cost requirement, adding little new semantic value beyond what the schema already documents.

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: 'Create a model export job'. It clearly distinguishes this from the sibling tools export_status, exports_list, and export_cancel by framing it as the state-changing creation step, and it reinforces the distinction by pointing to status/list tools for the outcome.

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 export_status and exports_list for the real outcome, which is direct guidance on how this tool fits versus alternatives. It also states the prerequisite confirm_cost=true, giving concrete when-to-use conditions.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds scoping context about which model references are accepted, but it does not disclose return shape, pagination, or ordering. This is acceptable given the low-risk read-only nature, but no meaningful behavioral depth is added 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?

A single, front-loaded sentence captures the operation, resource, and supported identifier formats with no filler. Every clause contributes necessary information.

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

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

For a simple, read-only list operation with two parameters and good schema coverage, the description is mostly adequate. However, there is no output schema and no mention of return contents or pagination, and the lack of guidance relative to export_status leaves a meaningful context gap for an agent deciding which tool to invoke.

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

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

Schema description coverage is 100%, and both the schema and the description explain the same model reference formats and the project requirement for slugs. The description restates rather than extends the schema, so it meets the baseline without adding new semantic value.

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 ('export jobs for a model'), and names the valid reference forms (owner/project/model, ul:// URI, or slug with project). It is clear, but it does not explicitly distinguish this tool from the sibling export_status, so it stops short of full sibling differentiation.

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 what can be listed and the required reference forms, but gives no guidance about when to use this instead of export_status, export_create, or export_cancel. There are no explicit alternatives or exclusions, so an agent must infer the boundary between listings and status checks.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description's 'Get' is consistent with a safe read operation. The description adds no extra behavioral context such as polling semantics, response states, or authentication requirements, but the annotations cover the main safety profile.

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

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

The description is a single sentence, front-loads the core action, and includes the essential addressing options without filler. Every phrase contributes to understanding what the tool does and how to invoke it.

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 status lookup, the description plus fully documented schema is largely sufficient to call the tool correctly. It does not explain the return format or what status values to expect, but the core invocation requirements are all covered.

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 description largely restates what the schema already says about model refs and export_id. It adds no new meaning beyond the schema, so the baseline score applies.

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

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

The description names a specific verb ('Get'), a specific resource ('one export job's status'), and the supported model reference forms. It is clearly distinct from the sibling exports_list, though it does not explicitly name 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?

It provides useful usage prerequisites: model can be given by owner/project/model, ul:// URI, or slug requiring a project, and export_id is needed. However, it does not say when to prefer this over exports_list, export_create, or export_cancel, so the selection context is only implied.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false. The description adds no additional behavioral context beyond confirming the tool's purpose. No contradiction.

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

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

A single, well-structured sentence conveys the full purpose without superfluous words.

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

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

Given the tool has no parameters, no output schema, and annotations cover the safety profile, the description provides all necessary context for a simple read query.

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 no parameters, so the description does not need to add parameter semantics. Baseline score of 4 is appropriate as there is nothing to document.

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 'Get' and clearly identifies the resource 'cloud-GPU stock status' with a qualifier 'by GPU type'. It distinguishes this tool from its siblings, which focus on datasets, models, and projects.

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

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

There is no explicit guidance on when to use this tool versus alternatives. However, the narrow focus on GPU availability and the sibling tools being about datasets and models imply its appropriate use case.

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

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

Annotations declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, so the description carries some burden. The description adds useful behavioral context: it downloads a file to a local path, and the filename parameter description explains the selection behavior ('Omit to prefer best.pt, then the first available file'). However, it doesn't disclose what happens if the file already exists without overwrite=true, or whether the download is resumable. The overwrite parameter is documented in the schema, so the description doesn't need to repeat it. The description adds value beyond annotations by clarifying the file selection 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 a single sentence that front-loads the core action (download weight file to local path) and then lists the accepted reference formats. Every word earns its place. The filename parameter description is also concise and informative. No fluff 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 download tool with 5 parameters, 100% schema coverage, and no output schema, the description is fairly complete. It explains the reference formats, the filename selection behavior, and the local destination. The main gap is that it doesn't state what happens on overwrite=false when the file exists, but that's a minor edge case. The tool is a straightforward file download, and the description covers the essential decision points.

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

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

Schema description coverage is 100%, so the schema already documents all 5 parameters. The description adds value by clarifying the relationship between model, project, and filename: it explains that slug requires project, and that filename does not set the local output filename. This goes beyond the schema descriptions. However, the description doesn't add much beyond what the schema already provides for output_path and overwrite. Baseline 3 for high coverage, plus the added clarification about slug/project and filename behavior, justifies a 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 states a specific verb ('Download'), a specific resource ('a trained model's weight file'), and the destination ('to an explicit local path'). It also enumerates the three accepted reference formats (owner/project/model, ul:// URI, or slug with a project), which distinguishes it from sibling tools like models_get or model_predict. This is a clear, specific statement of what the tool does.

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

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

The description implies when to use this tool: when you need to download a model's weight file to a local path. It does not explicitly name alternatives or state when not to use it, but the context of sibling tools (models_get, model_predict, model_plots) makes the use case fairly clear. The description could be improved by explicitly saying 'use models_get to inspect model metadata instead' or similar, but the core usage context is present.

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

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

The description is rich in behavioral details: it explains that bestEpochMetrics is pulled explicitly from trainResults by matching epoch against bestEpoch, independent of include_history window. It also specifies that on incoherent training data, the tool returns nulls instead of echoing unreliable platform values, and that include_train_args adds a large object (111 keys). Even with annotations indicating read-only and non-destructive, the description adds crucial context about data integrity and return 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?

The description is longer than typical but packed with necessary information. It front-loads the core purpose of distinguishing best vs final epoch metrics, and then elaborates on edge cases and flags. Every sentence adds value, though the length could be slightly trimmed without losing critical context. The structure is logical: purpose, detailed behavior, edge cases, optional parameters.

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

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

Given the tool's complexity (distinguishing best/final metrics, handling edge cases), the description covers all necessary context. It explains the meaning of null returns, the behavior of include_history and include_train_args, and notes the epoch window reporting. Since there is no output schema, the description compensates well by detailing return semantics. An agent can call this tool correctly without ambiguity.

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

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

The schema already has detailed descriptions for each parameter (100% coverage). The description adds semantics like 'omitted by default' for include_history and include_train_args, and clarifies the meaning of history_last_n's window reporting. It also explains the impact of include_train_args on performance, which goes beyond the schema's 'roughly a hundred keys'.

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 reports a model's best-epoch and final-epoch evaluation metrics, with a specific verb and resource. It explicitly differentiates the two metric sets, which is critical for agent understanding, and mentions it works for private and public projects. It stands out from sibling tools like model_plots and training_monitor because of this precise focus on epoch-level metrics, including handling of edge cases.

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: when you need a model's evaluation metrics at best and final epochs, especially to avoid confusion between the two. It also explains conditions like include_train_args and include_history, but does not explicitly say 'use this instead of X' or 'when not to use'. The context is clear, but exclusions and alternatives to siblings could be more 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?

While annotations already declare readOnlyHint=true and destructiveHint=false, the description adds valuable behavioral context beyond annotations: it warns about the potentially large size of pr_curve data, explains that field shapes vary by type (pr_curve has ap, confusion_matrix has matrix), and clarifies that plot presence does not correlate with training history. This is rich, non-obvious behavior that an agent needs to know.

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 detailed but every sentence earns its place. It front-loads the purpose and key distinctions, then adds essential operational details (size warning, field structures, presence caveats) without redundancy. It is well-structured and not overlong.

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

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

For a read-only tool with no output schema, the description is remarkably complete. It covers what the tool returns, how to filter, the variability of fields, and edge cases like empty plots. An agent has everything needed 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 schema already has 100% coverage with descriptions for all three parameters, so schema is doing the heavy lifting. However, the description adds meaningful semantics about the 'type' parameter (e.g., that it returns data unmodified, and that field shapes vary), which goes beyond simple parameter definitions, earning a 4.

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

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

The description clearly states it reports evaluation plots with specific plot types listed, and differentiates from model_metrics and training_monitor by noting they do not surface these plots. This is a specific verb-resource pair with clear sibling differentiation.

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 contrasts with model_metrics and training_monitor, telling the agent when to use this tool instead. It also provides clear guidance on default behavior vs. passing 'type', which is a usage guideline in 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 readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds context that inference is performed on URL/base64 sources and explicitly excludes local file paths, but it does not describe output behavior, errors, or other runtime expectations. 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?

A single sentence that states the action, resource, accepted source formats, and key exclusion with no filler. The most important information is front-loaded and everything included 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?

The description handles the core purpose and source input well, and the schema covers parameter details. However, with no output schema, no mention of the return payload or errors, and no differentiation from deployment_predict, the definition is functional but not fully complete for an agent deciding 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?

The input schema has 100% parameter description coverage, documenting model, source, project, conf, iou, and imgsz. The description only restates the source constraints and model context already present in the schema, adding no new parameter-level meaning, so the baseline score of 3 applies.

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

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

The description clearly states the operation ('Run inference') and resource ('with a trained model'), plus the accepted image source forms (URL or base64). It is specific and immediately understandable, though it does not explicitly distinguish itself from the sibling deployment_predict tool.

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

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

There is no guidance on when to use this tool versus deployment_predict or other inference-related siblings. The only directional constraint is 'no local file paths', which is more about the source parameter than about tool selection, so an agent is left to infer the appropriate 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?

The description adds substantial behavioral context beyond the annotations: deletion is soft, models go to trash, remain restorable, and weights/training history/exports are only removed on permanent deletion. This meaningfully clarifies the destructiveHint=true annotation and alerts an agent to the reversible nature.

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 focused sentence front-loads the operation and reference formats, then appends the consequential trash/restore behavior. There is no filler or redundant restating 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 two-parameter destructive operation with complete schema descriptions and no output schema requirement, the description covers how to identify the model, the required project context for slugs, and the post-deletion state. Nothing an agent needs to invoke 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 the description largely restates the model parameter's ref formats and the project requirement. It reinforces the parameter semantics but does not add new details beyond the input schema, so the baseline score applies.

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

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

The description opens with a specific verb-resource pair, 'Soft-delete a model', and spells out the three accepted reference forms. It clearly differentiates this delete operation from read-only siblings like models_get/models_list and makes the soft-delete semantics immediately apparent.

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 context for when the tool is applicable: deleting a model by standard refs, and notes the project requirement for slugs. It does not name an alternative or state explicit when-not-to-use conditions, but the reference formats and trash behavior provide enough guidance 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=true and destructiveHint=false, so the agent knows this is a safe read operation. The description does not add behavioral context beyond that, such as error behavior or response contents, but it does not contradict the annotations either.

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

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

One sentence with no filler, front-loading the action and object before listing accepted input forms. Every word earns its place, and the structure is easy to scan.

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

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

For a simple single-model read operation with complete schema coverage and safety annotations, the description provides all identifier options needed to invoke it correctly. No output schema is present, but 'details' is sufficiently clear for this tool's purpose.

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

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

Schema description coverage is 100%, so the input schema already documents both parameters fully. The description repeats the same identifier formats rather than adding new semantic value, meriting the baseline score of 3.

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

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

The description uses a specific verb ('Get') and resource ('details for one model'), and enumerates the exact identifier forms accepted. It clearly distinguishes this from sibling tools like models_list and model_download by focusing on a single model's details.

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

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

The description provides clear context: use this when you need details for a single model and have one of the supported ref formats. It does not explicitly name alternatives or exclusions, but the intent is obvious from the 'one model' wording and the ref requirements.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds no additional behavioral context such as pagination, return format, or rate limits, so it provides minimal value beyond what annotations already convey.

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

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

The description is a single sentence with the action front-loaded and no redundant wording. Every word contributes to specifying the tool's purpose and input format.

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

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

For a simple list tool with one parameter and no output schema, the description is complete: it specifies the input format and the action clearly, and the annotations cover the safety profile. Nothing essential for calling the 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% and the description repeats the parameter description verbatim ('Project ref by slug, owner/slug, or ul:// URI'), adding no new meaning beyond what the schema already provides. Baseline 3 is appropriate.

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

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

The description states the verb 'List', the resource 'models', and the scope 'in a project', plus three explicit ways to specify the project (slug, owner/slug, ul:// URI). This clearly differentiates it from sibling tools like models_get (single model) and models_delete (destructive).

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

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

Provides clear context on how to specify the project, but does not explicitly mention when to use this tool over alternatives. The context is sufficient for an agent to infer the use case (listing models) without confusion, though it lacks explicit 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 cover the mutation profile (readOnlyHint=false), and the description adds a genuinely useful behavioral nuance: the tool defaults to private visibility while the platform would otherwise default to public when the field is omitted. This goes beyond structured fields and helps the agent avoid an unwanted public project.

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 filler: the primary action is front-loaded, and the parenthetical about platform defaults earns its place because it prevents a costly mistake. Nothing unnecessary 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?

All 5 parameters are documented in the schema and annotations cover safety semantics, making basic invocation complete. However, the description omits uniqueness constraints, error behavior, or what happens if the project slug already exists—minor but real gaps for a create operation with no 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?

Input schema coverage is 100%, and every parameter has a description. The description adds context for visibility by explaining the default behavior, but this largely mirrors the schema's 'private (default)' note. With full schema coverage, a baseline of 3 is appropriate.

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

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

The description states a specific verb and resource: 'Create a project in your Ultralytics workspace.' It is unmistakably a creation operation, clearly distinct from sibling tools like projects_list, projects_get, and projects_delete without needing to inspect their schemas.

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 intended use is implied by the action 'Create a project,' but the description offers no explicit when-to-use guidance or alternatives. It does not tell the agent when to prefer this over related project tools or mention exclusions, so usage context is only implicit.

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

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

The description discloses that the deletion is soft and reversible, adding nuance beyond the destructiveHint annotation. It specifies that projects go to trash and remain restorable for a bounded window, which is critical behavioral context an agent needs to know before invoking a destructive 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 a single, information-dense sentence that front-loads the action and identification method, then provides outcome. No filler or redundancy; 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 single-parameter destructive tool with annotations covering safety and no output schema, the description is fully adequate. It explains what, how, and the post-deletion state, leaving no essential detail 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 schema already provides a complete description of the 'project' parameter (covering slug, owner/slug, and ul:// URI) with 100% coverage. The description merely restates this information without adding new meaning or syntax details, so the baseline of 3 is appropriate.

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

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

The description clearly states the action (soft-delete), the resource (project), and the accepted identifiers (slug, owner/slug, or ul:// URI). It also specifies the outcome (lands in trash, restorable for a bounded window), distinguishing it from read-only and other delete tools.

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

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

The description clearly establishes the tool's purpose for deleting projects, and the resource type makes it obvious which sibling it pairs with (e.g., projects_get vs projects_create). It does not explicitly mention when not to use or name alternatives, but the context is clear enough to infer correct usage.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds no further behavioral details such as response shape, error behavior, or authorization requirements, but for a simple read operation the annotation coverage lowers the burden.

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

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

One sentence, front-loaded with the core action, and no filler. Every word 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 one-parameter read-only tool, the description provides enough to invoke it correctly. The main gap is that 'details' is fairly vague and there is no output schema, though that is a minor concern for a simple getter.

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 parameter description already lists slug, owner/slug, and ul:// URI formats. The tool description essentially restates the same information, adding no new semantic meaning beyond the schema.

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

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

The description states a specific verb ('Get details') and a specific resource ('one project'), and it names the three accepted reference formats. This clearly distinguishes it from sibling tools like projects_list, which would return multiple projects.

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 makes it clear this is for retrieving a single project by an identifier, which gives an agent clear context for when to call it. It does not explicitly name alternatives or exclusions, so it stops short of a 5, 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=true and destructiveHint=false, covering the safety profile. The description adds the workspace scope but does not disclose pagination, return shape, or default-owner behavior beyond what the schema already 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?

A single front-loaded sentence with no redundant wording. The action and object are stated immediately, and every word contributes to the meaning.

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

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

For a simple read-only list with fully documented optional parameters and no required arguments, the description is sufficient for correct invocation. It does not explicitly describe the return format, but the verb 'List' conveys the output adequately and annotations cover side effects.

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 owner and username fully described, including defaults and precedence. The description adds no parameter-level meaning beyond the general workspace context, so the schema carries the burden.

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 'List' with a clear resource ('computer-vision projects') and scope ('your Ultralytics workspace'). This distinguishes it from sibling tools like datasets_list and exports_list, even though no alternative is explicitly named.

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 no guidance on when to use this tool versus alternatives such as explore_projects, projects_get, or projects_create. The intended use is only implied by the verb 'List', with no explicit when/when-not conditions.

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

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

The description gives rich behavioral detail beyond the annotations: cancelling releases the compute instance, elapsed GPU time is still charged, the most recent checkpoint is preserved, and the operation does not delete the model. This meaningfully supplements the destructiveHint and readOnlyHint annotations and helps the agent anticipate side effects and billing consequences.

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. The first sentence identifies the action and target; the second covers consequences; the third clarifies what the operation does not do. Every sentence earns its place without 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 destructive, non-idempotent operation, the description covers the essential context: how to reference the model, what side effects occur, cost implications, checkpoint preservation, and that the model is not deleted. Combined with complete schema coverage and relevant annotations, nothing critical is missing for an agent to invoke the tool correctly.

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

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

Schema description coverage is 100%, so both `model` and `project` are already documented in the input schema. The description restates the accepted reference forms but does not add new parameter-level meaning beyond what the schema provides, so the baseline score of 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'Cancel a running training job.' It also distinguishes the tool from siblings by scoping it to training jobs and explicitly stating that stopping is not deletion of the model. This makes the tool's purpose immediately clear and distinct from training_start, training_monitor, and models_delete.

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 clearly explains how to identify the target job via owner/project/model, ul:// URI, or slug with project, and notes the project requirement for slug references. It does not explicitly name alternative tools or when-not-to-use conditions, but the context strongly implies this is the cancellation action for training jobs, so the usage 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?

Annotations already mark the tool read-only and non-destructive. The escription adds substantive semantics: timing.elapsedMs is wall-clock since creation, evaluated at request time, and means different things for active vs finished models; computeCost.durationMs is billed time. This clarifies a genuine gotcha and goes well 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 sentences, front-loaded with the core purpose, followed by two high-value timing clarifications. No filler; the nuance is necessary and placed compactly.

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 status-reporting tool without an output schema, the description gives the key output semantics (elapsedMs vs computeCost.durationMs) and points at history behavior through schema docs. It doesn't enumerate status values or the full response shape, but the available schema and annotations cover most invocation needs. This is slightly better than minimal.

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 four parameters have rich descriptions in the input schema, so schema coverage is 100%. The tool description adds no parameter-level meaning beyond the schema; it explains response fields instead. 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 escription states a specific action ('Report a model's training status and progress') and resource (a model), which clearly distinguishes it from training_start and training_cancel. It does not explicitly name or differentiate from sibling getters likemodels_get or model_metrics, so it stops 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?

The phrase 'works for private and public projects' gives context, and 'Report...status/progress' implies a monitoring use case. However, no explicit when-to-use or when-not-to-use guidance is given, and no alternatives are named, so an agent must infer when training_monitor is preferred over models_get or model_metrics.

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

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

Annotations indicate destructiveHint=true and readOnlyHint=false, but the description goes far beyond that: it details exactly what is destroyed (status, epoch count, per-epoch metric history) and that it is irrecoverable; it discloses billing starts immediately with no cost preview; it reveals a side effect in checkpoint mode (leftover model) and names the delete tool. This is far richer than the annotations alone.

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 long, but every sentence adds unique and essential information given the tool's complexity (multiple modes, destructive effects, cost). It is front-loaded with the purpose and then systematically explains edge cases. While slightly verbose, it avoids redundancy and is appropriately sized for the risk profile.

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 high complexity (11 parameters, nested objects, multiple modes), the description covers all calling requirements: prerequisites, side effects, confirmation flags, and failure modes. It does not describe the return value or output, which is a minor gap since no output schema is provided, but the agent has sufficient information to invoke and interpret the operation. Sibling tools like training_monitor partially fill the output 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%, but the description adds critical parameter interplay: it clarifies that confirm_cost must be true, confirm_history_loss is required only for existing trained models, explains how train_args top-level conflicts are handled (silently overridden or rejected), and defines the semantics of dataset lists vs single dataset. This is substantial value beyond the schema.

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

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

The description states a specific verb (start) and resource (cloud training job) and clearly distinguishes from siblings: it explicitly references training_cancel for stopping and mentions model_download, training_monitor, etc. indirectly. It differentiates from other training-related tools by describing its unique role as starting 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 explicitly states when to use the tool (to start training) and provides explicit conditions: it explains when confirm_history_loss is needed vs not, how checkpoint mode differs, and when cost confirmation is mandatory. It even names training_cancel as the alternative for stopping a running job, giving clear routing.

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