1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@tactus vibrate device 1 at 0.8 intensity" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

tactus

by ProjectAILiberation

Overview Schema Related Servers Score Discussions

TypeScript

Local

Tactus

License: Apache-2.0

A content-agnostic MCP server that lets any AI agent control intimate hardware through a clean, safe tool interface.

Tactus is a thin, neutral control layer. It wraps Buttplug / Intiface — so a single integration reaches 750+ devices across ~26 brands — and exposes them to AI agents as Model Context Protocol (MCP) tools. It forwards hardware control commands only. It does not generate, host, or store any content of any kind.

Safety first. Intensity clamping, an independent watchdog auto-stop, a one-call emergency stop, and fail-safe stop semantics are built in and on by default — this is the headline feature, not an afterthought.
One-line install. npx -y tactus-mcp, no clone or build.
OS-agnostic. Tactus never touches Bluetooth. Intiface owns the radio; we just talk to it over a local WebSocket.

⚠️ Adults only (18+, or the age of majority in your jurisdiction). For use only on devices you own and only with the consent of everyone involved.

How it works

  AI client / agent           Tactus (this server)            Intiface Central
  (Claude Desktop,    MCP      - MCP server          WebSocket - holds BLE/USB
   Claude Code, your  ───────▶ - Buttplug client     ────────▶   - 750+ device
   own AI product)            - SAFETY LAYER          :12345      protocols
                                                                     │ BLE/USB
                                                                     ▼
                                                                🔵 your device

Everything runs locally on your machine. Tactus is a Buttplug client that connects to a locally running Intiface Central/Engine at ws://127.0.0.1:12345.

Related MCP server: mcp-devtools

Prerequisites

Install Intiface Central.
Open it and click Start Server.
Pair your device (or, for development, add a simulated device under Devices → Manage Simulated Devices).

Install & configure

Tactus runs over stdio via npx. Add it to your MCP client config.

Claude Desktop / Claude Code (claude_desktop_config.json):

{
  "mcpServers": {
    "tactus": {
      "command": "npx",
      "args": ["-y", "tactus-mcp"],
      "env": { "MAX_INTENSITY": "1.0" }
    }
  }
}

The same command/args work for any MCP client that launches stdio servers (Cursor, Cline, Continue, etc.).

Tools

Tool	Purpose
`list_devices`	List connected devices and their actuators
`scan_for_devices`	Scan for and return newly found devices
`get_battery`	Read battery level (0.0–1.0)
`vibrate`	Set vibration intensity (0.0–1.0)
`oscillate`	Set oscillation intensity (0.0–1.0)
`rotate`	Set rotation speed and direction
`linear`	Move a stroker to a position over a duration
`vibrate_pattern`	Play a timed, interruptible vibration pattern
`stop_device`	Stop one device
`stop_all`	Emergency stop — halt every device immediately
`server_status`	Report connection status to Intiface

All intensities are normalized to 0.0–1.0. Every tool returns both structured data and human-readable text.

Safety

The safety layer wraps every driving command and is on by default:

Intensity clamp — requests are clamped to MAX_INTENSITY; the effective value is reported back, and out-of-range input is rejected with a clear error rather than silently coerced.
Watchdog auto-stop — any continuous drive auto-stops after MAX_CONTINUOUS_MS (default 10 minutes) unless refreshed by a new command. This is an independent timer, not a check-on-next-call.
Stop on disconnect/exit — if the AI client disconnects or the process is signalled, all devices stop. The watchdog is the hard backstop for hard kills.
Interruptible patterns — patterns are time-scheduled so a single call never blocks the server; any stop preempts them instantly.
Rate limiting — per-device command bursts are coalesced to protect BLE.
Fail-safe stop — if a stop cannot be confirmed, Tactus retries rather than optimistically reporting success.

Configuration

Variable	Default	Meaning
`INTIFACE_URL`	`ws://127.0.0.1:12345`	Intiface WebSocket address
`MAX_INTENSITY`	`1.0`	Clamp ceiling for drive intensity (0.0–1.0)
`MAX_CONTINUOUS_MS`	`600000`	Watchdog auto-stop window
`SCAN_DEFAULT_MS`	`5000`	Default scan duration
`--allow-unsafe`	off	Disables the intensity clamp (discouraged)

