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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action but does not mention side effects, whether downloading starts immediately, queueing behavior, idempotency, or any error conditions. The only extra detail is accepted URL schemes, which is helpful but leaves many behavioral aspects unclear.

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

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

The description is compact and front-loaded with the core purpose. The Args block is organized and each line adds necessary information without redundancy. There is 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?

The tool is relatively simple and an output schema exists, so return values are covered. However, the description lacks behavioral details such as whether the task starts automatically, any authentication requirements, or what happens when the URL is invalid. These gaps make it only partially complete for an agent deciding how to invoke it correctly.

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

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

Schema description coverage is 0%, but the description compensates by explaining all three parameters: url with protocol examples, name as optional save filename, and connections as optional HTTP concurrent connection count. It adds meaning beyond the raw schema types, though it could go further with constraints like accepted values or defaults.

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+resource: 'Create a new download task.' This directly distinguishes it from siblings like list_tasks, pause_task, resume_task, and delete_task. The action is unambiguous and immediately identifies the tool's role.

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

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

The description implies when to use the tool (to create a download task) but does not explicitly discuss exclusions, prerequisites, or alternatives. With siblings covering list/pause/resume/delete/config operations, the need to articulate when not to use this tool is minor, but the guidance is still mostly 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?

With no annotations, the description carries the behavioral burden. It correctly discloses that `force` will also delete downloaded files, but it does not mention irreversibility, confirmation behavior, or whether active/incomplete tasks are protected. A deletion tool with no annotation coverage should state these caveats.

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

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

The description is short, front-loaded with the main action, and includes only the necessary `force` clarification. Every sentence earns its place; there is no redundant 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?

The tool is simple and has an output schema, so return values need not be explained, but the missing distinction from `delete_done_tasks` and the undefined term 'historical' prevent an agent from being fully confident about scope. A sentence clarifying prerequisites or irreversibility would make the definition complete.

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

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

The only parameter, `force`, is a bare boolean in the schema with 0% schema description coverage. The description fully compensates by explaining that passing force also deletes the downloaded files for each completed task.

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 ('Delete all') and a clear target ('completed historical download tasks'), so an agent can understand what the tool does. However, it does not differentiate from the sibling `delete_done_tasks`, which appears to cover the same or overlapping concept, 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?

No guidance is given about when to prefer this tool over `delete_task`, `delete_done_tasks`, or any other sibling. The phrase 'completed historical' only implies the selection criteria; it does not state exclusions or point to alternatives.

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

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

No annotations are provided, so the description must disclose behavioral traits itself. It only says 'Alias for deleting completed download tasks,' which adds little beyond the tool name and does not explain side effects, irreversibility, or how the 'force' parameter alters behavior. The word 'Alias' implies equivalence with another operation but does not specify what that operation entails.

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 no redundant wording and the main action is front-loaded. It is concise, though that conciseness comes at the cost of omitting parameter semantics. As a structure, it is clean, but not fully informative.

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 deletion tool with no annotations and a parameter that is undocumented everywhere, the description is incomplete. It does not explain 'force', the difference from delete_completed_tasks, or any postconditions of the operation. The presence of an output schema helps with return values but not with these gaps.

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

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

Schema description coverage is 0%, and the description does not mention the 'force' boolean parameter at all. The input schema only provides a title and default, leaving the parameter's meaning entirely unexplained. The description fails to compensate for the missing parameter documentation.

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

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

The description clearly states the verb and resource: 'deleting completed download tasks.' It is not a tautology and an agent can tell what action occurs. However, it does not differentiate from the sibling tool delete_completed_tasks, and the word 'Alias' signals that it may be a duplicate rather than a distinct 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 gives general context—this affects completed download tasks—but it provides no explicit when-to-use or when-not-to-use guidance. Given the sibling delete_completed_tasks, there is no direction about which tool to prefer or how these two relate. The agent must infer the intended usage from the 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?

