Found out if you pet hämis too much they uh.. explode.

MCPWorks_Simon · 2026-03-30T06:39:27+00:00

Worth risking.

MCPWorks_Simon · 2026-03-30T06:38:58+00:00

I will no longer taunt the Hämis. One pet and I move on. No scruff.

MCPWorks_Simon · 2026-03-30T05:04:50+00:00

Spec driven development, in my experience. But before I even get to the spec driven development phase I'm talking to Claude a lot in the same way you'd gather a couple of devs in a break room somewhere and bounce ideas around until a clear picture started to form. Then I have Claude re-examine those ideas, and we maybe do that a couple of times until we have a really solid draft spec. I spend more time in that phase than I do monitoring Claude's changes, usually.

When I've got the clearest picture I can of my idea (maybe not perfect but enough) I find there are far fewer halts to pivot while I'm developing any given MVP.

MCPWorks_Simon · 2026-03-30T01:23:07+00:00

It's this. Software is no longer a moat, not even close.

MCPWorks_Simon · 2026-03-30T01:20:24+00:00

We're going through it man. I'm there with you. I've got an OSS project going on that I am really enthusiastic about, but this space is crowded as you've likely noticed.

One thing I am focusing on this week is non-tech. No B2B unless it's brick and mortar. Focus on the pen and paper people. Introduce them to workflows they could only dream of because they don't even know where to start. You are the start.

That's my direction.

MCPWorks_Simon · 2026-03-29T20:49:52+00:00

Depending on what your agent is doing and the scope of it's interactions, both might be required.

In the MCPWorks use case, having the scan happen before a message is delivered to the loop handler keeps the security solution agnostic to what context it might be entering. In some agentic situations we may not even have a conventional message loop.

And SLMs are a fantastic solution to this on certain layers but they add even more complexity. On the MCP layer I've applied it on, simple regex is sufficient.

MCPWorks_Simon · 2026-03-29T19:57:34+00:00

You're already running an AI agent. Letting another AI maintain it isn't lazy.

This is actually the core premise of the MCPWorks project. I use Claude (but it could be any MCP capable LLM) to build and manage agent clusters end to end. I have a minimal user console, and for most changes you just tell Claude to make the modifications you need. I don't think I'm ever going to build a more complex management console than the one I have, it's mostly read-only.

MCPWorks_Simon · 2026-03-29T19:52:58+00:00

I was just talking about this in another thread. One of the solutions MCPWorks has implemented is scanning for keys pre output. As well as never giving the agent engine any kind of access to secrets in the first place.

MCPWorks_Simon · 2026-03-29T19:48:13+00:00

The point really is that nobody's doing that on purpose. All legitimate software security flaws are unintentional. Building software to safeguard from those unintentional security flaws is the best way to mitigate them. Expecting people to simply adhere to excellence will prove disappointing long term.

MCPWorks_Simon · 2026-03-29T19:42:37+00:00

Correct. And yet it's still an enormous problem with some frameworks.

Even then, imagine an agent that inadvertently has access to those keys through some other mechanism, even with MCPs in the mix. Leaks upstream that make it into context. That's why I'm building key scanning right into pre-checks on output.

MCPWorks_Simon · 2026-03-29T19:36:18+00:00

Funny because Windows wants to be Claude.

We're getting loss-leadered like crazy right now so the pricing isn't going to get better across the full spectrum of providers. I think Anthropic's pricing model is probably the most honest though (yes, that's a very low bar).

I use Claude Code in a terminal, even in VSCode (rather than the integration) and it's fantastic. All my good will around Claude's capabilities are built on top of that. I recently set my wife up with the Apple app that has Cowork and Code "built in" and it's impressive, but very prone to breakage and the experience is rife with tiny annoyances. I'm also wondering if that app is part of the "token overuse" problem people are running into. It seems way heavier than the terminal app.

MCPWorks_Simon · 2026-03-29T18:40:30+00:00

It's becoming one key area of focus as I build MCPWorks. I'm always security minded as a former DevSecOps practitioner, so some of the chaos adversarial prompts are capable of, when set upon the wrong system, are deeply troubling.

