Send a kernel interrupt to the active execution to stop running Python code. Use it to halt a long-running task; the execution updates to interrupted or error once the kernel is idle.
向当前正在运行的 execution 发送 kernel 中断信号。
该工具只作用于当前 running 记录。信号已发送不等同于记录已终态：
kernel 到达 IOPub idle 后，记录才会报告 interrupted、
error 或其他最终状态。kernel 空闲时返回 idle。
Returns:
已发送信号时返回目标 execution；kernel 空闲时返回 idle。
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.13Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for transparency. It explains the interrupt semantics, including that sending the signal does not immediately finalize the record, and describes the return behavior in different states. This gives a complete picture of the tool's 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 concise and well-structured, starting with the primary action and then providing semantic details. It is not overly verbose and conveys necessary information efficiently.
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 and lack of output schema, the description is sufficiently complete. It covers the action, side effects, and return values. No critical information appears to be missing for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so there is nothing to explain. According to the rubric, a baseline of 4 is appropriate for zero parameters, and the description does not need to add any parameter-related 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 description clearly states the tool's action: sending a kernel interrupt signal to the currently running execution. It also explains the intended effect, leaving no ambiguity about 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 provides guidance by specifying that the tool only affects the current running record. This implies it should be used when there is an active execution, and it clarifies the expected behavior when the kernel is idle, helping the agent decide when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.