Skip to main content
Glama
gxxHuang
by gxxHuang

Retry Task

retry_task

Retry a failed or stalled task using its task ID to recover iKuai router operations without restarting the entire workflow.

Instructions

重试任务

Input Schema

NameRequiredDescriptionDefault
task_idYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.0.1

TDQS

D1.3/5.0
Behavior1/5

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

No annotations are provided, so the description carries the full behavioral burden, and it discloses nothing: not whether retry is idempotent, whether it resets progress or state, whether the target task must be in a failed state, whether retries are rate-limited, nor what happens to concurrent task output.

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

Conciseness2/5

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

It is only four characters, but brevity here is under-specification rather than conciseness. There is no front-loaded useful content because there is no content at all.

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

Completeness1/5

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

For a state-mutating task tool with no annotations, an undocumented parameter, and no usage guidance, the description is entirely inadequate. The existing output schema removes the need to explain return values, but nothing else an agent needs in order to call this correctly is present.

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

Parameters1/5

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

The single required parameter task_id has 0% schema description coverage, and the description supplies no compensating meaning — no format, no source (e.g., from list_tasks), no constraints. The description does nothing to explain what a valid task_id is.

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

Purpose2/5

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

The description '重试任务' is a verbatim Chinese restatement of the tool name/title 'retry_task', adding no scope, no target clarification, and no distinction from siblings like abort_task or list_tasks. It does technically convey 'retry a task', but that is tautological rather than informative.

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

Usage Guidelines1/5

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

No guidance whatsoever on when to invoke this tool. With siblings list_tasks and abort_task present, the agent is never told which task states are retryable, whether this applies to failed tasks only, or how it differs from abort_task.

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

Deploy Server

Other Tools