Troubleshooting

"Intiface is not reachable at ws://127.0.0.1:12345" Start Intiface Central and click Start Server (the top status should read "Engine running"). Tactus retries automatically with backoff, so once Intiface is up the tools start working without restarting your MCP client.

A device doesn't show up when scanning

Make sure it is powered on and awake (press a button to wake it), and not already connected to its own phone app — Bluetooth devices accept one host at a time, so close/disconnect the app first.
On macOS, Intiface needs Bluetooth permission: System Settings → Privacy & Security → Bluetooth → enable Intiface Central, then quit and reopen Intiface (the permission only takes effect after a restart).
Keep the device in range; out-of-range devices drop and disappear from list_devices.

My computer sees the device over Bluetooth, but Intiface/Tactus doesn't The device's advertised Bluetooth name isn't in Buttplug's supported device list (common for regional/rebranded SKUs). Support must be added upstream in Buttplug — Tactus deliberately adds no per-device code and does not reverse-engineer devices.

A command returns "Unknown device id" The device disconnected (e.g. out of range) and left the known set. Call scan_for_devices / list_devices to reconnect and get its current id.

Known limitations

Device coverage = whatever Buttplug supports. Devices not present in Buttplug's device configuration cannot be controlled until added upstream.
Silent link degradation is not actively detected. A dropped link that Intiface reports is handled (the device leaves list_devices and drive calls error clearly). But if a Bluetooth link degrades silently without Intiface noticing, commands may appear to succeed while the device is unresponsive — active liveness probing is not yet implemented.
Local only. This package controls devices on the same machine via a local Intiface. Internet/remote control is out of scope here.

Adding support for an unrecognized device

Using a device from a supported brand that doesn't show up? It often just advertises a Bluetooth name (or regional SKU) that Buttplug hasn't catalogued yet. Because Tactus wraps Buttplug, the fix belongs upstream in Buttplug, not here — and for a same-brand device it's usually just adding a name, with no reverse-engineering.

Find the device's advertised Bluetooth name (see Troubleshooting above).
In Intiface's user device configuration, add that name to the same brand's existing protocol and test whether it drives correctly.
If it works, contribute the name upstream to buttplugio/buttplug so everyone benefits — and/or open an "Unsupported device" issue here and we'll help.

If a device only works under a protocol it doesn't truly match — or needs a protocol Buttplug doesn't have — that would require reverse-engineering, which is out of scope (see CONTRIBUTING).

Trademarks

"Lovense", "We-Vibe", "Satisfyer", "Kiiroo", "Lelo", "The Handy", "Magic Motion", "Svakom", and other device names are trademarks of their respective owners. Tactus is an independent project and is not affiliated with, endorsed by, sponsored by, or partnered with any device manufacturer. It is described as compatible with these devices only in the factual sense that it builds on the open-source Buttplug protocol library. No manufacturer logos are used.

Content generation — out of scope

This server forwards hardware control commands only. It does not generate, synthesize, recommend, or produce any text, image, audio, or video content. The calling AI agent is the sole content-generating party and is solely responsible for any content it produces and for compliance with content obligations in its jurisdiction.

Acceptable use

Tactus is a neutral, content-agnostic hardware control layer. It does not support, document, or assist with: use on devices you do not own or lack consent to operate; use by or on minors; or any use violating applicable law in your jurisdiction. These statements describe the scope of maintainer support and documentation — they are not additional restrictions on the License, which continues to govern all use, modification, and redistribution. Users are independently responsible for evaluating their use against applicable law.

Tactus only uses device protocols already supported upstream by Buttplug. It does not reverse-engineer unsupported devices and does not break any device encryption or access control. It collects and transmits no personal or usage data.

Disclaimer

This software controls hardware you connect to it. Use it only on devices you own and only with the consent of everyone involved. For adults only (18+, or the age of majority in your jurisdiction).

This software is provided "AS IS", without warranty of any kind (see LICENSE). The statements above are informational; they do not modify the License, add warranties or duties of care, or transfer liability. The License's no-warranty and limitation-of-liability terms continue to apply in full.

License

Apache-2.0.

Available Tools

11 tools

get_batteryGet batteryB

Read battery level (0.0-1.0) for a device that reports it.

