From the Backlog to the Build Log

Remote MCP Servers and a Commit Button: October 2 - October 8, 2026

What I Worked On

This week DevNitro learned to connect to remote MCP servers, and the AI never sees the key or token that unlocks them. A remote MCP server is one you reach over the web instead of running on your own machine, and most of them want an API key or an OAuth sign-in. Before this, I ran remote servers through npx. I didn't want a key or token sitting in a config file or passing through a model's context. So the secret stays with Lobast, the credential broker DevNitro already uses for browser logins, and DevNitro only talks to Lobast. That is how Intelligent Engineering should handle a rule like this. It lives in the system, so nobody has to remember it.

The rest of the week went to the tools around that work. Copilot's commit messages ran out on me Tuesday, so I built my own Generate Commit Message button into the DevNitro Visual Studio extension. The native terminal UI from last week's autonomous run passed my testing, and the rest of that run deleted the old terminal code. And Thursday night Visual Studio itself fought me for about an hour.

What the AI Did Well

The remote MCP work ran across two repos. On the Lobast side, the broker now opens a session for each remote server, adds the credential to requests on the way out, and runs the OAuth sign-in itself. On the DevNitro side, a new mcp_setup tool probes a server's URL, reports whether it needs no auth, a key, or OAuth, and then writes the config. A /mcp command walks through the same steps. If a config file has a literal Authorization header in it, DevNitro rejects it and points you to lobast_setup instead. All 670 Lobast broker tests and the DevNitro MCP and Lobast tests passed before I merged.

Updating the Visual Studio extension was past due. And it took up most of Tuesday. The commit button addition was reason enough for me to get back in there and do the work I had been putting off. Regarding the commit button itself, the newer Visual Studio extension model runs out of process, so I can't put a button inside the Git Changes window. I didn't want to bring in .NET Framework, so I'm living with that limit. DevNitro gets its own toolbar button and a hot key instead. It reads the pending changes, writes a message, and fills in the Git Changes box. By Tuesday night I was using it to commit the Lobast and DevNitro code it had helped write. I also updated DevNitro so you can pick which model and effort level writes the commit messages.

Monday I saw a reply vanish in the native CLI. I asked DevNitro to determine the issue. Instead of patching around the issue, we simplified the chat history and crash recovery code. Then I kicked off the rest of the autonomous run, and it removed Terminal.Gui and the other old console library. I've found myself having more conversations straight in the CLI than through the listener and web UI, which tells me the CLI is working well.

What Needed Correction

The agent that helped me write the remote MCP requirements had suggested Lobast save OAuth tokens in an encrypted table. I don't want Lobast storing any credentials right now, so I changed it. Tokens now live only in the broker's memory and get cleared when they rotate, when you revoke them, and when the broker shuts down. After a restart you sign in again. That costs a click now and then, and there is no token file for anyone to steal.

Monday morning the GlobalCove Technologies Framework failed its Semgrep check when I went to pack it. I made the SQL interpolation analyzer stricter and fixed what it found. Part of verification is making sure the verification tools do their job. If you can't trust them, the AI can do a lot of real work that isn't valid work by your team's standards. Good software requires more than just tests passing.

The hardest part of the extension was getting the Visual Studio Experimental instance to load my dev build instead of the production version I had installed. When I was working with it before I didn't have the issue, but this time around it would only load the production version. Thursday night, after more testing there, my main Visual Studio lost its Build and Test menus and Test Explorer's buttons went dead. My first guess was the extension. DevNitro read the extension code and Visual Studio's activity log and showed that the extension never touched anything outside its own button. devenv /updateconfiguration brought the menus back, and devenv /resetsettings fixed Test Explorer. I'm still skeptical, because it didn't happen until I ran Generate Commit Message with a folder open instead of a solution. I'll keep testing and see if it was a one-time thing.

Once tests ran, 5,152 passed and 2 failed. One failure was a check doing its job: I had added the /mcp command file but never added it to the seeded catalog. The other was a Lobast end-to-end test that collided with the Lobast broker already running on my machine. DevNitro fixed both that night.

What Shipped

Lobast's MCP session proxy and DevNitro's remote MCP support merged to main Tuesday night. The commit button also works with Open Folder now, after Wednesday's fix, since a couple of my repos have no solution file.

Thursday DevNitro picked up two server-side rules. The starting provider, model, and effort now come from shared server defaults, and the server enforces company AI policy even when a client names a provider or model directly. I deployed Thursday night.

The Numbers

Category Hours
Content 26h 48m
Product / Features 11h 48m
Testing 4h 58m
Business 1h 37m
Deploy / Infra 0h 48m
Total 46h 0m

Content took the most time: YouTube scripts, a close look at my channel analytics, and the animation video pipeline DevNitro built for my videos. DevNitro product, test, and deploy time came to 17h 35m, up from 15h 54m last week, and the Visual Studio extension was the biggest single product line. There are many things I could spend time on with DevNitro, but I'm refraining as I'm trying to put my time into go-to-market (GTM) efforts.

Where This Fits in Intelligent Engineering

Thursday's policy change means the server checks every provider and model a client asks for against the company's policy. A standard the organization sets has to hold even when a developer's machine, or an AI agent running on it, asks for something else. The remote MCP work follows the same idea. The broker holds the secret, so the agent never has it to leak.

I've used the commit button for my DevNitro commits since Tuesday night, including this week's remote MCP servers work. My GitHub Copilot subscription will cancel automatically in December. Not sure why all my usage was gone so fast. Looks like I used it for 30 commit messages and that was the max. Fortunately, it caused me to add a feature I needed into DevNitro. Back at it next week.