set_vibrationSets vibration intensity on supported devices and keeps it running until stopped; nonzero levels need confirm=true, and TF-PTPRO must first switch to vibration mode with its physical button.
设置支持设备的震动强度并持续运行，直到调用 stop_vibration 或 stop_device；TF-PTPRO 使用前须通过设备实体键切换到震动模式。非零值必须 confirm=true。
| Name | Required | Description | Default |
|---|---|---|---|
| level | Yes | ||
| confirm | No |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.2.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden and discloses important behavior: the vibration persists until an explicit stop call, TF-PTPRO needs a manual mode switch, and non-zero levels require confirmation. It does not state what level=0 means, supported-device limits, or failure behavior, leaving some behavioral gaps.
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 primary action and continuous-run behavior come first, followed by the device-specific prerequisite and confirmation constraint. Every clause carries operational meaning with no 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 two-parameter mutation tool with no annotations, the description covers the essential call conditions: persistence until stop, TF-PTPRO mode prerequisite, and confirm=true for non-zero levels. It is mostly complete, though missing level range and zero-value semantics could still lead to incorrect 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 0%, so the description must compensate. It clarifies that level represents vibration intensity and that non-zero values require confirm=true, but it omits the valid range for level, whether zero stops vibration, and any unit or default semantics for confirm beyond the default in 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 and resource: set vibration intensity on supported devices and keep it running continuously until stop_vibration or stop_device is called. It distinguishes the operation from sibling stop tools and waveform/suction/rotation controls by naming the exact resource and termination 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 clear operational context: continuous vibration until stop_vibration or stop_device, a device-specific prerequisite for TF-PTPRO requiring a physical button mode switch, and a confirm=true requirement for non-zero values. It does not explicitly compare against unrelated siblings like set_suction or set_rotary, but the usage conditions are sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.