ParametersJSON Schema

Name	Required	Description	Default
`device_id`	Yes	Device id from list_devices

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so the description must carry the full burden. It states it reads battery level but does not disclose potential side effects, required permissions, rate limits, or behavior if the device does not report battery. This is minimal for a read operation.

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

Conciseness5/5

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

The description is a single sentence that front-loads the key information: read battery level with range and device condition. Every word adds value with no redundancy.

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

Completeness3/5

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

Given the simple tool with one parameter and no output schema, the description is minimally complete. It covers the basic function but misses details about return format, error handling (e.g., if device missing or no battery), and the fact that it is likely a fast read. It is adequate but not comprehensive.

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

Parameters3/5

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

The input schema has 100% coverage with a single parameter 'device_id' described as 'Device id from list_devices'. The description adds no additional meaning beyond the schema, so it meets the baseline but does not compensate further.

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

Purpose4/5

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

The description clearly states the verb 'Read' and the resource 'battery level' with the specific range (0.0-1.0). It distinguishes from sibling tools like 'vibrate' or 'rotate' by focusing on a read operation, but does not explicitly contrast with other read tools like 'server_status'.

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

Usage Guidelines3/5

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

The description implies usage context by noting 'for a device that reports it', indicating not all devices have battery. However, it provides no explicit guidance on when to use this tool versus alternatives, nor when not to use it.

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

linearLinear strokeC

[Hardware control] Forwards a command to physical hardware. Move a stroker to a position over a duration.

ParametersJSON Schema

Name	Required	Description
`position`	Yes	Target position, 0.0-1.0
`device_id`	Yes	Device id from list_devices
`duration_ms`	Yes	Time to reach the position, ms
`actuator_index`	No	Restrict to one actuator index; omit to drive all matching actuators

TDQS

C2.9/5.0

Behavior2/5

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

No annotations provided, and the description does not disclose side effects, safety profile, or whether the command is destructive or read-only. Minimal behavioral context beyond the basic action.

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

Conciseness4/5

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

The description is very short (two sentences) with no fluff, but it could be more informative without sacrificing conciseness. Slightly too terse.

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

Completeness3/5

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

Adequate for the basic action, but given the presence of sibling tools with similar motions and no output schema, more context on when to use linear vs oscillate/rotate would improve completeness.

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

Parameters3/5

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

Schema coverage is 100% with descriptions for all parameters, so the description adds no extra meaning. Baseline score of 3 is appropriate.

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

Purpose4/5

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

The description clearly states the tool moves a stroker to a position over a duration, using specific verbs and resource. However, it does not distinguish this from siblings like oscillate or rotate, which also involve movement.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives. The description lacks context on prerequisites, conflicts, or preferred scenarios.

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

list_devicesList devicesA

List currently connected devices and their actuators.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior3/5

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

No annotations provided, so the description must convey all behavioral traits. It states 'currently connected devices' suggesting a snapshot, but lacks details on caching, side effects, or refresh behavior.

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

Conciseness5/5

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

Single sentence, front-loaded with key information, no wasted words. Highly concise.

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

Completeness4/5

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

For a simple listing tool with no parameters, the description is adequate. It could hint at return format, but the agent can infer a list of devices and actuators.

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

Parameters4/5

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

There are no parameters, and the empty schema is fully documented. The description adds no parameter-specific meaning, but none is needed; baseline for 0 params is 4.

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

Purpose5/5

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

The description uses a specific verb 'List' and identifies the resource as 'currently connected devices and their actuators,' clearly distinguishing it from siblings like scan_for_devices and actuator control tools.

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

Usage Guidelines3/5

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

The description implies use for viewing current connections but gives no explicit guidance on when to use this tool versus alternatives or any exclusions.

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

oscillateOscillateB

[Hardware control] Forwards a command to physical hardware. Set oscillation intensity on a device.

ParametersJSON Schema

Name	Required	Description
`device_id`	Yes	Device id from list_devices
`intensity`	Yes	Oscillation intensity, 0.0-1.0
`actuator_index`	No	Restrict to one actuator index; omit to drive all matching actuators

TDQS

B3.1/5.0

Behavior2/5

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

No annotations provided, so the description carries the full burden. It mentions 'forwards a command to physical hardware' which implies a write/mutation, but lacks details on side effects, safety, or state changes.

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

