[runekaagaard]

I thinks a lot is timing and also that it's a pretty low bar to write your first mcp server:

    from mcp.server.fastmcp import FastMCP
    mcp = FastMCP("Basic Math Server")

    @mcp.tool()
    def multiply(a: int, b: int) -> int:
        return a * b

    mcp.run()

If you have a large MCP server with many tools the amount of text sent to the LLM can be significant too. I've found that Claude works great with an OpenAPI spec if you provide it with a way to look up details for individual paths and a custom message that explains the basics. For instance https://github.com/runekaagaard/mcp-redmine

[_raz]

That's kind of my point, that the protocols complexity is hidden in py sdk making it feel easy... But taking on large tech dept

[practal]

The difficult part is figuring out what kind of abstractions we need MCP servers / clients to support. The transport layer is really not important, so until that is settled, just use the Python / TypeScript SDK.

[mmcnl]

But the spec is on the transport level. So for the specification, the transport layer is very important.

[practal]

This is the spec that counts: https://github.com/modelcontextprotocol/modelcontextprotocol...

How exactly those messages get transported is not really relevant for implementing an mcp server, and easy to switch, as long as there is some standard.

[vlovich123]

You’re ignoring the power of network effects - “shitty but widely adopted” makes “better but just starting adoption harder” to grow. Think about how long it takes to create a new HTTP standard - we’ve had 3 HTTP standards in the past 30 years, the first 19 of which so no major changes. HTTP/2 kind of saw no adoption in practice and HTTP/3 is still a mixed bag. In fact, most of the servers pretend HTTP/1 with layers in front converting the protocols.

Underestimate network effects and ossification at your own peril.

[pixl97]

I mean isn't this the point of a lot of, if not most successful software? Abstracting away the complexity making it feel easy, where most users of the software have no clue what kind of technical debt they are adopting?

Just think of something like microsoft word/excel for most of its existence. Seems easy to the end user, but attempting to move away from it was complex, the format had binary objects that were hard to unwind, and interactions that were huge security risks.

[Scotrix]

yeah, but it doesn’t need to be that way. It can be simple and makes it easier adoptable, why over engineering and reinventing the wheel of at least 2 decades experience and better practices.

[pixl97]

Simple software is the most difficult software to make.

Historically stated as

>I apologize for such a long letter - I didn't have time to write a short one.