What the people that predicted that AI will change productivity drastically in just a year or two imho underestimate: Just because a technology is capable of this in theory (and I think it is, even today) - it doesn't mean we are willing or able to deploy it to its full potential at scale. There will be a few individuals and very few companies which will do so or come close.

For most of the companies, they're still doing a lot of processes manually that could have been automated with 80s technology. Why should a change in the technology suddenly make everyone change their mindset, culture, way of thinking? This may take 1-2 generations to more fully form. Maybe that's also better: Slower change is less destablizing for society / individuals, I think of it more like a defensive mechanism of the system to keep it stable.

I hope such things will be standardized across vendors. Now that they founded the Agentic AI Foundation (AAIF) and also contributed AGENTS.md, I would hope that skills become a logical extension of that.

https://www.linuxfoundation.org/press/linux-foundation-annou...

https://aaif.io/

Comments URL: https://news.ycombinator.com/item?id=45493236

Points: 5

# Comments: 0

But now that many companies focus on MCP as a remote API, the question obviously comes up why not just use standard API protocols for that and just optimize the metadata for AI consumption.

The article also mentioned that OpenAPI is too verbose: I totally see that, but you could optimize this by stripping an OpenAPI file down to the basics that you need for LLM use, maybe even using the Overlay spec. Or you convert your OpenAPI files to the https://www.utcp.io format that pylotlight mentioned.

Some "curation" of what's really relevant for AI consumption may be a helpful anyway, as too many tools will also lead to problems in picking the right ones.

I did something similar a long time back, but not really focused on something that tiles up: https://svg-generator.netlify.app/

Still, I think it should only be an option, not a necessity to create an MCP API around existing APIs. Sure, you can do REST APIs really badly and OpenAPI has a lot of issues in describing the API (for example, you can't even express the concept of references / relations within and across APIs!).

REST APIs also don't have to be generic CRUD, you could also follow the DDD idea of having actions and services, that are their own operation, potentially grouping calls together and having a clear "business semantics" that can be better understood by machines (and humans!).

My feeling is that MCP also tries to fix a few things, we should consider fixing with APIs in general - so at least good APIs can be used by LLMs without any indirections.

Using a smaller set of different concepts also helps reducing the cognitive load, even if it leads to more verbosity ("less clever code").

https://www.sicpers.info/2018/03/why-inheritance-never-made-...

See announcement here: https://devblogs.microsoft.com/windows-music-dev/windows-mid...

Your project got me thinking - here's one idea: Windows should get MIDI 2.0 support soon, incl. non-blocking MIDI reading if I understood correctly. That should make it possible to create a small background application that records all incoming MIDI from all (or chosen) connected MIDI devices. It would work very much like your recorder and could share the same mobile app?

This I would be interested in. Since it's a software only solution, it could be cheaper and lower entry barrier.

Not entirely sure what you mean with canonical representation (I've heard this in the context of JSON-LD before, though). Can you explain what you mean here?

Where do you see the problem with Graphs and Dos? A reference is just a pointer. You just have to be careful when doing recursive code. I actually like the idea to explicitly define how a reference / association is made, because otherwise people will have to re-invent ID and association concepts and there's no shared understanding. In JSON Schema, you cannot properly express an association or graph structure and people start using overloaded and not well-defined concepts like `$ref` which is a separate standard.

One thing that is also really important is the ability to define a schema and be able to validate. See XML Schema, JSON Schema. This is a really tricky problem to get right. Especially if you try to do both with the same model (describing your data model and describing how its validated) at the same time.

Once you have the schema, IDEs like VSCode offer code-intelligence and real-time validation, which is very nice.