nit about current MCP problems

Signed-off-by: bowlofarugula <[email protected]>

Author: bowlofarugula

content/blog/mcp-with-wasmcp.md

@@ -75,7 +75,7 @@ So why don't we see every org implementing MCP servers to integrate their applic
 Local MCP servers are relatively simple to implement over the stdio transport. Official SDKs and advanced third party frameworks are available in nearly every programming language. But distributing an MCP server, either as a local installation or as a service over the network, presents a number of new challenges.
 
 1. Local MCP servers can be an attack vector for exploiting host resources, unless they run in a sandboxed environment.
-2. Much of the value proposition of MCP, particularly its advanced bidirectional features and tool discovery mechanisms, is locked behind the need for stateful server sessions. This means that we either need servers to run as long-lived processes, keeping their session state directly onboard, or else we need to manage the infrastructure for external session state plus the server code that interacts with it, which may incur additional network latency and complexity.
+2. Many of MCP's advanced bidirectional features and tool discovery mechanisms are locked behind a dependency on server-managed sessions. This means that we either need servers to run as long-lived processes, keeping their session state directly onboard, or else we need to manage the infrastructure for external session state plus the server code that interacts with it, which may incur additional network latency and complexity.
 3. Scaling and and response latency matter. We may not initially think of the response time of remote tool calls as being important, given inference itself (especially with thinking enabled) is generally slow anyway. But consider that in answering a single query, an agent may need to make many consecutive tool calls to one or more remote MCP servers. The latency of even a few hundred milliseconds for each tool call can quickly snowball to seconds of lag. In realtime use cases like a voice or stock trading agent, even small response delays for tool calls can translate to the success or failure of the overall interaction or goal.
 4. Authorization is painful. While the MCP spec does define OAuth flows, authorization is not yet straightforward to implement in practice. Currently, it requires an authorizer that supports [Dynamic Client Registration](https://datatracker.ietf.org/doc/html/rfc7591). Support for a simplified flow via [OAuth Client ID Metadata Documents](https://datatracker.ietf.org/doc/draft-ietf-oauth-client-id-metadata-document/) is confirmed for the November 2025 spec release.