Conciseness4/5

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

The description is short (two sentences) and front-loaded with a '[Hardware control]' tag, but it contains redundancy ('Forwards a command' and 'Set oscillation intensity' are essentially the same).

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

Completeness2/5

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

Given 3 parameters, no output schema, and sibling tools, the description is incomplete. It doesn't explain what oscillation does vs vibrate, or what the tool returns.

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

Parameters3/5

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

Schema coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema, such as clarifying the role of actuator_index.

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

Purpose5/5

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

The description clearly states the tool sets oscillation intensity on a device, using a specific verb ('set') and resource ('oscillation intensity on a device'). It distinguishes from sibling hardware control tools like vibrate, rotate, and linear.

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

Usage Guidelines2/5

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

No guidance on when to use this tool over siblings like vibrate or linear. No prerequisites mentioned, such as needing a device ID from list_devices.

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

rotateRotateB

[Hardware control] Forwards a command to physical hardware. Set rotation speed (and direction) on a device.

ParametersJSON Schema

Name	Required	Description
`speed`	Yes	Rotation speed, 0.0-1.0
`clockwise`	No	Direction; honored only if the device supports it
`device_id`	Yes	Device id from list_devices
`actuator_index`	No	Restrict to one actuator index; omit to drive all matching actuators

TDQS

B3.4/5.0

Behavior2/5

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

No annotations exist, and the description only states it forwards a command to hardware without disclosing side effects, safety implications, or impact on device state, which is insufficient for a hardware control tool.

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

Conciseness4/5

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

Two concise sentences, but the first sentence is redundant ('forwards a command to physical hardware') and could be removed to improve clarity.

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

Completeness3/5

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

Schema covers all parameters, but missing output schema and annotations; description lacks details on error handling, state changes, or prerequisites for a hardware operation.

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

Parameters3/5

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

The description adds minimal value beyond the 100% schema coverage; it repeats 'speed and direction' without deeper context like default behavior or interaction with actuator_index.

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

Purpose5/5

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

The description clearly identifies the tool as hardware control for rotation, specifying speed and direction, which distinguishes it from sibling tools like vibrate or oscillate.

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

Usage Guidelines3/5

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

The description implies use when rotating a device but lacks explicit guidance on when to use alternatives (e.g., oscillate for back-and-forth motion) or prerequisites like device connection.

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

scan_for_devicesScan for devicesB

Scan for new devices for a duration, then return any newly found.

ParametersJSON Schema

Name	Required	Description	Default
`duration_ms`	No

TDQS

B3.4/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. It mentions scanning for a duration and returning new devices, but lacks details on blocking behavior, empty results, or state changes.

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

Conciseness5/5

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

One clear sentence with no fluff, front-loading the action and result.

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

Completeness3/5

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

For a simple one-parameter tool without output schema, the description covers basic purpose and parameter usage, but lacks details on return format or behavior during scanning.

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

Parameters2/5

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

Schema has 0% parameter description coverage. The description mentions 'for a duration' linking to duration_ms, but does not specify units, default, or behavior. Parameter name is self-explanatory but description adds minimal value.

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

Purpose5/5

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

The description clearly states the tool scans for new devices over a duration and returns newly found ones. It distinguishes from sibling 'list_devices' which likely lists all known devices.

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

Usage Guidelines3/5

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

The description implies usage when wanting to discover new devices over time, but does not explicitly state when to use vs alternatives like 'list_devices' for current known devices.

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

server_statusServer statusA

Report connection status to Intiface and device count.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.5/5.0

Behavior3/5

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

The description implies a non-mutating read operation, which is correct. However, with no annotations, it does not explicitly state side effects, permissions, or response structure. It meets minimum standards but lacks detail.

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

Conciseness5/5

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

The description is a single sentence with no filler. It front-loads the verb 'Report' and immediately conveys the tool's function.

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

Completeness4/5

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

Given the tool has no parameters and no output schema, the description covers its core purpose adequately. It could mention that it is a safe, read-only check, but the sibling context makes this clear.

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

Parameters4/5

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

There are zero parameters, and the schema coverage is 100% trivially. Per guidelines, baseline is 4. The description adds nothing beyond the schema, but no additional info is needed.

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