With no annotations provided, the description carries the full burden. It does disclose the important behavior that downloaded files are only deleted when force is true, which is valuable. However, it does not mention that deletion is irreversible, what happens to an actively running task, or what occurs to the downloaded files in the default case beyond leaving them intact.

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 compact, front-loaded one-liner followed by a minimal two-item Args block. There is no filler or redundancy; every sentence contributes either purpose or parameter 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 two-parameter delete tool, the core functional surface is covered, and an output schema exists to handle return values. The main gap is the lack of boundaries against sibling bulk-delete tools and any notes about side effects on active tasks or file permanence, which keeps it from being fully complete.

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

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

Schema coverage is 0%, so the description must compensate, and it largely does: task_id is explained as the task to delete, and force is given the meaningful explanation 'Also delete downloaded files' with its default of False. This adds real semantics beyond the schema titles. The task_id explanation is somewhat obvious, so it is not a perfect 5.

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 'Delete a download task', which gives a specific verb and resource, and the Args section clarifies that it operates on the task identified by task_id. However, it does not explicitly distinguish itself from sibling tools like delete_completed_tasks or delete_done_tasks, so it stops short of 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?

There is no guidance on when to use delete_task versus the sibling batch/cleanup deletion tools. The description does not mention preconditions, such as whether the task must be done or can be running, or when it is preferable to use one of the bulk delete tools. The only usage-adjacent info is the force default, which is more parameter semantics than usage guidance.

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

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

No annotations are provided, so the description carries the behavioral transparency burden. 'Get current' implies a read-only snapshot without side effects, but the description does not explicitly state that it makes no changes or that no special permissions are required. It 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 directly states the operation and target. There is no filler or redundant information, making it appropriately concise for such a simple tool.

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

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

For a zero-parameter getter with an output schema, the description is largely complete: it identifies what is retrieved. The only shortcoming is the lack of explicit usage guidance or an explicit read-only statement, but the low complexity limits the impact of these omissions.

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

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

The tool has zero parameters, so the description has no parameter semantics to add. The baseline of 4 applies because there is nothing missing.

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

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

The description uses a specific verb ('Get') and names the exact resource ('current Gopeed configuration'). This clearly distinguishes it from sibling tools like update_config, which implies modification rather than 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 description does not state when to use this tool versus alternatives. It implicitly suggests reading configuration, but there is no explicit guidance about using update_config when modification is needed or listing conditions for choosing this tool.

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

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

No annotations are provided, so the description bears the burden of behavioral disclosure. The verb 'get' implies a read-only operation, and 'detailed info' indicates the nature of the response. However, it does not explicitly state that no side effects occur, or what happens for invalid/nonexistent task IDs. The output schema covers return structure, so the main gap is side-effect clarity.

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

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

The description is short, front-loaded with the primary purpose, and includes a clean Args structure. Every element earns its place—there is no filler, redundancy, or repetition of schema-only details.

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

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

For a simple one-parameter tool with an existing output schema, the description is largely complete. It explains the purpose and parameter source, and the output schema handles return values. It could add explicit alternative routing, but that is not critical for a straightforward read operation.

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

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

Schema description coverage is 0%, but the description's Args block adds meaning by explaining that task_id is a Task ID and specifically referencing list_tasks as the source. This gives the agent provenance and context beyond the raw schema, which only provides a type and title. The single parameter is effectively documented.

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: 'Get detailed info for a specific task.' This clearly distinguishes it from list_tasks and other sibling operations by focusing on retrieving details for a single task. An agent can tell immediately what this tool does and how it differs from the other task-related 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 provides a clear usage context by specifying that task_id should come from list_tasks, establishing a prerequisite workflow. It does not explicitly name alternatives or exclusions, but the purpose is unambiguous enough that an agent knows to use this when it needs details on an already-listed task.

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

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

No annotations are provided, but the verb 'List' strongly signals a read-only operation with no side effects. The description also discloses the allowed status values. It does not mention pagination or ordering, but the output schema covers the return shape, so this is a minor gap.

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

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

The description is compact and front-loaded, stating the core behavior in the first sentence. The Args section is minimal and directly supplies the missing parameter semantics without unnecessary detail.

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 optional parameter and an output schema, the description covers purpose, filtering options, and accepted status values. Nothing essential for correct invocation is missing.

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

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

