I think I found a better way of letting agents control software than MCPs or computer use screen automations.
Most desktop software come with a prebuilt, well-documented scripting layer: Photoshop has Extendscript, Excel has VBA, Blender has Python etc. These are like very mature and battle-tested APIs. They are often huge. To interact with them, we can make use of low-level, OS-wide communication protocols - COM on windows or AppleScript for Mac. With these two layers already readily available, agents don’t need MCP servers, schema definitions or screen vision to control most apps. They can just communicate with the software’s internal automation runtime.
I built a set of small bridges that allow agents to communicate with software this way. It is simple: the agent writes a script, a shell command sends it to the app, the app's scripting runtime runs it, JSON comes back.
This, admittedly, isn’t perfect. I’ve seen agents go off on long tangents trying to perform simple operations. But most of the time, if the request is specific and bounded, it works better than most software MCP integrations I’ve tried (Claude’s flaky integration into creative software from last week included), with no setup.
This seems like a semi-universal pattern. I’ve set-up adapters for 14 applications. I’m not a CAD user, but I’m sure this can work for AutoCAD or Fusion, or for Keyshot or Vray for renders. It lets you bypass the complex GUI for practically all desktop software.
It is also worth mentioning the obvious: performance varies with both model and harness. From my tests, Codex seems to handle this better than Claude code, and Cursor better than Codex (in a sense, this framework makes any “legacy” software a kind of Cursor); GLM 5 better than Deekseek v4 and Kimi 2.6.
I’ve wrapped this in a pip, which installs the tiny bridges and informs agents of this library as a skill.
That's certainly an interesting and novel take. Did you benchmark how "good" it performs against something that has an MCP? Btw I didn't know local apps have MCPs?
Yes, local apps have MCPs. They're usually a pain to set up.
I didn't benchmark against MCPs. I might do that, but there are lots of variables at play - which software, which MCP, which model and which harness.
I think I found a better way of letting agents control software than MCPs or computer use screen automations.
Most desktop software come with a prebuilt, well-documented scripting layer: Photoshop has Extendscript, Excel has VBA, Blender has Python etc. These are like very mature and battle-tested APIs. They are often huge. To interact with them, we can make use of low-level, OS-wide communication protocols - COM on windows or AppleScript for Mac. With these two layers already readily available, agents don’t need MCP servers, schema definitions or screen vision to control most apps. They can just communicate with the software’s internal automation runtime.
I built a set of small bridges that allow agents to communicate with software this way. It is simple: the agent writes a script, a shell command sends it to the app, the app's scripting runtime runs it, JSON comes back.
This, admittedly, isn’t perfect. I’ve seen agents go off on long tangents trying to perform simple operations. But most of the time, if the request is specific and bounded, it works better than most software MCP integrations I’ve tried (Claude’s flaky integration into creative software from last week included), with no setup.
This seems like a semi-universal pattern. I’ve set-up adapters for 14 applications. I’m not a CAD user, but I’m sure this can work for AutoCAD or Fusion, or for Keyshot or Vray for renders. It lets you bypass the complex GUI for practically all desktop software.
It is also worth mentioning the obvious: performance varies with both model and harness. From my tests, Codex seems to handle this better than Claude code, and Cursor better than Codex (in a sense, this framework makes any “legacy” software a kind of Cursor); GLM 5 better than Deekseek v4 and Kimi 2.6.
I’ve wrapped this in a pip, which installs the tiny bridges and informs agents of this library as a skill.
That's certainly an interesting and novel take. Did you benchmark how "good" it performs against something that has an MCP? Btw I didn't know local apps have MCPs?
Yes, local apps have MCPs. They're usually a pain to set up. I didn't benchmark against MCPs. I might do that, but there are lots of variables at play - which software, which MCP, which model and which harness.