How "useful" a particular MCP is depends a lot on the quality of the MCP but i've been slowly testing the waters with GitHub MCP and Home Assistant MCP.
GH was more of a "go fix issue #10" type deal where I had spent the better part of a dog-walk dictating the problem, edge cases that I could think of and what a solution would probably entail.
Because I have robust lint and test on that repo, the first proposed solution was correct.
The HomeAssistant MCP server leaves a lot to be desired; next to no write support so it's not possible to have _just_ the LLM produce automations or even just assist with basic organization or dashboard creation based on instructions.
I was looking at Ghidra MCP but - apparently - plugins to Ghidra must be compiled _for that version of ghidra_ and I was not in the mood to set up a ghidra dev environment... but I was able to get _fantastic_ results just pasting some pseudo code into GPT and asking "what does this do given that iVar1 is ..." and I got back a summary that was correct. I then asked "given $aboveAnalysis, what bytes would I need to put into $theBuffer to exploit $theorizedIssueInAboveAnalysis" and got back the right answer _and_ a PoC python script. If I didn't have to manually copy/paste so much info back and forth, I probably would have been blown away with ghidra/mcp.
"Please find 3 fencing clubs in South London, find out which offer training sessions tomorrow, then add those sessions to my Calendar."
That kicked off a maps MCP, a web-research MCP and my calendar MCP. Pretty neat honestly.
This totally reads to me like you're prompting an LLM instead of talking to a person
Chatgpt asks for a host for the mcp server.
All the MCPS I find give a config like
```{ "mcpServers": { "sequential-thinking": { "command": "npx", "args": [ "-y", "@modelcontextprotocol/server-sequential-thinking" ] } } }```
It feels like wizardry a little to me.
You can check out our super rough version here, been building it for the past two weeks: gateway.aci.dev
What I was talking about here is different though. My agent (Smith) has an inversion of control architecture where rather than running as a process on a system and directly calling tools on that system, it emits intents to a queue, and an executor service that watches that queue and analyzes those intents, validates them, schedules them and emits results back to an async queue the agent is watching. This is more secure and easier to scale. This architecture could be built out to support safe multiple agents simultaneously driving your desktop pretty easily (from a conceptual standpoint, it's a lot of work to make it robust). I would be totally down to collaborate with someone on how they could build a system like this on top of my architecture.
Very interesting! What kind of use cases are you using your agent (Smith) for? Is it primarily coding, or quite varied across the board?
The agent itself is designed to be very general, every trace action has hooks that can transform the payload using custom javascript, so you can totally change the agent's behavior dynamically, and the system prompts are all composed from handlebars templates that you can mix/match. The security model makes it great for enterprise deployment because instead of installing agent software on systems or giving agents limited shell access to hosts, you install a small secure binary that basically never changes on hosts, and a single orchestrator service can be a control plane for your entire enterprise. Then every action your agent takes is linked into the same reactive distributed system, so you can trigger other actions based on it besides just fulfillment of intent.
If yes, drop me a line, here or at manuel@kiessling.net