The input schema provides only a generic string/null status field with no enum or explanation. The description compensates by explicitly listing valid filter values and stating that filtering is optional, adding the necessary 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 uses a specific verb and resource: 'List all download tasks'. It also clarifies the optional status filter, so an agent immediately understands what the tool does and how it differs from task mutation or deletion siblings.

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

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

The description clearly indicates this tool is for listing download tasks, with optional status filtering. It does not explicitly name alternatives such as get_task_detail, but the context is clear enough for an agent to infer when listing is appropriate.

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

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

No annotations are present, so the description carries the full burden of behavioral disclosure. It only states that the task is paused, without explaining state transitions, idempotency, reversibility, or side effects.

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

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

The description is compact and front-loaded with the action statement. The Args section is clear and contains no unnecessary prose.

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 command with an output schema, this is minimally adequate. However, it lacks behavioral context such as what happens if the task is already paused, whether it can be resumed, or how it relates to sibling operations.

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

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

Schema description coverage is 0%, but the description adds minimal meaning by stating that task_id is 'Task ID to pause.' This goes slightly beyond the schema's type-only definition, though it largely restates the parameter name and tool purpose.

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: 'Pause a download task.' This clearly identifies the tool's action and differentiates it by function from siblings like resume_task and delete_task, 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?

There is no guidance on when to use this tool versus alternatives such as resume_task or delete_task. No preconditions, edge cases, or contexts are given, so the agent must infer usage purely from the tool name and description.

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

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

No annotations are provided, so the description carries the full disclosure burden. It states the main effect (resuming a paused task) and the precondition ('paused'), but does not describe error behavior, idempotency, or what happens if the task is not in a paused state. This is acceptable for a simple state-transition tool but not richly transparent.

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

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

The description is concise: a front-loaded action sentence followed by a minimal parameter explanation. Every sentence earns its place, with no filler or redundancy.

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

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

For a one-parameter state-transition tool with an output schema, the description provides the essential action, precondition, and parameter meaning. It does not explicitly describe edge cases or its relationship to pause_task, but nothing critical is missing for an agent to invoke it correctly.

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

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

Schema description coverage is 0%, so the description must compensate. The args block explains that task_id is the 'Task ID to resume,' adding semantic meaning beyond the schema's bare string type and title. Since there is only one parameter and it is fully explained, this is sufficient.

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

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

States a specific verb ('Resume') and a specific resource ('a paused download task'), which clearly distinguishes it from siblings like pause_task, delete_task, and list_tasks. The one-sentence definition is not a tautology and immediately conveys 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 phrase 'a paused download task' implies the tool should be used when a task is already paused, and the sibling list includes pause_task as a counterpart. However, it does not explicitly state when not to use it or mention alternatives, leaving the usage guidance mostly 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?

With no annotations, the description carries the behavioral burden. It discloses the important merge behavior (unmentioned fields are left unchanged), but does not address side effects, persistence, validation failures, or whether changes affect running downloads.

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: a one-sentence purpose followed by a clean Args list. Every line earns its place and there is no filler or repetition of schema types.

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

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

For a simple tool with three optional scalar parameters and an output schema that can document the return value, this is nearly complete: purpose, merge behavior, and all parameter semantics are present. Minor gaps like error behavior or effect on existing tasks are not severe enough to drop below 4.

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

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

Schema description coverage is 0%, and the description compensates by explaining all three parameters: connections gets a semantic definition plus examples, download_dir requires a full path, and proxy_enabled maps to a boolean. It could add constraints or default/null handling, but it adds meaningful value beyond the raw schema.

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

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

States a specific verb and resource ('Update Gopeed configuration') and adds the key partial-update qualifier 'only provide fields to change.' This clearly separates update_config from its read-only sibling get_config and from task-management siblings.

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

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

The opening sentence gives direct context: use this when you need to modify Gopeed configuration. The 'only provide fields to change' instruction also tells the agent how to scope arguments. It does not name alternatives explicitly, but get_config is naturally distinguished as the read counterpart and task tools operate on a different resource.

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