MCP 2025-11-25 vs. MCP 2026-07-28

A comparison of the major protocol changes introduced in the MCP 2026-07-28 specification.

The following table compares the earlier MCP protocol (2025-11-25 and earlier) with MCP 2026-07-28, highlighting the architectural changes introduced by the move toward a stateless, request-oriented protocol.

Category	Direction	Old MCP (2025-11-25 and earlier)	MCP 2026-07-28
Handshake	Client ↔ Server	initialize / notifications/initialized; server returns Mcp-Session-Id	Removed — version/capabilities travel per-request in _meta. No pinning to a server instance
Session	both	Mcp-Session-Id header on every request; needs sticky routing	Removed — every request self-contained. Any instance can answer any request
Capability probe	Client → Server	Implicit in initialize	server/discover (optional to call, MUST be implemented). Decoupled from a handshake
Routing	Client → Server	Gateway must parse JSON body	Mcp-Method, Mcp-Name headers. Header-based routing without body parsing
Discovery	Client → Server	tools/list, resources/list, prompts/list — varies per connection	Same calls, plus resources/templates/list; now cacheable (ttlMs, cacheScope). Cacheable since results no longer vary per-connection
Core calls	Client → Server	tools/call, resources/read, prompts/get	Same, but can return InputRequiredResult. Adds the MRTR path
Cross-call state	Client → Server	Implicit via session	Explicit server-minted handle passed back as a tool argument (SEP-2567). State made explicit, not connection-bound
Server-initiated input	Server → Client	sampling/createMessage, elicitation/create, roots/list — server calls back mid-handler	Deprecated (SEP-2577) → MRTR: server returns InputRequiredResult; client re-issues original call with inputResponses + echoed requestState. True server → client calls replaced by client-driven retries
Subscribe	Client → Server	resources/subscribe (per URI) / resources/unsubscribe	subscriptions/listen with a filter (toolsListChanged, promptsListChanged, resourcesListChanged, resourceSubscriptions: [uris]). One call can cover many watch targets; multiple concurrent listen streams allowed
Subscription push	Server → Client	notifications/resources/updated, notifications/*/list_changed over the session's GET/SSE connection	Same notifications, now tagged with io.modelcontextprotocol/subscriptionId in _meta, delivered only on the stream that requested them. Demultiplexed by subscription, not by session
Subscription teardown	Client → Server	resources/unsubscribe	Close the SSE stream (HTTP) / notifications/cancelled referencing listen ID (stdio); no dedicated unsubscribe RPC. Server holds no state across reconnects — must re-listen after any drop
Progress	Server → Client	notifications/progress, keyed by progressToken in request _meta	Unchanged in spirit — still request-scoped. Same mechanism, explicitly not moved to subscriptions/listen
Logging level	Client → Server	logging/setLevel (session-scoped)	io.modelcontextprotocol/logLevel in per-request _meta. Per-request instead of per-session Logs are sent in the same open connection, before final response as "notifications/message".
Keepalive	both	ping	Removed — SSE comment-line keepalives on long streams instead. No dedicated RPC
Cancellation	Client → Server	notifications/cancelled	Close the SSE response stream (HTTP); notifications/cancelled now stdio-only. Cancellation piggybacks on stream closure over HTTP
Long-running work	Client ↔ Server	No first-class support	tasks/get, tasks/update, tasks/cancel (extension); tools/call can return a task handle; tasks/list removed. New capability, extension framework
Interactive UI	Server → Client	Not supported	MCP Apps extension (SEP-1865) — sandboxed iframe HTML. New capability
Stream resumability	—	SSE Last-Event-ID allowed reconnect/redelivery	Removed — broken stream ⇒ re-issue request with new ID, no redelivery. Simplicity traded for reliability guarantee

Key takeaway: MCP 2026-07-28 moves away from connection- and session-bound behavior toward self-contained, request-scoped interactions, while introducing mechanisms such as MRTR, subscription-based listening, explicit cross-call state, tasks, and MCP Apps.

MCP v2 changes things a lot for the developer

 As I go deep into MCP v2, overwhelming changes are being noticed:

• Session is being done away with.
• If at all server needs to refer to state from previous response,  server appends a requestState in response, which the client must echo in next request.
• Server will never make a call to client - this is biggest change. Channel must be kept open if you require multiple server responses for one single request. 
• Elicitation: Client Sends a Request to Server. Server responds to the request, which contains a field called InputRequiredResult. Then client re-issues  the request with inputResponses + requestState
• For Progress/Notification : 
• For non-request-scoped notification (.e.g subscription to listChanged events of tools/prompts/resources), client opens one request and that request is kept open forever (till the time required by client).
• For request-scoped notifications such as progress and logging, the notifications (notification/progress and notification/message) are sent in the same open connection, before the final response "result" to the mcp "tools/call" request is sent. The connection closes after the final response is received by the client from server.
• Roots is deprecated

Mamba

What Mamba Is

Mamba is a new large language model (LLM) architecture introduced in late 2023 by researchers from Carnegie Mellon and Princeton. It’s built on Structured State Space (S4) models and aims to overcome transformers’ inefficiencies on long sequences by using a selective, input-dependent state space mechanism.

Key Innovations

• Selective State Spaces (SSM): Mamba’s core block dynamically filters information, keeping what’s relevant and discarding the rest as it processes each token.
• Simplified block design: It replaces the transformer’s heavy attention + MLP blocks with a single, cohesive SSM block, reducing complexity.
• Hardware-aware parallelism: Uses a parallel scan algorithm tuned for GPUs, optimizing memory usage and throughput.
• Linear-time scaling: Training and inference scale linearly with sequence length, unlike transformers’ quadratic attention cost.

Architecture Highlights

Mamba introduces a selected SSM layer that:

• Focuses on relevant info: Weights inputs differently so predictive signals dominate.
• Adapts to inputs: Parameters change per token (time-varying), enabling flexible sequence modeling.

It’s designed to fit GPU high-bandwidth memory and exploit parallel compute, improving speed and memory efficiency.

Mamba vs Transformers

Transformers	Mamba
Attention-based; excellent at capturing global relationships but suffer from high memory/compute as sequences grow (quadratic scaling).	SSM-based; uses a fixed-size hidden state that compresses history, enabling much faster inference and lower memory on long contexts.

Trade-offs noted in broader research (and acknowledged in the article’s context): transformers can still outperform on some retrieval/copying tasks and may need less data to learn certain behaviors, despite Mamba’s efficiency gains.

Usage

• Requirements: Linux, NVIDIA GPU, PyTorch 1.12+, CUDA 11.6+.
• Install: pip install causal-conv1d (optional) and pip install mamba-ssm from the official repo; can also build from source.
• Usage: Instantiate a Mamba module with parameters like d_model, d_state, d_conv, and expand, then pass tensors of shape (batch, length, dim) .

Applications

Because it handles long sequences efficiently, Mamba is positioned for:

• Long-form text analysis and content generation
• Speech/audio and time-series modeling
• Real-time translation and chatbots that track long conversations

Domain impacts highlighted include healthcare (genomic data), finance (long-term trends), and customer service (long-context dialogues).

Bottom Line

Mamba reframes sequence modeling by replacing attention with selective state spaces, delivering linear-time scaling and major efficiency gains for long contexts—making it a strong alternative (and potential complement) to transformers in future AI systems.

Semantic Layer in Data Science

Core Idea

A semantic layer is an intermediary between raw data sources (data warehouses, lakes, etc.) and business users/tools. It translates technical schemas into business-friendly terms, defines shared vocabulary and rules, and provides a consistent, governed view of data for analytics.

Why Organizations Need It

• Eliminates silos and inconsistency: Unifies data from many systems under one business vocabulary so “sales,” “revenue,” etc., mean the same thing across teams.
• Improves accessibility: Lets non-technical users explore data via self-service without deep SQL or schema knowledge.
• Speeds insights: Predefined metrics and relationships let analysts build reports faster and make decisions more quickly.

Types of Semantic Layers

• Universal: Standalone, enterprise-wide layer acting as a single source of truth; great for governance and flexibility but costlier.
• Data warehouse semantic layer: Lives inside the warehouse; focuses on naming, data model organization, and lineage.
• Data lake semantic layer: Organizes schemas and meanings for unstructured/semi-structured data in lakes.
• BI semantic layer: Sits between warehouses/lakes and tools like Power BI/Tableau; defines business concepts, relationships, and prebuilt metrics.

How It Works (Key Components)

1. Data sources: Raw repositories (warehouses, lakes).
2. Data integration: Extracts and transforms data into consistent formats.
3. Metadata repository: Stores definitions, models, and relationships.
4. Semantic model: Encodes business logic, hierarchies, metrics, and calculations.
5. Query engine: Translates user queries into source-specific queries.
6. Presentation layer: Dashboards/reports users interact with.

Building a Semantic Layer (High-Level Steps)

1. Identify business requirements with analysts and domain experts.
2. Assess existing data sources for format and quality.
3. Design the semantic model using sound modeling techniques.
4. Implement using BI/data modeling tools (views, calculated fields, hierarchies).
5. Integrate with sources via connectors/APIs and ETL/ELT processes.
6. Test, validate (including UAT), then deploy and maintain with ongoing monitoring.

Challenges to Watch

• Complex initial setup and integration.
• Scalability as data volume/variety grows.
• Maintaining consistency across sources.
• Ongoing cost, resources, and change management/user adoption.

Common Implementation Architectures

Architecture	Description
Metadata-first	Logical, metadata-driven unification without physical consolidation; balances standardization and agility.
Ontology modeling language (OML)	Uses a shared ontology (e.g., UFO) to build a knowledge graph for federated data.
Built-for-purpose	Decentralized, leveraging semantics inside individual tools (CRM, BI) per business unit.
Centralized	Consolidates definitions/logic in an EDW/DL; strong governance but heavy upfront investment.

Tools with Sematic-Layer Capabilities

Cube.js, MetricFlow, dbt, Tableau, and Power BI, highlighting features like data modeling, metrics layers, caching, APIs, and visualization/integration strengths.

FastMCP renamed to MCPServer and Context object still required

While the Model Context Protocol (MCP) 2026-07-28 specification removed protocol-level sessions (Mcp-Session-Id and the initialize handshake) to make the protocol stateless, the Context object in FastMCP remains a core feature, though its underlying scope and behavior have changed.

How the Context Object Has Changed

From Session-Scoped to Request-Scoped

Previously, the Context object was tied directly to a persistent, long-lived client session. In the new stateless era, each individual MCP request receives a brand new, isolated Context object.

State Isolation

Any state you set dynamically inside a tool via ctx.set_state() is strictly scoped to that single, specific request execution. It does not leak or persist into subsequent tool calls or requests.

Protocol Era Coexistence

The Context object is backward-compatible. Inside your handlers, you can check ctx.request_context.protocol_version to determine if a call arrived via the legacy handshake era (session-backed) or the modern stateless era.

Ambient Cleanup

The ambient server.request_context global ContextVar has been entirely removed in favor of strict, clean parameter injection (ctx: Context) passed directly into your functions.

Why the Context Object Is Still Needed

The Context object does not exist just to manage sessions; it acts as your tool's gateway to operational sub-systems. It is still heavily used for:

• Logging & Progress: Dispatching real-time ctx.info(), ctx.error(), and ctx.report_progress() updates back to the client UI.
• Client Sampling: Allowing the server to request completions from the client LLM dynamically using ctx.sample().
• Lifespan Management: Providing access to persistent backend resources initialized at startup (like database drivers or external APIs) via ctx.request_context.lifespan_context.

Note

As part of the same v2 stateless transition, the high-level framework class FastMCP has been renamed to MCPServer in the official Python SDK.

Migration Details

Old Import (v1): from mcp.server.fastmcp import FastMCP
New Import (v2): from mcp.server.mcpserver import MCPServer
Context Property: ctx.fastmcp changed to ctx.mcp_server

Comparison between Google's Native Gemini SDK and the LangChain wrapper

Table: Comparison between Google's Native Gemini SDK and the LangChain wrapper.

Feature	genai.Client (Google Native SDK)	ChatGoogleGenerativeAI (LangChain Wrapper)
Created By	Google	LangChain Community
Installation Package	google-genai	langchain-google-genai
Execution Call	.models.generate_content()	.invoke() or .stream()
Swapping Models	Heavy rewrite required if moving away from Google.	Instant swap with any LangChain-supported provider.
Best Used For	High-performance apps built only on Gemini or utilizing heavy file processing.	Complex agent pipelines, retrieval-augmented setups (RAG), and multi-model projects.

Tools : MCP vs Langchain

Feature	LangChain Native Tool	MCP (Model Context Protocol) Tool
Core Nature	Application-level abstraction/code component.	Infrastructure-level, open network protocol.
Architecture	In-process execution (runs inside your app memory).	Inter-process/network communication (Client-Server via JSON-RPC).
Portability	Bound to the LangChain framework ecosystem.	Vendor-neutral; works across any MCP-compliant platform.
Discovery	Hardcoded/imported statically by the developer.	Dynamic discovery by the client at runtime.
Security & Isolation	Low; shares permissions and runtime environment with the app.	High; tool server executes in an isolated environment/network.
Implementation Ownership	App consumer must write or wrap the code for every API.	Service provider creates one server for all consumers.
Scope of Logic	Flexible; can embed inner orchestration or multi-step logic.	Strictly atomic; limited only to data access or point actions.
Ecosystem Targets	Custom agent applications built by developers.	IDEs (Cursor, Windsurf), Chat UI clients, and enterprise platforms.