MCP 2026-07-28 for Local AI: Stateless Servers, server/discover, Migration & Security

Model Context Protocol (MCP) changed materially with the 2026-07-28 protocol revision. The most important change for local-AI developers is not a new model or UI feature: MCP moved to a stateless request model, removed the old mandatory initialize handshake for modern clients, and added server/discover so clients can discover protocol versions and capabilities before making tool calls.

That matters if you are building a local AI agent around Ollama, LM Studio, llama.cpp, OpenHands, Goose, or your own MCP client. A server that was written around the older session-oriented lifecycle may still work through compatibility paths, but new integrations should understand which protocol generation they are speaking, where state now lives, and how to secure tools that can read files, execute commands, access databases, or call network services.

This guide focuses on the practical side: what changed, how modern MCP negotiation works, how to test a local server, how to migrate session assumptions, and how to avoid turning a private local agent into an over-privileged automation endpoint.

Why MCP 2026-07-28 Is a Useful Local-AI Content Cluster

GyanAangan already covers individual local runtimes, RAG, Ollama troubleshooting, LM Studio APIs, vLLM serving, and Goose security. The gap is the protocol layer connecting those pieces: how modern MCP actually works in 2026 and how local AI developers should migrate or design around it. The current MCP project is actively maintained, its 2026-07-28 specification is stable, and official SDKs are implementing the new lifecycle.

The official specification says the modern protocol is stateless: each request carries the information needed to process it, while application-level state that must survive multiple requests should be represented by explicit identifiers. The specification also introduces server/discover as the discovery mechanism. This is a more useful long-lived foundation than another generic “best local AI tools” list because it explains an underlying protocol change that affects many agent stacks.

What Changed in MCP 2026-07-28?

The official changelog describes the removal of protocol-level sessions and the Mcp-Session-Id header for the modern Streamable HTTP flow. It also moves protocol version, client identity, and capabilities into request metadata. That distinction is important: stateless protocol does not mean your application can never have state. It means the MCP protocol should not silently infer that state from a previous connection.

Understand server/discover Before You Touch Your Agent

A modern client can ask a server what it supports before sending normal MCP operations. The request uses JSON-RPC and includes metadata describing the protocol version and client capabilities.

