Code Refactor

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. It usefully discloses what is inspected and reported (backend type, model name, key validation), but is silent on whether the check performs a live network/API call, possible latency or failure modes, and how an unavailable result should be interpreted.

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

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

Two sentences, zero waste: the first front-loads what is checked and returned, the second front-loads the calling guideline. 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 simple, no-argument health-check with no output schema, the description compensates by naming the three returned fields and the availability signal. It stops short of describing error/unavailable states or how to act on them, which is the only remaining gap.

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

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

The tool takes zero parameters (schema coverage 100%, empty object), so there is no parameter semantics to explain; the baseline of 4 applies. The description correctly adds no redundant parameter talk.

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: checking availability of the refactoring service and the DeepSeek cloud model, plus the returned fields (backend type, model name, key validation status). It is unmistakably distinct from the sibling refactor_code, which performs the actual refactoring rather than checking readiness.

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 routes the agent: 'suggest calling this tool before calling refactor_code.' The sibling is named and the condition that selects this tool (pre-flight precondition) is stated, leaving nothing to inference for a zero-parameter status check.

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

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

With no annotations, the description carries the full burden and it does deliver real behavioral content: the behavior-preservation guarantee and the disclosure that it injects Chinese comments and type annotations into the code. However, it is silent on the things an agent most needs — whether refactored code is returned as text or written to files, whether changes are reversible, size/length limits, and any auth requirements. That is a meaningful gap for a mutation-style tool.

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

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

Two tight sentences, front-loaded with the core action and the behavior-preservation contract before the transformation list and language scope. No filler, no repetition of the title.

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

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

For a code-transformation tool with zero annotations and no output schema, the definition covers input expectations well but leaves the return contract entirely unstated — the agent cannot tell whether it receives refactored source, a diff, or a file write. Adequate but with a clear, load-bearing gap.

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

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

Schema description coverage is 100%, so the baseline is 3 and the schema already explains 'code', 'task' (with an example prompt), and 'language' (including the auto-detect convention). The description's language list loosely reinforces the 'language' parameter but adds no syntax, format, or constraint detail 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?

States a specific verb+resource (refactor legacy code into modern idiomatic code) plus the invariant contract ('行为保持不变') and the exact set of transformations performed. The supported-language list further bounds scope, so an agent knows precisely what this tool does without opening the schema. The only sibling, check_status, is unrelated, so no sibling differentiation is needed or possible.

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?

Applicability is only implied through '适用于 Python / JavaScript / ...' — it tells the agent which inputs qualify but not when to prefer refactoring over, say, generating code fresh, nor any exclusions or prerequisites. With no comparable sibling there is no alternative to route to, but the description still never says when this tool is the right call.

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