Purpose4/5

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

The description clearly states the tool reports 'connection status to Intiface and device count', which is specific and distinguishes it from sibling tools that control devices or scan for them. However, it could be more precise about what 'status' entails (e.g., connected/disconnected).

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

Usage Guidelines2/5

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 like list_devices or scan_for_devices. Its purpose is implied but not explained in context of workflow.

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

stop_allStop all (emergency)A

Immediately stop every connected device. Emergency stop.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior3/5

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

With no annotations, the description bears the full burden. It states the immediate action but does not disclose potential side effects (e.g., devices may need manual restart) or any prerequisite conditions.

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

Conciseness5/5

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

The description is only two sentences, efficiently conveying the core purpose and usage context without any filler.

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

Completeness4/5

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

Given no parameters, no output schema, and no annotations, the description is mostly adequate. Additional detail about post-stop state or recovery could improve it, but for a simple emergency stop it is sufficient.

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

Parameters4/5

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

There are no parameters, so the description does not need to add parameter meaning. The schema is empty and coverage is 100%, which is acceptable.

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

Purpose5/5

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

The description clearly states 'Immediately stop every connected device' and the title includes 'Emergency', making the purpose unmistakable and distinguishing it from 'stop_device' for individual devices.

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

Usage Guidelines4/5

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

The description says 'Emergency stop', which implies when to use it. It does not explicitly say when not to use it, but the context makes it clear that this is for stopping all devices in urgent situations.

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

stop_deviceStop deviceA

Stop all actuators on one device.

ParametersJSON Schema

Name	Required	Description	Default
`device_id`	Yes	Device id from list_devices

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It only states the basic action without disclosing prerequisites, side effects, or error handling, leaving significant 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.

Conciseness5/5

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

The description is a single sentence with no wasted words, efficiently conveying the tool's purpose.

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

Completeness3/5

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 no output schema, the description is adequate but could benefit from mentioning device connectivity requirements or the scope of the stop action.

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

Parameters3/5

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

Schema description coverage is 100%, so baseline is 3. The tool description adds no additional meaning to the 'device_id' parameter beyond what the schema already provides.

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

Purpose5/5

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

The description clearly states the action ('Stop all actuators') on a single device, distinguishing it from the sibling tool 'stop_all' which targets multiple devices.

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

Usage Guidelines3/5

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

The description implies use for a specific device but does not explicitly guide when to use this tool versus alternatives like 'stop_all' or other actuator control tools.

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

vibrateVibrateB

[Hardware control] Forwards a command to physical hardware. Set vibration intensity on a device.

ParametersJSON Schema

Name	Required	Description
`device_id`	Yes	Device id from list_devices
`intensity`	Yes	Vibration intensity, 0.0-1.0
`actuator_index`	No	Restrict to one actuator index; omit to drive all matching actuators

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description must carry the burden. It states 'Forwards a command to physical hardware', implying interaction with hardware but lacks details on side effects, permissions needed, or potential damage. Minimal behavioral insight.

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

Conciseness4/5

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

Two short sentences conveying purpose without redundancy. The '[Hardware control]' prefix adds minimal value but does not detract. Could be slightly more streamlined.

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

Completeness2/5

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

Tool has three parameters and no output schema, yet the description omits return behavior, error conditions, or hardware constraints. Given complexity, more context (e.g., that intensity is relative, or what happens on invalid device) is needed.

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

Parameters3/5

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

Schema description coverage is 100%, so parameters are already documented. The description adds 'Set vibration intensity', aligning with the intensity parameter, but does not clarify the 'actuator_index' parameter beyond the schema.

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

Purpose5/5

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

The description states a specific verb ('Set') and resource ('vibration intensity on a device'), clearly identifying the tool's function. It distinguishes from sibling tools like 'oscillate', 'rotate', and 'vibrate_pattern' by focusing on intensity setting.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives such as 'oscillate', 'rotate', or 'vibrate_pattern'. There are no exclusions or context about prerequisites (e.g., device must be connected).

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

vibrate_patternVibrate patternC

[Hardware control] Forwards a command to physical hardware. Play a timed multi-step vibration pattern; interruptible by any stop.

ParametersJSON Schema

