When you turn on exhaustive, exhaustruct and wrapcheck linters in golangci-lint. You get such a massive safety boost and it makes you fly through writing Go.

One of the team members working on Gram here.

I initially worked on a code generator for OpenAPI -> MCP in January but very quickly we found issues relating to poor quality operation (tool) names and descriptions. Not to mention that each API endpoint does not cleanly map to an MCP tool and yet it all gets dumped into the context window - sometimes exhausting it if you have hundreds of schemas and endpoints.

Gram is our attempt to make better use of API by adding a curation layer:

- You upload your OpenAPI document, or any number of other OpenAPI documents. - You then subset them into "toolsets" by selecting only the ones relevant to a domain (e.g. reading stripe charges) or business process (e.g. understanding customer health by reading info from your CRM, data warehouse and so on). - Optionally, you create custom tools (these are prompt templates under the hood) that describe how to make a series of tool calls to solve a problem. - Finally, every toolset is automatically exposed as a hosted/managed MCP server. No waiting for build or deploy steps. - You can edit the names and descriptions of all imported tools and they are instantly reflected in the MCP server.

The net result is you have a rapid iteration loop to create effective tools from your API.

I hope you have a chance to try it out. Will be around to answer any questions in the mean time :)

I just love how this language marches forward. I have so many colleagues that hate many aspects of it but I sit here combining Go, Goa and SQLc writing mountains of code and having a fairly good compiler behind me. I understand what I’m missing out on by not using stricter languages and so often it’s a totally fine trade off.

I know this won’t apply to everyone but I’ve been able to, relatively successfully, stick to the constraint that most of my dev tools are static binaries: zoxide, fzf, eza, btop and so on. There is one glaring exception which is docker but I let it pass.

By sticking to this I’m able to avoid Homebrew’s mess and Nix’s complexity. I use mise (https://mise.jdx.dev/) to manage the binaries and languages I have on my machine. It handles installing multiple versions and is directory-aware.

The introduction of WWW-Authenticate challenge is so welcome. Now it's much clearer that the MCP server can punt the client to resource provider's OAuth flow and sit back waiting for an `Authorization: Bearer ...`.

It's somewhat disappointing to see a bunch of "well, duh" comments here. We're often asking for research and citations and this seems like a useful entry in the corpus of "effects of AI usage on cognition".

On the topic itself, I am very cautious about my use of LLMs. It breaks down into three categories for me: 1. replacing Google, 2. get a first review of my work and 3. taking away mundane tasks around code editing.

Point 3. is where I can become most complacent and increasingly miscategorize tasks as mundane. I often reflect after a day working with an LLM on coding tasks because I want to understand how my behavior is changing in its presence. However, I do not have a proper framework to work out "did i get better because of it or not".

I still believe we need to get better as professionals and it worries me that even this virtue is called into question nowadays. Research like this will be helpful to me personally.

If you limit yourself to common programming languages and single-binary programs (e.g. ones written in Rust/Go) then I cannot recommend Mise enough to you. Absolute bliss compared to homebrew, asdf and other projects especially if you want multiple versions of tools in different projects.

https://mise.jdx.dev/