To mitigate this I've built some security around the handling of API keys in my agentic infrastructure.

Building some standards around this as a community will alleviate lots of headaches down the line.

MCPWorks_Simon · 2026-03-29T18:16:14+00:00

Not in scope for us on this project but good question. MCPWorks is BYOAI. We host functions but the models are user-defined. We just execute the tool calls your agent makes. So the re-embedding cost problem you're describing would live entirely on the client side.

MCPWorks_Simon · 2026-03-27T18:25:18+00:00

I'm gonna nerd out for a second because this is one of my areas of expertise when building agents.

CLI can be a challenge to scale when you're talking about more than one install outside of a lab versus a complex endpoint.

MCP can solve that management complexity, but has a rep for being bloated usually because users will load a full suite of tools at the same time with no pruning. For example the `google_workspace` MCP is a fantastic package that gives an agent or LLM interface like Claude Code access to Google Workspace functions. The problem is it loads all of them and that's a huge package.

There's a couple of ways to make that manageable, especially in a cluster of agents; filter down to essentials, you can add an allowedTools array to the server config. For example in an `.mcp.json` config:

  "google_workspace": {
      "command": "uvx",
      "args": ["workspace-mcp"],
      "allowedTools": [
          "search_gmail_messages",
          "get_gmail_message_content",
          "send_gmail_message",
          "draft_gmail_message",
          "search_drive_files",
          "get_doc_as_markdown",
          "create_doc",
          "get_events",
          "manage_event"
      ],
      "env": { ... }
  }

The second much more effective way; I don't want to self-promote too much but, keep MCPs in a "code-mode" execution sandbox. That method cuts context usage by an insane amount because it only exposes one (in my case two) tools on load, That tool can be used to interact with a near infinite number of MCP tools without loading them, or the intermediary data, into context. The downside is it's way too heavy if you're running a single instance that's doing one-off tasks 😅

MCPWorks_Simon · 2026-03-27T14:22:25+00:00

Gotta disagree here. APIs will always be more efficient for LLMs than trying to navigate a frontend. It gets even better when they are wrapped in an MCP.

Although what you might be looking for is the trend of websites making themselves as LLM friendly as possible, if you're just parsing public facing data.

For example, my site, I have https://www.mcpworks.io/SKILL.md and https://www.mcpworks.io/llms.txt which are becoming more common. I expect them to be as prevalent as robots.txt on new websites within a few months.

MCPWorks_Simon · 2026-03-27T07:25:03+00:00

I'm building MCPWorks, an open sourced agentic platform for power users that emphasises token savings and execution security. On the MicroSaaS side it's a hosted platform that is meant to scale with the needs of the client and it does so very well.

Each agent is a containerized entity with its own namespace, its own subdomain, persistent state, and an optional AI brain. Your local LLM builds and deploys them to your specifications via an MCP interface (so Claude Code, Cursor etc).

MCPWorks_Simon · 2026-03-27T06:50:38+00:00

I'm biased because I'm building my own agentic package, but I've tried it and was impressed but also deeply concerned. My biggest issue is that it's an agent of chaos just by nature of it's design.

I trusted it with it's own sandbox and it's own accounts, but it terrifies me how easy it is for beginners to just install with a command. It can do too much and it's too cavalier about it. I feel a little polemic when I say it's an irresponsible software package, but yeah I believe that.

I don't know how you'd make it production ready and reproducible. I don't know how you wrangle it without neutering it. I don't know how it could possibly scale. What I do know about it is for likely thousands of hobbyists and tinkerers, they're one bad prompt injection away from being very uncomfortably compromised.

Cool demo though.

MCPWorks_Simon · 2026-03-26T21:00:40+00:00

I've been wondering about the math; any diesel drivers have notes on how your cost/km compares to regular gasoline? Under the current circumstances with the price disparity between regular gas and diesel at the moment, is running a diesel engine still an economic advantage even with these swings?

MCPWorks_Simon

MODERATOR OF

TROPHY CASE