Name	Required	Description
`steps`	Yes
`repeat`	No
`device_id`	Yes	Device id from list_devices
`actuator_index`	No	Restrict to one actuator index; omit to drive all matching actuators

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description must fully disclose behavior. It mentions forward to hardware, play pattern, and interruptibility, but omits side effects (e.g., immediate haptic feedback), idempotency, required permissions, or device state prerequisites.

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

Conciseness4/5

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

The description is efficient at two sentences, front-loading the action and hardware control context. It earns its place, though it could be structured with bullet points for readability.

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

Completeness2/5

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

Given 4 parameters (2 required), no output schema, and hardware control, the description lacks details on repeat behavior (default?), actuator_index omission effects, and return values. The agent may misuse if not informed about these aspects.

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

Parameters2/5

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

Schema description coverage is 50% (descriptions for device_id and steps only). The description adds no meaning beyond 'play a timed multi-step vibration pattern' and does not clarify repeat behavior, actuator_index usage, or intensity range validation.

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

Purpose5/5

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

The description clearly states the tool plays a timed multi-step vibration pattern on physical hardware. It distinguishes itself from siblings (e.g., vibrate, oscillate) by specifying 'multi-step' and 'interruptible by any stop'.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives like vibrate (likely single-step) or other motion tools. No prerequisites or explicit when/when-not conditions are mentioned.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

11 tool updatesv0.1.2Jul 30, 2026
- First observedget_battery
- First observedlinear
- First observedlist_devices
- First observedoscillate
- First observedrotate
- First observedscan_for_devices
- First observedserver_status
- First observedstop_all
- First observedstop_device
- First observedvibrate
- First observedvibrate_pattern

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation5/5

Each tool targets a distinct action: device management (list, scan, status, battery), stopping (single/all), and various actuation commands (vibrate, oscillate, rotate, linear, pattern). No two tools appear to do the same thing.

Naming Consistency5/5

Tools follow a clear pattern: verb_noun for management (list_devices, stop_device, stop_all) and single verbs for actuation (vibrate, oscillate, rotate, linear). Consistent and predictable.

Tool Count5/5

11 tools is well-scoped for a hardware control server. It covers discovery, status, battery, individual stop, multiple actuation types, pattern playback, and emergency stop without unnecessary redundancy.

Completeness5/5

The tool surface covers all expected operations: device detection (list, scan), status monitoring, battery reading, individual stop, various actuation commands, pattern control, and global stop. No obvious gaps for the domain.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

mcp-serverOAuth
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2
strata
ai.klavis
MCP server for progressive tool usage at any scale (see https://klavis.ai)
Agent Orchestration Autonomous Agents Developer Tools
25,748
Remote Desktop CommanderOAuth
app.desktopcommander
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Shell Access OS Automation
214
AI.TV MCP ServerOAuth
tv.ai
Remote MCP server for AI.TV creators — delegate account operations to your AI agent over MCP.
Entertainment & Media AI & Machine Learning
2

Related MCP Servers

sql-query-mcp
Databases Developer Tools
andyWang1688
A
license
A
quality
C
maintenance
A general-purpose MCP server that lets AI work with multiple databases within clear boundaries.
Updated 2 months ago (2026-06-26 07:20 UTC)
13
6
MIT
mcp-devtools
Databases Developer Tools File Systems
marin1321
A
license
B
quality
D
maintenance
Production-grade MCP server that gives AI agents safe access to your local dev environment: filesystem, databases, processes, and OpenAPI specs.
Updated 2 months ago (2026-07-01 18:47 UTC)
15
67
3
MIT
Forage MCP Server
Autonomous Agents Developer Tools
isaac-levine
A
license
Not graded
quality
D
maintenance
An MCP server that enables AI agents to automatically discover, install, and learn to use new tools without manual configuration.
Updated 7 months ago (2026-02-21 23:02 UTC)
52
16
MIT
better-mcp
File Systems Databases Shell Access
erquier
F
license
A
quality
B
maintenance
A universal MCP server that provides AI agents with structured tools for filesystem, database, shell, and git operations, enabling seamless interaction with projects.
Updated 4 days ago (2026-09-02 19:14 UTC)
19
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ProjectAILiberation/tactus'

If you have feedback or need assistance with the MCP directory API, please join our Discord server