4 ms·

We are still a bit light on documentation on how to integrate MCP into an application. The best starting point are the respective client parts in the SDK: http

We are still a bit light on documentation on how to integrate MCP into an application. The best starting point are the respective client parts in the SDK: https://github.com/modelcontextprotocol/typescript-sdk/tree/main/src/client https://github.com/modelcontextprotocol/typescript-sdk/tree/... and https://github.com/modelcontextprotocol/python-sdk/tree/main/src/mcp/client https://github.com/modelcontextprotocol/python-sdk/tree/main..., as well as the official specification documentation at https://spec.modelcontextprotocol.io https://spec.modelcontextprotocol.io. If you run into issues, feel free to open a discussion in the respective SDK repository and we are happy to help. (I've been fairly successful in taking the spec documentation in markdown, an SDK and giving both to Claude and asking questions, but of course that requires a Claude account, which I don't want to assume)

xyc 2y ago
Thanks for the pointers! Will do. I've fired up https://github.com/modelcontextprotocol/inspector https://github.com/modelcontextprotocol/inspector and the code looks helpful too. I'm looking at integrating MCP with desktop app. The spec (https://spec.modelcontextprotocol.io/specification/basic/transports/#stdio https://spec.modelcontextprotocol.io/specification/basic/tra...) mentions "Clients SHOULD support stdio whenever possible.". The server examples seem to be mostly stdio as well. In the context of a sandboxed desktop app, it's often not practical to launch a server as subprocess because: - sandbox restrictions of executing binaries - needing to bundle binary leads to a larger installation size Would it be reasonable to relax this restriction and provide both SSE/stdio for the default server examples?
- xyc 2y ago
  ^ asked the question in the discussion: https://github.com/modelcontextprotocol/specification/discussions/63 https://github.com/modelcontextprotocol/specification/discus...
- somnium_sn 2y ago
  Having broader support for SSE in the servers repository would be great. Maybe I can encourage you to open a PR or at least an issue. I can totally see your concern about sandboxed app, particularly for flatpack or similar distribution methods. I see you already opened a discussion https://github.com/modelcontextprotocol/specification/discussions/63 https://github.com/modelcontextprotocol/specification/discus..., so let's follow up there. I really appreciate the input.
  - mst 2y ago
    A possible cheap win for servers would be to support the systemd "here's an fd number you get exec'ed with" model - that way server code that's only written to do read/write on a normal fd should be trivial to wire up to unix sockets, TCP sockets, etc. (and then having a smol node/bun/go/whatever app that can sit in front of any server that handles stdio - or a listening socket for a server that can handle multiple clients - and translates the protocol over to SSE or websockets or [pick thing you want here] lets you support all such servers with a single binary to install) Not that there aren't advantages to having such things baked into the server proper, but making 'writing a new connector that works at all' as simple as possible while still having access to multiple approaches to talk to it seems like something worthy of consideration. [possibly I should've put this into the discussion, but I have to head out in a minute or two; anybody who's reading this and engaging over there should feel free to copy+paste anything I've said they think is relevant]

xyc 2y ago

Thanks for the pointers! Will do. I've fired up https://github.com/modelcontextprotocol/inspector https://github.com/modelcontextprotocol/inspector and the code looks helpful too. I'm looking at integrating MCP with desktop app. The spec (https://spec.modelcontextprotocol.io/specification/basic/transports/#stdio https://spec.modelcontextprotocol.io/specification/basic/tra...) mentions "Clients SHOULD support stdio whenever possible.". The server examples seem to be mostly stdio as well. In the context of a sandboxed desktop app, it's often not practical to launch a server as subprocess because: - sandbox restrictions of executing binaries - needing to bundle binary leads to a larger installation size Would it be reasonable to relax this restriction and provide both SSE/stdio for the default server examples?

xyc 2y ago
^ asked the question in the discussion: https://github.com/modelcontextprotocol/specification/discussions/63 https://github.com/modelcontextprotocol/specification/discus...
somnium_sn 2y ago
Having broader support for SSE in the servers repository would be great. Maybe I can encourage you to open a PR or at least an issue. I can totally see your concern about sandboxed app, particularly for flatpack or similar distribution methods. I see you already opened a discussion https://github.com/modelcontextprotocol/specification/discussions/63 https://github.com/modelcontextprotocol/specification/discus..., so let's follow up there. I really appreciate the input.
- mst 2y ago
  A possible cheap win for servers would be to support the systemd "here's an fd number you get exec'ed with" model - that way server code that's only written to do read/write on a normal fd should be trivial to wire up to unix sockets, TCP sockets, etc. (and then having a smol node/bun/go/whatever app that can sit in front of any server that handles stdio - or a listening socket for a server that can handle multiple clients - and translates the protocol over to SSE or websockets or [pick thing you want here] lets you support all such servers with a single binary to install) Not that there aren't advantages to having such things baked into the server proper, but making 'writing a new connector that works at all' as simple as possible while still having access to multiple approaches to talk to it seems like something worthy of consideration. [possibly I should've put this into the discussion, but I have to head out in a minute or two; anybody who's reading this and engaging over there should feel free to copy+paste anything I've said they think is relevant]