fix up for latest go-buttplug and intiface central

[diamondburned]

this PR consists of 2 commits:

• fix up for go-buttplug v0.0.8 changes (also meant that i rewrote a lot of the code, sorry!)
• add --no-resources for opencode/crush

Important

You need GOEXPERIMENT=jsonv2 to build this until Go 1.26 is released and encoding/json/v2 is officially added. This is an upstream decision coming from go-buttplug. Sorry!

test result with Intiface Central 2.6.7+33 and the opencode MCP config below:

opencode.json

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "buttplug-mcp": {
      "type": "local",
      "command": [
        "./bin/buttplug-mcp", "--ws-port", "12345", "--ws-host", "<REDACTED>", "--no-resources"
      ]
    }
  }
}

have fun!! ❤️

P/S: next version of go-buttplug that uses schema v4 should be way easier to use. right now that's still in Intiface beta, so i don't want to push for it yet.

[diamondburned]

ssorry, converting this to a draft for now until i made sure that the controller stops when it needs to stop.

[neomantra]

Thanks for these contributions! I appreciate you are advancing go-buttplug and keeping track with the upstream activity. I thought I might need to go to Rust for that.

With respect to —no-resource… I originally made this when MCP was new, in its March 2025 upswing. It seems that most of MCP-land has ignored the prompt/resource aspect and leaned on the tool calling. Most things that can be resources are accessed via tool calls. (That probably has some feedback loop where the models are better at tool calling than resource calling.)

It’s beyond the scope of the PR but I have found tool description to be the most critical aspect of the MCP server.

Perhaps it is better to have solely tool-based access … then focus on tool descriptions and more high-level tools.

[diamondburned]

Perhaps it is better to have solely tool-based access … then focus on tool descriptions and more high-level tools.

i'm fine with that! i was originally hesitant since crush, the app that i originally use, kept asking for permission to use tools, but it seems like opencode just uses them without asking, which is great!

[diamondburned]

actually, a fun idea would be to allow custom overriding of the tool descriptions to better suggest how the agent should use them. as far as high-level tools go, i also had the idea of making a simple expression language to describe vibration patterns that the agent can use to generate.

[diamondburned]

pattern works!

opencode doesn't display the actual pattern array, which mmm is not ideal? the patterns definitely work (i can feel it), but maybe i should make it a string instead, something like:

0.5+0.2s; 0.0+0.2s; 0.5+0.2s; 0.0+2s

this looks easy enough to read.

[diamondburned]

this is great, actually!

(i swear it only took me a day to implement this, i got really sidetracked)