Using older version of langchain-mcp-adapters produces the following error:
ImportError: cannot import name 'streamablehttp_client' from 'mcp.client.streamable_http' (/usr/local/lib/python3.12/dist-packages/mcp/client/streamable_http.py). Did you mean: 'streamable_http_client'?
This is the error of version mismatch of langchain-mcp-adapters package, not an error of importing wrong package.
You can just updgrade langchain-mcp-adapters and check back:
!pip install --upgrade mcp langchain-mcp-adapters
This error was caused at the statement:
from langchain_mcp_adapters.client import MultiServerMCPClient
A revolutionary change was announced on 28/July/2026 in the MCP specifications. It announced specifications for stateless MCP, making it fit to the era of distributed computing.This redesign addresses one of the biggest barriers to deploying AI agents at production scale—scalability. By making MCP stateless, developers can now deploy AI agents using the same cloud-native infrastructure and scaling techniques that power modern web applications.
Background: Why MCP Matters
The Model Context Protocol (MCP) has emerged as the standard interface that allows AI models and agents to communicate with external tools, APIs, databases, and services.
Instead of building custom integrations between every model and every tool, MCP provides a common protocol that standardizes discovery and invocation.
However, the original MCP protocol maintained server-side session state. Once a client initialized a session with an MCP server, subsequent requests had to reach the same server instance because that instance stored the conversation and capability state.
While this worked well for local development and small deployments, it introduced serious challenges in production environments.
Problems with Stateful MCP
The article explains several operational limitations caused by maintaining sessions on the server.
1. Sticky Sessions
Because each server instance stored client state, load balancers had to route every request from a client back to the same server.
This prevented true horizontal scaling and made infrastructure more complex.
2. Difficult Autoscaling
Cloud-native platforms such as Kubernetes, Cloud Run, and serverless functions continuously add and remove instances based on demand.
With stateful MCP:
Removing an instance could disconnect active sessions.
Scaling required session replication or external session stores.
Infrastructure became significantly more complicated.
3. Reduced Reliability
If the server maintaining a client's session crashed, the session was lost.
Even rolling deployments could interrupt connected clients because session ownership was tied to a particular server.
These issues made production deployments unnecessarily difficult despite MCP itself being conceptually simple.
The Shift to Stateless MCP
The central idea of the update is simple:
Every request contains all of the information required to process it, in a new field called "_meta". It will include "capabilities" and "clientInfo" fields, which were earlier exchanged only in the beginning, in the "initialize" request. The "intialize" request itself is deprecated now.
Instead of relying on previously established server-side state, each request becomes self-contained.
This aligns MCP with how REST APIs and modern HTTP services already operate.
Now any server instance can process any incoming request.
The server no longer needs to remember earlier interactions.
Infrastructure Benefits
The article highlights several operational improvements.
Horizontal Scaling
Since every request is independent:
requests can go to any replica,
standard load balancers work correctly,
no sticky routing is necessary.
This greatly simplifies Kubernetes and cloud deployments.
Serverless Compatibility
Stateless services are ideal for:
Cloud Run
AWS Lambda
Azure Functions
edge computing platforms
Instances can start, handle a request, and shut down without preserving client state.
Improved Reliability
If one server fails:
another instance immediately handles subsequent requests,
clients experience fewer disruptions,
deployments become safer.
This improves availability while simplifying operations.
Self-Describing Requests
One of the major protocol changes is that requests now include metadata describing:
supported protocol version,
capabilities,
context needed for execution.
Previously, servers had to remember these details from an initialization handshake.
Now they travel with every request.
As a result:
requests become portable,
servers remain stateless,
infrastructure becomes easier to manage.
HTTP-Friendly Design
The new protocol is intentionally designed around standard HTTP infrastructure.
Several protocol elements now map directly to HTTP concepts.
For example:
methods appear in HTTP headers,
tool names can be exposed through headers,
gateways can inspect requests without parsing JSON payloads.
This enables existing API gateways and reverse proxies to perform:
routing,
authentication,
authorization,
logging,
monitoring.
Organizations can therefore reuse their existing networking infrastructure rather than deploying MCP-specific components.
Important Note
Because MCP now aligns closely with standard HTTP semantics, existing cloud infrastructure—including API gateways, reverse proxies, service meshes, and load balancers—can operate without requiring protocol-specific customization.
Caching Improvements
The article also introduces cacheable discovery responses.
Operations like:
listing tools,
discovering capabilities,
retrieving metadata
typically change infrequently.
The updated protocol allows servers to specify cache lifetimes.
Clients can therefore reuse cached information instead of repeatedly requesting identical data.
Benefits include:
reduced latency,
lower bandwidth,
fewer server requests,
improved scalability.
Large deployments especially benefit because discovery operations often represent a significant portion of traffic.
Multi-Round Interactions
A concern with stateless systems is supporting workflows that naturally span multiple interactions.
Rather than relying on persistent bidirectional sessions, MCP introduces mechanisms for Multi Round-Trip Requests (MRTR).
This allows:
clarification requests,
user input,
long-running operations,
asynchronous workflows
without requiring permanently open connections.
The protocol separates application workflow from transport-layer state.
Applications may still maintain business state (such as task IDs or workflow progress), but the transport itself remains stateless.
Security Improvements
The protocol update also strengthens authorization.
The article references improvements that align MCP more closely with OAuth and OpenID Connect best practices.
Security enhancements include:
stronger issuer validation,
improved authorization handling,
enterprise-friendly authentication mechanisms.
These changes make MCP easier to integrate into existing enterprise identity systems while reducing security risks associated with session management.
Important Note
The security model focuses on standards-based authentication and authorization, allowing organizations to integrate MCP with existing enterprise identity providers and security infrastructure.
Developer Impact
For developers building MCP servers, the migration requires some architectural adjustments.
Previously, developers often stored:
session objects,
client capabilities,
negotiated protocol versions,
temporary context
inside server memory.
With stateless MCP:
servers should treat each request independently,
persistent application state should live in databases or external storage when necessary,
infrastructure no longer manages conversational state.
Although this may require code changes, it dramatically simplifies deployment.
Tip
Stateless application servers should only process requests. Long-lived application state should be stored in external databases, distributed caches, or workflow engines rather than server memory.
Cloud-Native Alignment
A recurring message throughout the article is that AI infrastructure should leverage decades of cloud engineering rather than inventing new operational models.
Stateless MCP allows AI agent infrastructure to inherit proven practices such as:
autoscaling,
rolling deployments,
health checks,
CDN caching,
standard load balancing,
serverless execution,
edge deployment.
This makes MCP servers behave like conventional HTTP services rather than specialized stateful applications.
Why This Matters
The article argues that the stateless redesign is less about changing how developers invoke tools and more about changing how AI systems can scale in production.
As organizations deploy thousands or millions of AI-agent requests, infrastructure complexity—not model quality—often becomes the bottleneck.
Removing protocol-level session state enables:
simpler deployments,
better resilience,
lower operational costs,
easier scaling,
improved compatibility with modern cloud platforms.
In essence, MCP evolves from a protocol optimized for developer convenience into one optimized for enterprise-scale AI infrastructure.
Important Note
The primary motivation behind the stateless redesign is not to change the programming model, but to eliminate infrastructure bottlenecks that arise when AI systems are deployed at production scale.
Conclusion
The stateless MCP update represents a foundational architectural shift. Instead of tying clients to individual server instances, every request is now self-contained, allowing AI agent infrastructure to operate like any modern distributed web service. This eliminates sticky sessions, enables seamless autoscaling, improves reliability, and integrates naturally with existing HTTP infrastructure, gateways, caches, and serverless platforms. Combined with enhancements such as cacheable discovery, multi-round request handling, and stronger authorization, these updates position MCP as a protocol capable of supporting large-scale, production-grade AI agent ecosystems rather than just local development or small deployments.
Summary
Area
Stateless MCP Improvement
Architecture
Every request is self-contained.
Scaling
Supports true horizontal scaling without sticky sessions.
Reliability
Server failures no longer terminate protocol sessions.
Cloud Support
Compatible with Kubernetes, serverless platforms, and edge deployments.
Performance
Cacheable discovery reduces latency and server load.
Security
Improved authorization aligned with OAuth and OpenID Connect.
Developer Experience
Application state moves to external storage while infrastructure remains stateless.
The Model Context Protocol (MCP) relies on JSON-RPC 2.0 as its core wire format to enable seamless communication between LLM clients and servers. These methods are separated by direction and functionality, managing everything from lifecycle initialization to specific resource, tool, and prompt capabilities.
Client-to-Server Requests
These methods are invoked by the AI client to query capabilities, manage sessions, or execute actions on the server.
Lifecycle & Session
Method
Purpose
initialize
Establishes the connection and negotiates protocol capabilities.
ping
Performs a standard connectivity and health check.
Tools Feature
Method
Purpose
tools/list
Requests a comprehensive list of all executable tools available on the server.
tools/call
Instructs the server to execute a specific tool with designated parameters.
Resources Feature
Method
Purpose
resources/list
Discovers context data and files exposed by the server.
resources/read
Retrieves the raw content of a specific resource.
resources/templates/list
Lists modular URI templates available to dynamically fetch data.
resources/subscribe
Requests continuous real-time updates for a resource.
resources/unsubscribe
Cancels an active resource data subscription.
Prompts Feature
Method
Purpose
prompts/list
Discovers pre-built prompt templates available on the server.
prompts/get
Retrieves the specific structure and layout of a chosen prompt template.
Configuration & Utilities
Method
Purpose
logging/setLevel
Adjusts the verbosity thresholds for the server's logging outputs.
roots/list
Requests a list of underlying file system roots accessible to the client.
Server-to-Client Requests
These methods allow the server to ask the client for additional user context, file visibility, or model completions.
Method
Purpose
ping
Server-initiated connectivity verification to check client status.
sampling/createMessage
Requests the LLM client to generate a message or text completion.
elicitation/create
Prompts the host client to safely gather explicit human input.
completion/complete
Requests auto-completion string matching from the client.
Notifications (Asynchronous Events)
Notifications do not include an id field and do not expect a returned response object. They primarily track real-time changes.
Notification
Purpose
notifications/initialized
Sent by the client to signal that initialization is finalized.
notifications/cancelled
Signals that a running asynchronous operation has been cancelled.
notifications/progress
Provides step-by-step progress tracking for long-running actions.
notifications/tools/list_changed
Notifies the client that the server's tool availability matrix has updated.
notifications/resources/list_changed
Broadcasts changes regarding underlying data resources.
notifications/prompts/list_changed
Alerts the client that server prompt templates have been modified.
notifications/message
Transmits live logging data records from the server to the client console.
Model Context Protocol (MCP) Primitives
Model Context Protocol (MCP) primitives are the core building blocks defined in the data layer that let AI clients and servers share context, structure interactions, and execute tasks. They split into server-side capabilities (tools, resources, prompts) and client-side control features (sampling, elicitation, roots).
Server-Side Primitives
Primitive
Description
Tools
Model-controlled executable functions that let the LLM perform actions like API calls, file updates, or database queries.
Resources
Application-controlled data sources providing ambient reference data and context like file contents or database records.
Prompts
User-controlled reusable templates and slash commands that standardize workflows and interactions.
Client-Side Primitives
Primitive
Description
Sampling
Server-initiated requests allowing an MCP server to safely query the host's LLM for agentic or recursive behaviors.
Elicitation
Mid-task requests where a server asks the user for missing details or confirmation instead of guessing.
Roots
Security boundaries defining which specific directories or files a server can access.
Elicitation Requests
An elicitation request is a runtime mechanism in the Model Context Protocol that allows a server to dynamically prompt a user for missing details or confirmation during tool execution rather than failing. It supports form collection for structured data and secure URL redirects for sensitive tasks.
Key Modes & Actions
Mode / Action
Description
Form Mode
Collects in-band structured inputs and primitives using optional validation schemas.
URL Mode
Sends users out-of-band to a browser for secure flows like OAuth or payments.
Response Actions
User interactions follow an accept, decline, or cancel framework.
Important Note
Elicitation enables MCP servers to request additional information from users safely and explicitly, avoiding assumptions during task execution while supporting structured forms and secure external workflows.
Application-layer protocols (HTTP, gRPC, MQTT, SMTP, etc.) define how applications communicate, while transport-layer protocols (TCP, UDP, QUIC) determine how data is delivered across the network. IP (IPv4/IPv6) operates at the network layer and is responsible for addressing and routing packets between hosts.
An odds ratio (OR) measures the association between an exposure and an outcome. It represents the odds that an outcome will occur given a specific exposure, compared to the odds of the outcome occurring in the absence of that exposure.
Here is a breakdown of odds ratios, interpretive logistic regression, and ordinal logistic regression.
1. Odds Ratio (OR)
An odds ratio compares the likelihood of an event happening between two different groups. It is not the same as risk (probability).
Odds vs. Probability
If a horse wins 2 out of 10 races:
Probability of winning = 2 / 10 = 20%
Odds of winning = 2 to 8 = 2 / 8 = 0.25
Probability and odds are related but are not the same quantity.
Calculation
OR
=
(Odds of Event in Group A)
/
(Odds of Event in Group B)
Interpretation
Odds Ratio
Interpretation
OR = 1
The exposure does not affect the odds of the outcome.
OR > 1
The exposure is associated with higher odds of the outcome.
OR < 1
The exposure is associated with lower odds of the outcome.
2. Logistic Regression for Interpretation vs. Prediction
Logistic regression models the probability of a binary outcome (e.g., Yes/No, Success/Failure) using independent variables.
You can use this tool for two completely different goals:
Logistic regression can be used either for interpretation or prediction.
Interpretation Focus
Goal: Understand the relationship between variables.
Key Metrics: Coefficients (β), p-values, and confidence intervals.
Action: Convert log-odds coefficients into Odds Ratios by exponentiating them (eβ).
Odds Ratio = eβ
Example
"Holding all other variables constant, every one-year increase in age increases the odds of developing heart disease by 1.15 times (OR = 1.15)."
Prediction Focus
Goal: Accurately classify new, unseen data into a category.
Key Metrics: Accuracy, Precision, Recall, ROC-AUC, and F1-score.
Action: Use the model output to generate a probability score between 0 and 1, then apply a threshold (such as 0.5) to label the data.
Example
"Based on this patient's medical data, there is an 87% chance they have heart disease, so we classify them as High Risk."
Logistic regression prediction workflow.
3. Ordinal Logistic Regression
Standard logistic regression only works for two categories.
Ordinal logistic regression is used when the dependent variable is categorical and has a natural, ordered ranking, but the distance between the ranks is unknown.
Instead of predicting a single probability, ordinal logistic regression evaluates cumulative probabilities. It looks at the odds of being in a category or lower versus being in a higher category.
Ordinal logistic regression models cumulative probabilities across ordered categories.
The Assumption
It assumes that the effect of an independent variable is the same across all category cutoffs.
For example, if smoking increases the odds of moving from "Mild" to "Moderate" disease by 2.0, it must also increase the odds of moving from "Moderate" to "Severe" disease by 2.0.
Important Note
This assumption is known as the parallel lines assumption or the proportional odds assumption.
Summary
An Odds Ratio (OR) compares the odds of an event occurring between two groups.
Logistic regression can be used either for interpretation (understanding relationships) or prediction (classifying new observations).
Ordinal logistic regression extends binary logistic regression to ordered categorical outcomes by modeling cumulative probabilities under the proportional odds assumption.
Note that the term "backpropagation" is technically not used for standard linear or logistic regression. Instead, we simply call the optimization process Gradient Descent.
Backpropagation is also related to vanishing gradient. Vanishing gradient can occur only across multiple layers. Thus both backpropagation and vanishing gradient are related to multiple layers only, then are never used for single layer models.
Important Note
The word propagation implies a sequence of layers. Because linear regression and logistic regression contain only a single layer of weights, there is no sequence of layers through which errors can propagate backward.
What is Backpropagation?
Backpropagation is short for "backward propagation of errors." It is an algorithm specifically designed for multi-layer neural networks.
The Sequence
It uses the mathematical Chain Rule to calculate gradients. It starts at the final output layer, computes the error, and then passes (propagates) that error backward, layer by layer, to update the weights at the very beginning of the network.
During backpropagation, the error is propagated backward through multiple layers using the Chain Rule.
Why the Confusion in Linear and Logistic Regression?
You might hear people use the term loosely in linear or logistic regression for two main reasons:
1. Neural Network Equivalent
A logistic regression model is mathematically identical to a single-neuron neural network with a sigmoid activation function.
2. The "One-Step" Chain Rule
Even in logistic regression, you use a small version of the Chain Rule. To find how the loss changes with respect to the weights,
Because this calculation proceeds backward from the Loss to the Weights, some instructors casually refer to it as "backpropagation", even though it only spans a single layer.
Logistic regression applies the Chain Rule over a single layer rather than propagating errors through multiple layers.
Summary of Terms
Term
Definition
Used In
Gradient Descent
The overall optimization algorithm used to update weights to minimize error.
Linear regression, logistic regression, and neural networks.
Backpropagation
The specific method used inside gradient descent to calculate gradients across multiple sequential layers.
Multi-layer neural networks.
Key Takeaway
Gradient Descent is the optimization algorithm that updates model parameters to minimize the loss function. Backpropagation is the gradient-computation algorithm used within gradient descent for multi-layer neural networks. In standard linear regression and logistic regression, we typically refer only to Gradient Descent, since there are no multiple layers through which errors must propagate.
A mathematical transformation is a function T that maps elements from an initial set (domain) to another set (codomain), modifying inputs into outputs according to a strict mathematical rule.
In geometry and linear algebra, it maps vectors or points from one vector space to another, written as:
T : V → W
Here V is the domain, W is the Codomain and T is the function that maps V to W.
2. Linear vs. Non-Linear Transformations
The fundamental division between transformations relies on two algebraic rules:
Additivity
T(u + v) =
T(u) +
T(v)
Homogeneity
T(cu) =
cT(u)
Linear Transformations
Linear transformations satisfy both conditions.
They always map the origin to itself.
T(0) = 0
They map straight lines to straight lines.
They keep grid lines straight and parallel.
They can always be expressed as a matrix multiplication:
T(x) = Ax
Non-Linear Transformations
Non-linear transformations fail at least one condition.
They curve the underlying space.
They warp grid lines.
They move the origin.
Examples include squaring coordinates:
T(x, y) = (x2, y)
Or adding constants:
T(x) = x + b
(which is an affine transformation, not strictly linear).
Property
Linear Transformation
Non-Linear Transformation
Additivity
✔ Satisfied
✘ Violated
Homogeneity
✔ Satisfied
✘ Violated
Origin
Preserved
May Move
Grid Lines
Remain Straight
May Warp
Matrix Representation
Always Possible
Generally Not Possible
3. Standard 2D Linear Geometric Transformations
In a two-dimensional Cartesian plane, standard linear transformations alter the spatial properties of shapes and can be written using a 2 × 2 matrix:
[ x′ ] =
[ a b ] [ x ]
[ y′ ]
[ c d ] [ y ]
Note
Use arrow keys to adjust value.
0:00 / 1:01
Audio made with Google AI. Image licensed by Google.
Scaling
Stretches or shrinks coordinates along axes.
sx
0
0
sy
Rotation
Rotates points counterclockwise around the origin by an angle θ.
cos θ
− sin θ
sin θ
cos θ
Shearing
Slants one coordinate axis parallel to another based on a factor k.
Horizontal Shear
1
k
0
1
Vertical Shear
1
0
k
1
Reflection
Flips the space across a line passing through the origin.
Across the x-axis:
1
0
0
−1
Note
Translation—sliding an object—is geometric but requires a 3 × 3 matrix with homogeneous coordinates to be handled linearly because it moves the origin.
Figure 3.1 — Examples of scaling, rotation, shearing, and reflection in two-dimensional space.
4. Non-Geometric Transformations
Non-geometric transformations modify the properties or data structures of elements rather than their spatial positions, shapes, or orientations.
Transformation Type
Description
Examples
Data Transformations
Converting variable distributions in statistics.
Logarithmic transformation (log(x)) or Z-score normalization.
Color Space Transformations
Converting digital imagery pixels from one color representation to another.
RGB → CMYK or YCbCr color spaces.
Domain Transformations
Changing the functional domain of an equation.
Fourier Transform or Laplace Transform for mapping time-domain signals to the frequency domain.
Cryptographic Transformations
Permuting and substituting data bytes to encrypt plain text into ciphertext.
Algorithms such as AES.
Important Note
Unlike geometric transformations, non-geometric transformations change the underlying data, representation, or mathematical domain without necessarily altering the physical position or shape of objects.