{
  "jsonrpc": "2.0",
  "id": "discover-1",
  "method": "server/discover",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "my-local-agent",
        "version": "1.0.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

The server responds with supported protocol versions, capabilities, and server information. The official specification states that discovery results can be cached, so a client does not necessarily need to repeat discovery for every tool call.

{
  "jsonrpc": "2.0",
  "id": "discover-1",
  "result": {
    "resultType": "complete",
    "supportedVersions": ["2026-07-28"],
    "capabilities": {
      "tools": {}
    }
  }
}

One subtle security point is easy to miss: server identity is informational. The official discovery specification explicitly says clients should not rely on self-reported serverInfo to make security decisions. Authentication, authorization, network policy, and trust configuration still need to be handled separately.

Stateless Does Not Mean “No State”

This is the migration concept most likely to cause bugs.

Imagine an agent that starts a long-running operation and stores an internal identifier in memory because the next request is expected to arrive on the same session. That design is fragile under the modern protocol. If the operation genuinely needs state, expose or retain an explicit application-level handle and send that handle with subsequent requests.

A simplified pattern looks like this:

{
  "tool": "build_project",
  "arguments": {
    "request_id": "job_8f21",
    "project": "/srv/my-project"
  }
}

The MCP server can then resolve job_8f21 from a database, cache, signed state object, or another application-owned store. The important design principle is that the state is explicit rather than being inferred from a connection or worker process.

What This Means for Local AI Agents

Local agents often combine an LLM with tools that are much more powerful than the model itself. An Ollama or LM Studio model may only generate a tool call, while the MCP server actually reads files, runs Git commands, queries a database, or invokes an external API.

That creates three separate boundaries:

1. Model boundary: the local LLM decides what it wants to do.
2. MCP client boundary: the host validates and routes tool requests.
3. Tool boundary: the MCP server performs the real-world action.

Do not treat “the model runs locally” as equivalent to “the entire workflow is trusted.” A local model can still be induced to request a dangerous tool operation by untrusted repository content, a malicious document, an MCP server, or prompt injection.

Recommended Local MCP Architecture

For a developer workstation, start with stdio for trusted local servers when possible. Move to Streamable HTTP when you actually need a network boundary, remote client, shared service, or horizontally scalable deployment. Do not expose an MCP endpoint to a LAN or the public internet merely because your LLM is local.

How to Verify Which MCP Generation You Are Using

The exact command depends on your SDK, but your verification goal should be consistent.

1. Identify the MCP client and SDK version.
2. Identify the MCP server and SDK version.
3. Check whether the client attempts server/discover.
4. Check the negotiated protocol version.
5. Confirm which transport is actually being used.
6. Test a harmless read-only tool before enabling write or shell tools.

For example, official SDK documentation shows modern clients probing server/discover and falling back to initialize when they encounter an older server. That compatibility behavior is useful during migration, but you should not mistake a successful fallback for proof that your server has been migrated to the modern protocol.

Python MCP SDK: A Practical Compatibility Check

If you are using the official Python SDK, run a small client against your local server and print the negotiated protocol version. The current SDK documentation describes an automatic discovery-first flow.

import anyio
from mcp import Client

async def main():
    async with Client("http://127.0.0.1:8000/mcp") as client:
        print("Protocol:", client.protocol_version)

if __name__ == "__main__":
    anyio.run(main)

For a modern server, the expected protocol value is 2026-07-28. If the client falls back to an older generation, investigate compatibility rather than assuming the modern lifecycle is active.

Streamable HTTP and Horizontal Scaling

The stateless design is especially interesting for deployments with multiple workers. A modern request is not tied to an MCP protocol session, which removes one important reason for sticky sessions. This can make ordinary load balancing easier.

However, application state still has to live somewhere durable or deliberately scoped. If a multi-step operation depends on in-memory state on worker A, worker B cannot magically reconstruct it when the next request arrives.

A practical production layout is:

Client
  |
  v
Reverse Proxy / TLS
  |
  +---- MCP worker A ----+
  |                      |
  +---- MCP worker B ----+---- Redis / DB / application state
  |                      |
  +---- MCP worker C ----+

Keep authentication and authorization at the HTTP boundary, then apply tool-level authorization inside the MCP server. If your server performs privileged operations, a network load balancer should never be considered the only security layer.

Security: The Most Important Local-AI Trade-off

MCP can make an agent dramatically more useful, but every tool expands its attack surface.

The MCP ecosystem itself documents security concerns such as confused-deputy behavior, token passthrough and server-side request forgery. Treat these as protocol/application security problems, not as issues that disappear because the LLM is running on your own machine.

Common Migration Failures

“My server only works after initialize”

Your client or server may still be using the older protocol generation. Confirm SDK versions and whether the implementation supports server/discover. Compatibility fallback can keep an old integration working while hiding the fact that it has not been migrated.

“I removed sessions and now my tool loses state”

Move application state into an explicit handle, database, cache, or other application-owned mechanism. Stateless MCP does not provide automatic cross-request application state.

“Discovery says the server supports something dangerous”

Discovery is capability information, not authorization. Do not grant trust because a server advertises a capability. Use explicit configuration and policy to decide which tools a client can actually invoke.

“My modern client cannot connect to an old server”

Check protocol negotiation and compatibility support. Modern SDKs may probe server/discover and then fall back to initialize for older servers, but behavior depends on the client and server implementations.

“Multiple workers randomly lose a task”

Look for application state stored only in process memory. Modern MCP removes protocol-session affinity; your own task state still needs a shared or portable representation if requests can land on different workers.

How MCP Fits With Ollama, LM Studio and Local RAG

MCP is not an inference engine. Ollama, LM Studio and llama.cpp provide model execution or model-serving capabilities; MCP provides a standardized way for agent hosts to interact with external tools and context providers.

A useful local stack can therefore look like:

Local model
   |
   v
Ollama / LM Studio / llama.cpp
   |
   v
Agent host
   |
   +---- MCP filesystem server
   +---- MCP Git server
   +---- MCP database server
   +---- Local RAG / retrieval tools
   +---- Carefully scoped external APIs

This separation lets you change the inference runtime without redesigning every tool integration. It also makes security review clearer because model execution, agent policy, tool implementation and OS permissions are separate layers.

Prerequisites for a Safe Local MCP Setup

• A local AI runtime such as Ollama, LM Studio or llama.cpp.
• An MCP-capable agent/client.
• An MCP server compatible with the protocol generation you intend to use.
• A dedicated test directory rather than your entire home directory.
• No production credentials in environment variables accessible to arbitrary tools.
• A backup or Git worktree before testing write-capable tools.
• Basic understanding of localhost, LAN binding, TLS and firewall rules if using HTTP transport.

A Safer First Test

Create a disposable directory containing a harmless text file. Connect a read-only MCP server that can access only that directory. Ask the local agent to list the file and read it. Verify the server logs, then deliberately try an operation outside the allowed path.

The expected result is not simply “the model says no.” The server or operating-system boundary should reject the unauthorized operation.

mkdir mcp-test
printf "local MCP test\n" > mcp-test/hello.txt

After the read-only test works, add one capability at a time. This makes failures and permission mistakes much easier to isolate.

Official Sources and Further Reading

• MCP specification releases
• MCP 2026-07-28 changelog
• MCP server/discover specification
• MCP statelessness specification
• Official MCP Go SDK releases

Related GyanAangan Guides

• Goose + Ollama Local AI Agent Setup in 2026
• How to Secure Goose MCP Extensions in 2026
• LM Studio Responses API 2026: Local Models, Tools & MCP
• LM Studio API Setup 2026
• How to Build a Private Local RAG System in 2026

FAQ

Does MCP 2026-07-28 completely replace initialize?

For the modern 2026-07-28 protocol lifecycle, the old mandatory initialize handshake is removed. Clients and servers can still support older protocol revisions for compatibility.

Is MCP now completely stateless?

The protocol lifecycle is stateless, but applications can still maintain state. The difference is that state needed across requests should be represented explicitly rather than being inferred from a protocol session.

Do I need to upgrade every MCP server immediately?

Not necessarily. Compatibility support exists across protocol generations, and the correct migration timing depends on the SDK and clients you use. For new development, however, you should understand and test the 2026-07-28 lifecycle rather than assuming the older handshake model.

Is local MCP automatically private?

No. A local MCP server can still read sensitive files, expose secrets, execute commands, or make network requests. Privacy depends on the tools, permissions, network exposure and credentials you give it.

Should I expose an MCP server directly to the internet?

Usually not as a first step. Prefer localhost or a tightly controlled private network, authenticated HTTP when network access is required, least-privilege tools, and an explicit reverse-proxy/firewall policy.

What should I learn next?

If you are building a local coding agent, understand MCP protocol negotiation first, then tool permissions and prompt-injection boundaries. After that, connect your agent to a local model runtime and add tools incrementally.

Bottom line: MCP's 2026-07-28 revision is important because it changes the protocol lifecycle beneath local AI agents. The practical migration rule is simple: discover capabilities explicitly, carry protocol metadata per request, keep application state explicit, and enforce security outside the model. That architecture scales from a single developer laptop to a multi-worker private AI service without assuming that a local model is automatically trustworthy.