You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As much as SDKs can be helpful, they do abstract away some aspects of the protocol that might be relevant for first timers. This is useful to understand the logic, inner workings and possibilities of the protocol. Currently, it seems that most documentation evolves around very specific implementations: using the SDK to create the server, using stdio as transport, and using clients that only support stdio (Claude Desktop, Cline, and apparently Continue seem to have this restriction).
There are a lot of agents in the wild that have been implemented in multiple different ways. As an example, currently, we have a few agents running in production that use a very simple protocol for tools (services that run separately from the agent itself):
GET /tools POST /tools/:id/executions
This works, and it does allow us for both decoupling and composition when building new agents. However, it is a very specific (simplistic, rudimentary) protocol. It would make a lot of sense for us to try to adapt to what might become a global protocol. However, it can be challenging to rewrite existing agents (both client/server) using the SDK, while it could be straight forward, if we were to slowly adapt the protocol, up into a point where both client and server are MCP-compliant and could be used in different scenarios (other clients/servers).
The way this could be implemented is straightforward: create examples in docs that do not leverage the SDK, but rather show the implementation, there are a lot of pieces around, one being the transport section that does show to HTTP routes /mcp/message and /mcp/sse, however, we found complete examples lacking when trying to move forward toward that route.
The text was updated successfully, but these errors were encountered:
As much as SDKs can be helpful, they do abstract away some aspects of the protocol that might be relevant for first timers. This is useful to understand the logic, inner workings and possibilities of the protocol. Currently, it seems that most documentation evolves around very specific implementations: using the SDK to create the server, using stdio as transport, and using clients that only support stdio (Claude Desktop, Cline, and apparently Continue seem to have this restriction).
There are a lot of agents in the wild that have been implemented in multiple different ways. As an example, currently, we have a few agents running in production that use a very simple protocol for tools (services that run separately from the agent itself):
GET /tools
POST /tools/:id/executions
This works, and it does allow us for both decoupling and composition when building new agents. However, it is a very specific (simplistic, rudimentary) protocol. It would make a lot of sense for us to try to adapt to what might become a global protocol. However, it can be challenging to rewrite existing agents (both client/server) using the SDK, while it could be straight forward, if we were to slowly adapt the protocol, up into a point where both client and server are MCP-compliant and could be used in different scenarios (other clients/servers).
The way this could be implemented is straightforward: create examples in docs that do not leverage the SDK, but rather show the implementation, there are a lot of pieces around, one being the
transport
section that does show to HTTP routes/mcp/message
and/mcp/sse
, however, we found complete examples lacking when trying to move forward toward that route.The text was updated successfully, but these errors were encountered: